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?"
0.9.2 version released (Score:5, Informative)
This is a good demo of the power of Java, it handles the game, then passes this smoothly to the native opengl rendering. Jogl is great, I hope I can find time to work with it some more.
Those crazy Germans do deserve some awesome credit for this! (having lived in Germany I can say I love Germans, and they are crazy!
Sourceforge page [sourceforge.net]
Re:Java != Slow (Score:5, Informative)
Re:What?! (Score:1, Informative)
I ran it here and there was no noticable speed difference and a little benchmarking only showed it to be marginally slower -- although perhaps there would be a bigger difference on slow hardware. One thing I did notice though was that it was a bit buggy, this ranged from a few small anoyances like mouse2 and mouse3 being mixed up in the preferences so my old config file had to be edited to the fact that it always crashed on exit forcing me to do a 'killall -9 java' which makes you doubt the common assertion that Java code is less buggy than C code (of course this hasn't had the level of testing that Quake 2 had nor has it been developed by the likes of Carmack).
High performance Q3/D3 graphics engine (Score:4, Informative)
A brief snippit from the developer site:
Re:The language does not always matter (Score:5, Informative)
Actually, in the more recent JVMs garbage collection improves cache coherency through memory locality - newly allocated memory is likely to be close to already allocated memory, and thus in the cache.
The same techniques can be exploited to cause stack allocation instead of heap allocation, another speed win.
As far as compilation goes, Java compilers don't extensively optimize. Java optimizations typically occur at run time, which gives you a far greater range of possible strategies than the static compile time optimizations that are possible with C. Some people now think that run time optimization will eventually lead Java to be a higher performance language tham C.
I don't believe java can be as fast as native code, although probably extremely close.
It will be interesting to see how this works out, I'm betting that for a significant class of problems, large general purpose software, Java's runtime optimization will make it a clear winner.
For small programs that can fit in a CPU cache though, I think Java will be slower to overtake C, if ever.
Wow, what a crock (Score:4, Informative)
The article says "Runs somewhere between 60 and 85% of the speed of the original", and this is on modern hardware.
Let's see how it performs on hardware that was actually used to play Quake 2 before we start lying about how fast java is compared to the native code. When the hardware in question is capable of pulling 300 frames per second, it's pretty damn likely it's not even being used to its full potential. Even the K6-2 machine was getting near 60fps. The only people who got 60fps in Quake 2 when it came out were the people with monster machines.
Yes, sorta (Score:3, Informative)
Sorta. There are numerous games out already that are based on Java. Pretty much all of Popcap [popcap.com] uses Java. Java is also used as a scripting language for several games (sorry, no links), as an alternative to Python, Lisp, C++, Lua or any other interpretive language (or home-brewed language).
However, it will be a very long time (if ever) before developers switch over to Java as their language of choice. Why? Because it is only the last generation or two of games that have started to use C++.
Game developers are constantly trying to push the edges of what can be done within current hardware limitations. The problem with languages that do a lot for us is that... They do a lot for us. Which is nice a lot of times. But always seems to happen at the most inconvenient time (like when we're doing matrix operations, or animating units).
Re:Native Libraries? (Score:3, Informative)
First Generation Java Games (Score:4, Informative)
The first commercial Java game was Tom Clancy's Politika, published in 1997. This was followed by Tom Clancy's Ruthless.com in 1998, and Shadow Watch in 1999. I'm not exactly sure what the comment above means, but personally I consider those games first generation. They were burnt onto CD and sold in stores like many a C or C++ title.
Whereas some C/C++ games have used Java as a scripting language, the approach of these games was to use Java for the core game loop and game logic, and to write new native libraries for the performance heavy stuff like graphics and sound. For Politika, we wrote our own movie and sound code (for both PC and Mac) because Java didn't have very good support at that point. We almost got some faster and leaner 2D graphics support in there too, but ran out of time. This approach was written up for a paper (Writing Java Games: How We Did It), which was presented at CGDC 1998.
In Ruthless.com, the native libraries were improved and the 2D graphics support was added. Basically a wrapper was created around DirectX using JNI. In addition, the whole game was compiled to native code instead of using the Java VM. This whole system hit its peak with Shadow Watch, which is an awesome little turn-based strategy game; think Rainbow Six Tactics.
So this has been possible for many years -- it's just that nobody's carried it on. The big accomplishment here is that they may be using only Sun libraries, which only means that Sun has finally gotten their act together and put out well-optimized code.