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!"
http://www.bytonic.de/html/jake2.html just thought it might be, you know, handy?
Brain(s): 0.0% user, 1.3% system, 0.1% nice, 98.6% idle
I saw it at swing sightings. I tried it with the original game files and didn't notice any difference in speed with the original binaries.
And this with a not so fast computer: PIII 800, TNT 2, 384 MB RAM.
Anyway if you wanna see benchmarks with older computers look at their web.
... I would give this guy research lab and resources to create java-based DirectX library. For game developers, it would be just great to write once and sell on Windows on Linux on Mac on Playstation (don't know about XBox). Even without Sun's support, it would be great fot 3rd party to sell such engine/framework.
839*929
in Firefox?
Runs great on my 1.2 GHz G4 with 640 MB of RAM in OS X 10.4.3. Running the web start version downloads a file which starts up as a separate java program.
This is the coolest use of Java I've ever seen.
No, I don't think so. Perhaps if you were born after 1985. Wolf 3D and Doom were the seminal games, or perhaps even Ultima Underworld, although nobody seems to remember that one. There were many games in the genre making it appear tired and unoriginal long before Quake 2 came along with a bit more of the same.
I've played Quake 2 than all the rest put together, but that doesn't make it seminal.
dupe
Check out the benchmarks. Similar frame rates to the C version on the same hardware.
I've not tried it myself yet. Might get in trouble at work.
Jvm apps can be faster than their compiled counterparts, specially when compared to those made with non specialized compilers like GCC. The "virtual machine = slow" myth is no longer true.
The real issue is startup time and initial memory consumption. Java is not suitable for applets that run in the background because your basic app will require about 20 megs of RAM minimum to start. Another issue is swing. You can disagree with me, but please wake me up when it gets clear type fonts on windows.
Cheers,
Adolfo
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.
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.
Even with 512MB of RAM, Azureus (the hugely popular Java-based BitTorrent client) takes forever to start up, responds sluggishly to user input, and sucks down so much RAM that the Windows PC it's running on is nearly useless for any other task. This isn't simply the nature of BitTorrent - other clients run far more smoothly.
Maybe there are reasons for this that aren't directly related to Java. Maybe Azureus just isn't very well-written, or maybe it's just feature-bloated. Maybe the Windows JVM just stinks.
But in any case, the common perception of Java applications as being slow and ponderous is one that Java applications have earned - there are actual reasons, based on real-world experiences, that cause people to feel this way. That has nothing to do with some pig-headed resistance to change.
Rather than railing against the Java-haters, why not point out some useful, slick, fast Java-based applications? I'd love to see some. Every one that I've tried so far has been a disaster in one way or another. I honestly want to like Java. I like the language, I love the concept - it's the real-world experience with it that I have a problem with.
"Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
Mustang (Java 6) which is under Open development (not quite open source license) already has wider support for clear type than Microsoft... So you are right its a bit late but people have invested work into that.
Swing is not slow or bloated, it just can't be compared to the native OS size since it duplicates its functionality so its memory usage seems high in the task manager. Startup time and cold start is improving with every release and building serious client side Java applications is becoming a very real option.
Here are some screen shots, coz that's most important and what people really want and shit...
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?
The only reason that this posting is news is that, up to now, Java programs haven't been as fast as C++ programs in the general case. Given the overwhelming experiential evidence, it would seem that the Java bigots are the ones who need to make more of a case than "it is faster because I say so." Quake 2 running on Java is a start. Quake 4 having shipped as full Java would have been a big win. That this post isn't being brushed off as non-news bears out my point.
This is really the conflation of two orthogonal arguments, though, and we should take care to avoid treating languages and their compilation/execution mechanisms as locked behaviors.
When the Cell takes over, we'll all be stuck writing for SPEs in straight C.
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!)
640 mb of ram should be enough for anyone.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/