Yeah, if you make a C++ application and insist on using one of the operating system's GUI systems/APIs directly, you're gonna run headfirst into portability issues. If you use a multiplatform layer inbetween, something like Qt or GTK or similar: your app will work the same on windows, mac, and linux.. the portability issue disapears ( as long as those are your target platforms.. ). Same with 3D even; use SDL + OpenGL, and all necessary porting is taken care of, between windows and linux atleast. I see the 'C++ apps aren't portable' argument as a myth; from experience with 2 largish apps: as long as I'm careful and avoid ( or allow the switching of [ which is rarely necessary ] ) all platform-specific code, and use multiplatform libs where appropriate; building the same code on windows and linux is trivial.

those multiplatform APIs however are non-standard and hard to use.
Their licenses are also often such that you don't want to use them (forcing your application into GPL for example, or extremely expensive).
There's also no standard.


They also lack documentation, can't be easily (if at all) extended, etc. etc.
The full product is well worth paying for if you're going to use Visual Studio for non-trivial tasks.

I'll agree, the Qt licensing sucks. GTK isn't bad though; it's LGPL, which is reasonable.. It (GTK) IS a messy API to use directly, but the Glade XML format is handy. Neither of these really aim to be standards; they are multiplatform APIs for user interfaces, that's all, and they do that well.

Anyway, I know where you're coming from, but if a standard for the runtime and GUI gets Java + Swing; I'll stick with no standard GUI, threads or networking; and C++ & libs / engine code. It's totally a preference thing, but there are good reasons for having that preference - and it's nothing to do with running speed ( or resistance to change - I learnt Java before I really understood C++ ) : it's mainly the lack of the same amount of groundwork in games libraries on Java as is on C/C++, but also a dislike of the simplicity of the Java language, which actually makes it highly complicated to use at times. Also.. for all of Java's proclaimed multiplatform-ness, I don't see a JRE on the Wii, DS, Xbox360, PS3, PSP, etc..

i know, i dont get how java runs on my phone but they dont make a CE edition

I entirely disagree with your statement. I think you are completely wrong. I think that proprietary APIs are the WORST at providing documentation and are usually far more complex and require a much higher learning curve. Have you ever tried easily finding the full documentation with full code examples for the Windows API or the Apple API. I didn't think so. Although you could argue that you have MSDN at your disposal on the Microsoft side. Trying to find ANYTHING on MSDN is like trying to find the worlds smallest needle in the worlds largest haystack. Not to mention that Microsoft's APIs for C and C++ are some of the worst I have ever used.

Whereas the Open Source APIs are far easier to learn while not sacrificing flexibility. They make more sense logically in your code. When you go to their websites, all the documentation is right there in front of you, easy to navigate, and most provide many tutorials and code examples on how to use their API for free. Most are licensed under the LGPL. In Qt's case, you have a choice of the GPL or the QPL. And then you have WxWidgets which has its own open source license and uses native widget toolsets on all platforms. The same thing applies to graphics APIs

Interesting thread... too predictable, unfortunately.

May I ask how many of you suggesting Java is "as good or even better than c++ for gamedev" have actually worked in games industry? Or at least have worked on a game, from start to finish?

There is that old saying, "right tool for the job", it fits in this discussion pretty well. Java is not the right tool for the job.

Well I can say that I have. But then again, I wasn't one of the people supporting Java for game dev. I think it'd be terrible for full blown 3D games. Not to mention slow. Having to translate the bytecode into machine code at runtime. You'd get an ass-wooping of lag every time you did something.

This is the stereotypical wrong view most people have. Java bytecode is compiled to machine code at load time and optimized at runtime. It means you will have longer loading time, and the performance will be sub-optimal for about 30 sec, until the JVM fully optimizes the code.

It is not the question if todays games are made in C++, they are. The traditional game libraries are for C++, not Java. Using those in Java is possible through JNI, but its another layer of code which needs to be written. The inner loop of the engine can be written in C++ (or ASM if you will) and linked to Java. The Sun JVM has been open-sourced, so it is possible to directly integrate custom C++ code with the JVM. I hope that a more game friendly JVM will emerge from the open source JVM.

The anti-Java attitude of the C++ "fanboyz" is highly predictable. As are the utterly flawed arguments they keep repeating again and again to "prove" that "Java is slow".
Java WAS slow, back in 1999 and before. It no longer is.
We run realtime systems in Java, systems were seconds can mean loosing or making millions, systems that according to the "Java is slow" "wisdom" could never be built in Java, and not at all using EJBs. We've done it, it works, and it screams (if the database and network can keep up, sometimes they can't).
It's fast enough in fact that we had to artificially restrict the flow of data in order to prevent overloading our customers' systems.

It may not be a 3D game, but it's mission critical and realtime. And they told us it couldn't be done because it was going to be Java...
There are similar stories all over the world.

What's hurting Java for game development is mainly the lack of easy to use libraries like the ones that most game studios have had at hand for C++ for a decade or more.
Performance is used just as an excuse, "measured" by people with no practical experience in Java using deliberately skewed "benchmarks" created by people like them who had a preconceived conclusion ("Java is slow") in mind when they set out.
Run those against old JVMs (based on the also flawed preconception that noone has anything newer than 1.1 installed on their systems), and the results are predictable.

But you're essentially comparing the speed of a BASIC implementation of something running on an XT and comparing it with a C implementation of the same thing running on a 486.

^ No, all that simply does NOT apply to games. Having servers that scale does not translate to games. I've been working on games for 7 years now and I am also well aware what Java can (and can not) do.

Java CAN work nicely for MMOs (actually, it's probably the best bet for server-side), but CAN NOT handle low-level cpu-intensive systems on todays gaming hardware (including PowerPC in every console today, a cpu without ANY of the tricks JVM could use). Here I'm referring to AAA titles with cutting edge physics/rendering/AI. Java could probably handle games with lower requirements, though.