quote:Original post by cwurts
Nobody has ever answered this question to my satisfaction. C++ is the standard for game development, but is there any good reason for this, other than circumstance? Is there anything java is lacking that would make it inappropriate for game development, and what would that be?

1) These kinds of posts are against forum rules.

2) It depends what kind of game you are making. Web-based games are Java''s domain, but it just seems weird to make it take the place of C++ as far as commercial games. It''s just not what it was designed for. There is nothing to stop you from doing it, other than a small speed hit. And before anyone says anything different, yes, there probably will be one. Most of it comes from your lack of control over memory. A good Java programmer will be able to make this almost nothing though. Basically it comes down to which ever you are more proficient in.

i think that until you come to the point when your program is actually running slow, you shouldnt be too worried. i was installing uru and noticed that it was installing a java virtual machine onto my hardrive. im assuming this means that the game was coded in java, sure didnt run slow. of course, most games still use c++. (before anyone decides to argue this, go to all the major game developers websites and check their job postings. you''ll see "c++" come up an aweful lot.)

Many games today use java (or lua, or whatever) as a scripting language, since you can probably get something closer to 50-80% execution speed vs. C++, instead of the typical 5-20% with a pure bytecode approach.

quote:Original post by cwurts
Is there anything java is lacking that would make it inappropriate for game development, and what would that be?

For a PC game which is to be distributed as a boxed up CD on the retail shelves and is not intended to be ported to any consoles, no. Anything else is a maybe.

The first biggest problem with Java for games at present is related to target market. There is not at this time a port of Java to any console system, so this rules it out for a game that will target consoles.

The second limiting issue is JRE distribution. For a game delivered on CD this is no problem, as you can bundle the JRE with it. For web distributed games you are now either asking your potential customers to download the latest JRE separately, or bundling the JRE with the game download directly - moves which could affect sales.

Sun is doing a lot to get the JRE out there. Companies like Dell are installing the JRE on new computers they sell, there's an auto update now, etc... I'm fairly pessimistic on this sort of thing though, so the situation might be rosier than I think. I know Three Rings has been successful with YoHoHo! Puzzle Pirates. They distribute online with a bundled JRE. Other Java games, such as Alien Flux are having meager success being distributed via Webstart. I'm really interested in seeing how OddLabs does with their upcoming Tribal Trouble, as it is more hardcore than most of the Java games on the market now.

Those are the two biggest problems with Java game dev as I see it. On these forums, you'll see people rant about performance, how they are forced to use classes, how the garbage collector brings the framerate to a crawl, or how they don't need a language to hold their hands. I think it's fairly easy to separate the wheat from the chaff. To find out about the real issues that arise in Java game dev, head over to the javagaming.org forums and talk to people who are actually doing it.

[edited by - aldacron on June 13, 2004 1:33:51 AM]

quote:
i think that until you come to the point when your program is actually running slow, you shouldnt be too worried.

Sorry, but no. While that''s certainly a valid response for optimization, it''s not exactly an easy task to completely rewrite your whole engine in another language once it''s been written. You need to choose a platform from the get go.

Yes, porting from C++ to java *CAN* be easy, but for someone who''d even ask a question like this, I can guarantee that it won''t be.

quote:Original post by Kranar
I still think it''s silly to say that because of JIT, Java is or can be faster than C++.

Actually it''s not silly. Theoretically, runtime compilation should allow much better performance than current C/C++ optimizers. The compiler has more information available to make optimization decisions based upon runtime data. It''s a much more intelligent process. We aren''t there yet, but as the technology improves you might very well see Java and C# performance surpass C++.

quote:
First off... there''s a reason why games aren''t being made in Java, and yes it has to do with speed/performance.

Sorry, but no. There are several games being made in Java. Check out the links I posted earlier for examples. Of course, I''m sure you''re only referring to AAA, boxed, retail titles. You will see more of those in the near future, but as long as a shop wants to put a port on the console they won''t be using Java. And drop the performance myth already. It''s ancient history.

quote:
Third, have you ever seen a Java GUI? They have serious performance issues compared to an OS''s native GUI.

And all Koreans eat kimchi. You are generalizing, mate. AWT has been performant for years (it uses the native GUI). Ever used SWT? The only poor-performing standard Java GUI I''ve seen is Swing. Check out the 1.5 beta2 to see how it performs now.

quote:
Use Java because you want a language that is restrictively object oriented, neat, elegant, and don''t want to have to worry about cross-platform issues. Don''t let this JIT technology being able to allow incredibly small fragments of an algorithm execute 2 percent faster than its purely C++ counterpart fool you into thinking that JIT is the answer to Java''s speed issues, because it''s not. JIT is a nice and advanced feature, but it sure as hell doesn''t compare to the incredibly impressive optimizations that a compiler like MSVC++ .NET provides.

What happens when you couple the incredibly impressive optimizations that a compiler like MSVC++ .NET provides with the incredibly impressive optimizations that runtime compilers can provide? What do you think the MS .NET runtime JIT is all about?

JIT *is* one answer to Java''s performance "problems". I don''t know why you think it isn''t. JIT would even improve the performance of C++. How could it not?

Well, actually JIT can't ever outperform "native" code. It can, at best, compile down into native code the same way as a normal compiler does. Doing this at runtime gives (theoretically) some advantage over statically compiled code. In practice, it doesn't, because it's pretty easy to determine where your bottlenecks are beforehand, and optimize around that. JIT solves a problem that doesn't really exist. It's a VERY useful tool when it comes to making a program that will run optimally on multiple platforms without requiring recompiling, though, as you can approach native speed without doing anything but update your VM. It's still faster to run an app optimized for each target platform, though (assuming you have a decent compiler and don't suck at programming).

Like I said before - write the same program in a JIT and in a non-JIT environment, and tell me which one runs faster (I'd recommend using C++ for this comparison, since you can do managed C++ -> CLR and get a fair comparison).

There's just far too much overhead involved with the process.

By the way - MSVC++ already does use JIT -- during debug mode.

JIT is the future, unquestionably. But it's not the present.

There is no performance "myth" about Java. Java is slower than C++. Do the programming yourself, it's the best way to be sure that it's a 'fair' comparison. I can already tell you what you'll discover though, because I've tried it myself. There is a LOT of overhead involved with the built in GC, the JIT compilation, and the rest.

Oh, and yes - there are games written in Java. None of them are very speed-critical games. You could also write these games in C# or VB (and at least you'd have easy integration of a first-class API, unlike the hacks like Java3D that exist for Java).

Many people don't seem to understand how JIT works. It *IS* bytecode. It's compiled "just in time" into appropriate machine code to give optimal performance during runtime. 99 times out of 100, this code is not on par with what would be generated by a native compiler during static compilation (how could it be? it's got fractions of a second to choose the best optimizations, whereas native compilers can spend as much time as they like compiling). It's not some magical panacea to solve all performance issues - you still have to program intelligently. With .net, you also have a healthy portion of your code precompiled so that it's already running in appropriate machine code for the platform (which is done because -gasp- it's faster than JIT!).

[edited by - Etnu on June 13, 2004 5:21:27 AM]

quote:Original post by Etnu
Well, actually JIT can''t ever outperform "native" code. It can, at best, compile down into native code the same way as a normal compiler does. Doing this at runtime gives (theoretically) some advantage over statically compiled code. In practice, it doesn''t, because it''s pretty easy to determine where your bottlenecks are beforehand, and optimize around that. JIT solves a problem that doesn''t really exist.

I''m inclined to disagree with you on this. There''s a big advantage to runtime compilation in the fact that the compiler has information available that a static compiler does not.

quote:
JIT is the future, unquestionably. But it''s not the present.

I agree with this, and said as much in my last post. Even so, Java specifically has seen significant gains in the last few years because of JIT.

quote:
There is no performance "myth" about Java. Java is slower than C++. Do the programming yourself, it''s the best way to be sure that it''s a ''fair'' comparison. I can already tell you what you''ll discover though, because I''ve tried it myself. There is a LOT of overhead involved with the built in GC, the JIT compilation, and the rest.

Yes, there very much is a performace myth about Java. I can''t count how many times I''ve read or heard people say "Java is too slow for this or that". That may have been true years ago, but it is no longer. I will not argue that Java is slower than C++, but I will argue that the difference is negligible.

I''ve been using Java for several years now. In that time, I''ve discovered a lot . And I will strongly disagree with you on the GC overhead. Just as there are things you should/shouldn''t do in C++ (avoiding temporary objects in overloaded operators, for example), there are things you should/shouldn''t do in Java. One of the things a Java programme should do is understand how the GC works. Another thing is GC profiling to find which of the available GCs work best with a particular app. It''s quite possible to code a game without seeing any GC stutters at all.

quote:
Oh, and yes - there are games written in Java. None of them are very speed-critical games. You could also write these games in C# or VB (and at least you''d have easy integration of a first-class API, unlike the hacks like Java3D that exist for Java).

That''s just nonsense. I think you''ll be surprised to see what comes down the pipe over the next couple of years, or even what is out there now if you take the time to look Some of the submissions for the Java Games Technology Contest should really open some eyes.

quote:
Many people don''t seem to understand how JIT works. It *IS* bytecode. It''s compiled "just in time" into appropriate machine code to give optimal performance during runtime. 99 times out of 100, this code is not on par with what would be generated by a native compiler during static compilation (how could it be? it''s got fractions of a second to choose the best optimizations, whereas native compilers can spend as much time as they like compiling). It''s not some magical panacea to solve all performance issues - you still have to program intelligently. With .net, you also have a healthy portion of your code precompiled so that it''s already running in appropriate machine code for the platform (which is done because -gasp- it''s faster than JIT!).

I''ll be the first to admit I''m no expert on runtime compilation, and that there is certainly room for improvement. But look how long it took for us to get to the current state of the art in static compilation. While the runtime compilation is certainly not a new idea, actively developed runtime compilers are still relatively young. Eventually, we''ll get to a point where this sort of discussion will be moot.

Java has its problems, yes. But they are not the problems that are commonly tossed about on these and other forums. I''m not quite yet willing to bet the bank on it for a self-published game simply because of the JRE distribution issue, but others are and some have been quite successful.

J. P. Lewis gives wrote a practical article on all of this here. I think anyone who has doubts about Java performance should read it from top to bottom. You can find out more about Lewis'' works and reasearch (mostly in computer graphics) here.