Slashdot Mirror
Quake2 Ported to Java, Play Via the Web
casemon writes "Quake2 fans unite! Thanks to German software developer ByTonic software, you can now play Quake2 via the web with Jake2 a java port of ID Softwares seminal Quake2. ByTonic claims performance is similar to original C version. From the Jake2 website;
"Jake2 is a Java 3D game engine. It is a port of the GPL'd Quake2 game engine from idSoftware. To use the Jake2 engine you need either the data files from the original game or from the demo version available for download from ftp://ftp.idsoftware.com."
You actually don't need to get the data files, they've set it up to automatically download the 38Mb demo assets using WebStart. Just click the Play Now button and away you go. Most features supported, even multiplayer server!"
Actually, it runs pretty quickly, although not quite as quickly as the original. Something like 85-90%. That's mostly because of the overhead of calling into the OpenGL libraries from Java, and because Quake 2 was written at a time when 3D games were fillrate limited, not CPU limited. Back then, the extra overhead of sending models one vertex at a time was essentially zero, because you were still sending the data faster than the graphics card could render it. With modern graphics cards, Quake 2 becomes CPU limited. The extra overhead of all those unnecessary OpenGL calls is even greater in Java than it is in C, so it ends up running slower.
It'd probably be better if the game were designed as a Java program, rather than a C program. The Java code is a fairly close port of the original C, so it does quite a few things which aren't optimal for a Java program.
Right on, brother! The C/C++ bigots just can't accept that a Java program might run as fast as, or (gasp!) faster then a C/C++ program.
I worked in a compiler group for 10+ years. Profiling was definitely the best way to optimize a program. The challenge was that the compile-profile-compile loop was cumbersome and was hard to account for all use cases. JIT profiling deals with YOUR use case. If it's really good, it will even adapt and re-profile as your use pattern changes.
"No matter where you go, there you are." -- Buckaroo Banzai
I have two points.
Comparing a static C binary, with a JIT is sort of silly. Logically comparing a JIT with a C binary compiled with profile based feedback optimization is probably more legitimate.
Secondly, the released Quake engine had a couple of assembly routines. Proving that C wasn't always the best choice, even back then. My understanding is that the versions of quake with assembly loops are roughtly 30% faster than the C only version they are comparing this with.
In the end these sound like good results, I'm continually amazed at how fast java has gotten. The fundamental arch is pretty much broken for generating fast binaries, and it speaks volumes about the quality of the coders writing the JIT engines that they can make a stack based compilation target run fast on modern processors.
Oh, one final thing, did anyone see what C compiler they used for those numbers? I'm currious if it was the same compiler ID originally used, or one of the more modern intel compilers?