Tired of hearing of my projects yet?

[ultifinitus]

Hah well I am SERIOUSLY almost done with my first app... it's taken long enough.

My holdups have been the following things:

first using blocking sockets and threads, my server was super messy, and could only accept exactly one client at at a time.

The communication between threads was... wretched. A class based communication system that, well it worked sometimes =)

I had no idea how to display a second view for my help menu. Took five seconds to fix that...

I ended up asking around about async socket programming and learned to use select(), which is awesome. But you can't have more than 1024 clients on a posix system. So right now I'm dealing with the cap, but as soon as I actually get my server up and running I'll swap over to poll()

My graphics took me *forever*. I don't know why I took so long... But seriously probably more than half of the time I spent coding I spent making stupid graphics...

My game =)

Then I started learning java for the android....


anyways, enough talk, you can see the latest screenshots on facebook:
http://www.facebook.com/pages/Ultifinitech/188161037870298?ref=ts

[D80DSL3A]

I haven't learned about sockets, etc. yet but I share your frustration regarding the immense fraction of dev. time devoted to the graphics in an app.
This is mainly why I switched to SFML from DirectX, so only 50% (instead of 80%) of my time goes into graphics.
That's still too much though. Developing the logic should be the main project focus.

[ModShop]

I like Java, but I like C++ better. My opinion is probably biased though, because I learned C++ first. I like the "freedom" that you have with C++, especially when it comes to source files. In Java, you need a separate file for each public class! Also, C++ tends to be faster because it is run independently, Java needs its JVM. But, this also makes Java portable to just about anything.

[1yR4jE8b]

I prefer C++, but I also like Java very much. Java uses/needs very little external libraries because there is a class for pretty much anything you can think of in the JSL. I've also brought over the "one class per file" into my C++ coding style, I just find it cleaner and easier to maintain.

I will second the frustration at the amount of time it takes to write a GUI. In my computer graphics class, 10% of the assignments were for just implementing the algorithm he asks us and the other 90% for writing the GUI to go along with it. Writing GUI code is tedious and boring, thank god I had a WYSIWYG Java GUI Builder (Netbeans).

[chrisname]

darkestfright wrote:

I've also brought over the "one class per file" into my C++ coding style, I just find it cleaner and easier to maintain.

I do this as well (though if a class inherits another one I will sometimes put them both in the same file, unless another class inherits it as well).

darkestfright wrote:

I will second the frustration at the amount of time it takes to write a GUI

Another "agreed" from me. This is why I'm writing my own, it's a wrapper for SFML. It's a lot of fun, but it's annoying having to work around SFML's sf::NonCopyable base class (any class that inherits it can only be passed by reference or pointer, which is very irritating).

[sohguanh]

I've also brought over the "one class per file" into my C++ coding style

Actually to be more precise it is "one public class per file". I can have ONE public class but multiple non-public classes residing in a single .java file.

Usually those non-public classes are meant to be used by that ONE public class only. Outside code cannot call direct to those non-public class but they can use the public class as "base" to indirectly access those non-public class.

Generally I do prefer the one class one source file as it is easier to do future maintenance but when you do lot's of GUI-related programming with Java, you will sooner or later use the above method to do anonymous inner classes etc etc.

For non-GUI Java code, I guess it is still pretty straight-forward.