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!"
in Firefox?
>>In some cases, this can result in more effecient code than a precompiled binary such as one created by a C compiler. This is a bullshit argument that generally presumes a substandard optimization by the binary compiler. I believe the theory is that the compiler can optimise for, say, Athlon XP, but cannot assume that anything above a 386 (or a Pentium, depending on settings) is being used, so it can't use XP-only instructions/tricks. Whereas the JIT compiler can optimise for the exact processor it is running on - it doesn't need to be able to run the programm on any other machines. This is particularly the case in Windows, and for Linux binary packages (obviously gentoo can do what I described when installing packages). Whether this actually makes an appreciable difference is another matter.
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.
If you consider Quake2 as the first game to really make it while introducing proper mouselook to the masses, yes it is. Duke3D had it, but it was wonkky enough to make me seasick so it never got used. Quake2 gave you the ability to do much more with it than anything prior, even Quake, where it was not really needed and played by the best gamers I know with pure keyboard.
Can we get a comparison of the Java and .NET ports of this?
.NET port can be found at http://www.vertigosoftware.com/Quake2.htm
The
Most users that played Quake2 did not have hardware with builtin 3D acceleration. So the folks at idsoftware improved their already outstanding software rasterizer for Quake2, which provided almost identical rasterizing performance on then-highend machines compared to modern 3d cards at that time.
If the Java version would do the same, then I would take my java performance prejudices and dump them.
Don't underestimate the execution-speed of Java in a decent JVM. For example: My Java-based HTTPD outruns Apache HTTPD for static file serving.
Still, there are things that needs to be addressed:
- Multiplayer should allow voice and webcam communication.
- There should be Servers and bandwidth available for Multiplayer games.
- All parts of this library must be able to run on Windows/Linux/Mac/Playstation (including JRE and SPU support on PS3)
- There should be new graphic instructions in Java JRE (based on OpenGL API) that directly maps to OpenGL driver and don't need RMI layer.
- There could be "iTunes for games" service that provides all games and previews on a single place (money generator)
839*929
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
Their website shows the framerate going up by about a third by switching from jogl to fastjogl.
I have developed code in java for a few years now and you are over simplifying the case.
Where Java has been or still is slow.
1. Start up. It takes a good bit of time to start a java program because it takes a good amount of time to load the JVM. Not an issue on a sever where the JVM is probably in use all the time but a pain on the desktop. It also makes small utilities a pain in java. The latest version of java seems to start quicker.
2. Swing. Swing has been slow. The latest version of java seems much better.
I here all the time how Java can be as fast as c++ but I have to admit I have never seen it. I would put Java in the class of fast enough for most tasks.
I use Java because I like OOP and I really like how Swing is laid out. It fits my mind set a lot better than MFC which I hate with a passion or GTK which while object oriented is not in c++. You can use GTKmm but the number of dependencies is just over the top IMHO. Everyone is different so what I like may not be what someone else likes.
I don't do VB because I will not learn a programing language that only runs on one OS. I also have not bothered with c# yet because I see little benefit over Java unless you are going to stick to just Windows. I have to develop for Windows and Linux so that is not an option.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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?
There is no way to write and read from lots of memory quickly in java is there?
.NET being better than Java. Even newer reports show that Ruby is better than .NET. I guess Ruby is the best there is. Expect a Ruby port of Quake that runs faster than the original C version ;)
Yes, Java came out with Native I/O API (NIO).
All benchmarks that I have looked into that show that Java runs faster then C/C++ are extremly heavily biased towards making Java look good.
I've read similar reports of
Correct me if I am wrong, but in order to get towards the original C code, they have had to change the quake rendering code, and in doing so, have made Quake2 more optimal for modern video cards with modern drivers.
Yes, they optimised with vector arrays and how memory is allocated in some loops. Vector arrays meant Java sent fewer calls to OpenGL since one performance issue with Java to OpenGL is calling virtual functions (JNI). Its unlikely that using vector arrays in the original C port would do anything for performance. The memory allocation is a bit more tricky since Java works with memory differently than C and this may not be an improvement to the original C code. I haven't read the source code and have to take the developers word on all this.
But to be fair of Java, it has to go through an extra layer of interfaces to make the calls (On the other had this is always another argument why java is actually slow)
Most Java applications do not use JNI code which would make that argument rather rare in usage.
Is it true java needs more memory, does this therefore this can cause more cache thrashing?
No, the garbage collectors in Java do a pretty good job at making sure the cache is not thrashing. But, if you read some Trolls here on Slashdot they would state that Java not only ate all their computer memory but also kicked sand in their face at the beach and stole their lunch money. Depends if you WANT TO BELIEVE that Java takes 600 megs to run. It won't match reality but might make a "Java Hater" fan club member sleep easier at night.
I've actually had the experience of writing java games on mobile phones, its really sad that the performance of java has become hyped to the point where people think giving developers no other choice but java on these machines is a good idea.
This reminds me of when I was writing PalmOS apps. I was writing them in C using a modified Cygwin compiler on Windows. Some time later I came across SuperWaba and dropped the C code in a heart beat. Main reason? It was cross platform. With SuperWaba I could support all types of PalmOS platforms AND Windows CE. Seems to be the #1 reason phone companies use it too. Theres just too many different types of phones out there with different chips, operating systems, memory sizes, screen resolutions+colors, buttons, etc. Seems smart to give developers the capability to hit more devices rather than fewer. C may give you sweet access to performance for a particular machine/device but it will also lock you to it.
"Some simple optimizations" ? does "simple" optimizations in Quakes C/C++ 'Original C Code' too little kid... (how many java programmers knows/owns JVM/JIT/JSuck optimizations vrs. how many C/C++ programmers knows C/C++ standart code? I will not never pay $100/hour for a Java expert programmer, but $200/hour for a C++ semi-expert programmer!)