Quake2 Engine In Java 123
An anonymous reader writes "Ok, so the game is old and there was a really poor web version some years back, but some guys at Bytonic Software in Germany have done a full source port of the Quake2 engine from C to Java. It's cross platform, performs just about as fast as C and has room for further improvements according to the developer. Also, there was another game engine that ran Q3 maps that was shown recently at JavaOne. Are first generation Java games that far behind?"
Re:Java != Slow (Score:5, Interesting)
The language does not always matter (Score:5, Interesting)
By the way, what hardware have they tested on to claim that performance is similar? If it's modern hardware, then of course it will run at 60+ fps no matter what.
What's more, I would guess the bulk of the work on the CPU for quake2 consisted in traversing the BSP tree, building the scene (with transforms still being performed on the CPU at that time) and collision detection. The rest is taken care by the graphics hardware so that's totally independant of the language you've used.
There is one thing that bothers me with Java though. You never know when the garbage collection will be performed. Sure, recent virtual machines make it possible to perform garbage collection in smaller but more frequent iterations so you don't halt the system for a few seconds like early virtual machines would do. But still, if you're in a tight loop with your data and instruction cache perfectly populated, and all of a sudden the garbage collection kicks in, then your cache is toast and data will have to be refetched to it when execution resumes. That would result in a horrible performance loss provided you are already really close to the machine's limit. Also, what I'm saying is only pertinent on a console with no (or almost no) OS, because on any PC operating system, your process can be interrupted at any time by the various system tasks that are running, so the garbage collection interrupting your tight loop would only be one of many possible interruptions.
I don't believe java can be as fast as native code, although probably extremely close. And sure, a good java compiler will generate faster code then a crappy C++ compiler.
Another thing I don't like about java is that you have no control over memory (not that i know of, maybe some recent VM extensions allow you to have some control over that?). I really like to be able to give different sets of alloc/dealloc routines to the different subsystems in a game. A subsystem that is known to perform very small allocations/deallocations very often could be passed alloc/free routines that are customized to its use so that memory fragmentation is kept to a minimum. If such a component was allowed to get memory from the same pool then your other subsystems, it would wreck havoc on your memory.
Anyway, it's not such a good idea to compare java and C++ (or whatever other languages) on a system where resources are abundant (PCs).
By the way, Jak & Daxter for the ps2 is written in a lisp derived language (GOAL), yet that game outperforms and looks better then almost everything else on the ps2. Yet lisp is not perceived as a high performance language. But the people at Naughty Dog have developed their very own compiler that is extremely specific to their needs (see their gamasutra post-mortem, very cool read) So, it goes to show that the notion of performance shouldn't be tied with a language, but rather with that language's runtime & compilers.
Ok enough ranting!
garbage collection? (Score:3, Interesting)
Vampire: the Masquerade (Score:3, Interesting)
Nihilistic [nihilistic.com]'s Vampire: the Masquerade - Redemption [nihilistic.com], back in 2000. As I recall, in the Gamasutra postmortem [gamasutra.com], they commented on how well it worked out for them.
Sadly, I don't know what JVM they were using - but they did say in the postmortem that they didn't write it themselves.
Re:Yes, sorta (Score:1, Interesting)
There are games and then there are games :) One should make difference between traditional rich games (sold in boxes at store shelves) and small games (browser games and mobile J2ME games). Popcap seem to be designing the latter. The amount of work for browser games is not comparable to rich games. Browser games are simple, taking maximum few months to develop. Rich games cost average 5 million dollars [dfcint.com], have hunders of people working on them and development time is counted in years [3drealms.com]. As far as I know, no rich games use Java for their core, but Java has been used for scripting purposes in rich games.
Due to Java's nature to maximize portability, Java's means for native interface fine control (i.e. display drivers) is crippled. You need to make an extra complex DLL layer (JNI) between Java and an operating system. This is hinderous for core engine performance. The engine in the article used jogl as a layer and the engine page mentioned that they have reduced the number of native calls because of performance penalty. Also, Java's safe memory management model prevents making any "dirty tricks" to tweak performance. C# comes around this by having ability to have inline "unmanaged" C code directly in C# source.
Maybe in some point CPU speeds are so fast and systems are so mature that there is no more requirement for "low level work" in game programming. But not yet.
Nothing new (Score:3, Interesting)
in Python some time ago, and currently hacks on
qrazor-fx aka http://xreal.sf.net/ which is a Q2
with graphics quality in the range of Q3 or even
Doom 3.
Re:The language does not always matter (Score:3, Interesting)
Actually on mobile phones, where you're working with extremely limited hardware and very little RAM, it's common practice to force the garbage collector to run regularly. I usually call the gc in the central game loop to prevent "hitches" during play as a large(ish) block is freed up randomly.
Since just about every game I've written is under 30k in size (including graphics and sound), and most run in phones with as little as 100k of usable RAM, no hardware sprites etc, I'd say that Java can be pretty efficient!