Slashdot Mirror
Quake2 Engine In Java
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?"
Maybe this will lay waste to claims that java is slow, bloated, and sucks.
I've only recently started doing heaving Java programming, and I have to say that the language is a dream to code with (provided you use a decent IDE). There're so many classes in place already, there's nothing you can't do. I'll take it over C++ any day, and MS's MFC is horrible on comparison.
My only problem with it is the deployment; screwing with class paths and what not.
People need to realize that most of the overhead they experience with their "hello world" experience has to do with loading the classes in the beginning. Once that is done, Java performs nicely.
Sure, straight C is faster, but Java isn't the turtle everyone makes it out to be.
First released notice in May.
:-)
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
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
Does it run on a Mac? Does it run on Linux? So why bother if it already runs on Win32 anyway? The Java version runs on 3 platforms with no further modifications.
Now you can have the eye candy of Quake 2 with the speed of Doom 3!
I don't care if it's running in Java C D E or bloody Z, as long as the game runs well and looks playable (AKA not shooting green blocks to make red blocks appear with a black block and various brownish walls. ).
No gamers is going to go "Doom 3 running on Java!? I'm so not buying that!" or "Doom 3 is running only on C++ I'm not playing that!". No one but the coders themselvs and the modders will truely care what it's written in as long as it runs okay and looks good.
So gonna get modded Troll..
I like muppets.
Having worked with Java, I'd say a powerful IDE like Eclipse is a requirement.
Lots of people were writing Java code long before Eclipse was released. A random text editor (Textpad) interfacing with Java1.1 was sufficient to write and compile a lot of early java code. I think that the JRE was setup so nicely that its integration into IDE's is/was so easy that everyone writing Java is now using an interactive IDE. Its not that the language requires one, its just that thats how programming is done nowadays.
Not to mention the fact that I kinda doubt the port is being played on the same hardware that the original was played on at the time.
It had BETTER perform as good on todays hardware, and that I kinda doubt...though I haven't tried yet.
No Comment.
He wasn't stating required use of an IDE to develop Java in, he was questioning the grandparent posters statement that Java 'is a dream to code with (provided you use a decent IDE)'
No Comment.
And so Java accesses the hardware in the same manner that C or C++ accesses the hardware. So what? C relies on assembly :) The fact is that a Java coding solution, coupled with open source bindings that run on several platforms, makes a more compelling argument than a single platform C++ implementation of a game.
So, Check this for Mac compatability
but what about when Quake2 came out? The code runs at about 60% performance on today's machines. So when Quake2 was released, Quake2 Java would have broken my machine, as it barely ran the orignal Quake2 version. Java can offer portability over platforms but games often push hardware to its limits and so may raise the bar on minimum system specs.
Where did I state that J2SE came with these APIs? The JOAL/JOGL APIs are additional packages that are required to make the Java application work on the various platforms. Just like a C++ requires a OGL or DX binding. Furthermore, why is it so difficult to believe that Java may be a perfectly acceptable language for high performance game development? In fact, depending on the application, Java applications can be FASTER than compiled C++ apps. Just one of the many benefits of compiling at runtime on the actual client hardware vs. compiling on development systems and hoping for the best.
See above.
Have you actually tried it though? I did this morning and it's TERRIBLY slow.
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).
The important thing to know is that the majority of your performance gains are obtained by scheduling the hardware intelligently, keeping the CPU and GPU well balanced, i.e. busy at all times. And of course, that your tight loops are really optimized, that you do not fragment memory, etc. That, for the most part, has nothing to do with the language your using, but simply with your programming skills.
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!
Now I haven't used java since 2000, but have they fixed the seemingly random garbage collection? I remember seeing a raytraced wolfy3d java demo years back, and garbage collection would make it go to a stand still at random intervals.
when Push Comes to Shove
No, that is Logo.
Lasers Controlled Games!
A brief snippit from the developer site:
In addition the Managed C++ Quake II .NET also has an extended feature for Quake Radar.
By "ported to Managed C++" you really mean "compiled to IL to run on the CLR". There's a big difference. This code is not managed, its just unsafe code running in a VM (there was more information on this on Channel 9 last week). The radar program they created was written in managed code.
Ummm. What are all those Windows .dlls and Linux .so's doing in the distrib? I'm assuming they're for the graphics stuff... It seems you could probably get JavaScript to manage the game play if you offloaded all the heavy graphics lifting to compiled native libraries like this seems to do.
-Russ
Me
The summary says "Runs almost as fast as the original code!"
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.
Sorta. There are numerous games out already that are based on Java. Pretty much all of Popcap 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).
I currently have no clever signature witicism to add here.
I happen to know of at least one AAA game which used Java - it used it as a scripting engine.
Nihilistic's Vampire: the Masquerade - Redemption, back in 2000. As I recall, in the Gamasutra postmortem, 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.
VB is not a programming language, but a development tool that includes some sort of Basic language, in a similar way that Delphi includes Pascal.
Tr3B (Robert Beckebans IIRC) has written a Q2 clone
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.
My Karma isn't excellent, damn it! (And
And I'm a grown up, so I can *decide* if I want to use pointers, gotos, or multiple inhieritance. If you don't like these features in C++ THEN DONT USE THEM.
We may be all grown-ups, but its a sad fact of IT development that we all make mistakes, and pointers aren't an optional extra in C++, they are fundamental to the way data is stored. The use of C/C++ has been a disaster in many areas of IT, leading to buffer overruns, buggy software and virus susceptibility. (I remember spending days trying to trace a buffer overrun in a C++ program on DOS).
Unless you are writing OS kernels, device drivers or hardware controllers its hard to see why anyone would feel the need to use raw memory pointers in an application.
Why doesn't Jake2.0 support Mac OS?
Why do you care what platforms they support . Once all the bugs are out of jogl/joal it will run fine on Mac OS
The original c/c++ source compiles and runs on several platforms. THAT SOUNDS PRETTY PORTABLE TO ME.
How many layers of dust covered the average q2 cd before the source was released?
So why are we using Java to write games?
We're writing games now?
Its not more portable as I've just pointed out.
Err sure. Btw: How well do win32 binaries run on MacOS these days?
Its slower.
Because the difference between 296 fps and 312 fps is essential to the proper enjoyment of any game.
And I'm a grown up, so I can *decide* if I want to use pointers, gotos, or multiple inhieritance.
Of course you are. And one day, when you've had a real job you'll discover what a pain in the arse those things are when your code doesn't do what you think it should.
If you don't like these features in C++ THEN DONT USE THEM.
Quite so. On the other hand c++ without pointers would be like a dog with no legs
A language is *not* better or easier if it leaves useful features out!
Absolutly true, but I thought you were arguing for c++.
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.
It does. Please re-read these threads before posting.
Can anyone explain what the shared libraries and dlls in the compiled distribution are for? Is the Quake 2 part of the code 100% java, and are the shared libs just wrappers around the OpenGL libraries, or what?
If so, why does there have to be a wrapper shared library created to interface with the opengl libraries?
>Jake2 uses jogl for OpenGL graphics and joal for 3D
...erm...more like sticking a 302 in a Ford Pinto and still calling it a Pinto. Nonetheless, still an impressive port...props-n-hos to the Jake2 crew.
>sound. Currently supported operating systems are Linux
>and Windows2000/XP.
This isn't native swing and double buffered Jpanels
Join the Slashcott! Feb 10 thru Feb 17!
>Unless you are writing OS kernels, device drivers
>or hardware controllers its hard to see why
>anyone would feel the need to use raw memory
>pointers in an application.
Lets see, what have I done in the last few months programming games:
*Needed to get a raw memory pointer to PS2 framebuffer.
*Needed to align 16byte structures in memory from a non-aligned binary file.
*Optmised a matrix-math function to use GameCube paired singles FP instruction.
Games need to be optimised. No matter what all the Java-Fanboys in the world think - cutting edge games will always use pointers. We're programming at a level were we have to consider the cost of a *virtual* function call versus a regular one.
And guess what, our source code (C++) compiles and runs on XBOX/PC and PS2. And the browser I'm using to post this (Firefox) was written in C++, and runs on even more platforms...
Its a bad example anyway, rendering Quake2 on todays graphics hardware is virtually free. If you wanna impress me with how fast Java is, show me the Quake2 software renderer in Java, and compare *that* to the c++ version.
"My cat's breath smells like cat food." - The Tao of Ralph Wiggum.
If you wanna impress me with how fast Java is, show me the Quake2 software renderer in Java, and compare *that* to the c++ version
You mentioned doing direct access to a framebuffer. I would say that counts as 'hardware', so fits with my original post.
I can see how in your specialised area, C++ has real advantages. I was definitely not saying Java should be used everywhere. What I feel was disastrous was to use C++ for general application coding.
If you don't like Java, there are other languages which can provide safety and range-checking - Pascal for example - just as fast as C++, and the range checking can be turned off at runtime to improve speed.
As for portability, I think you are missing the point. The firefox browser does indeed run on lots of platforms, but its up to the firefox coders to ensure that, and also up to the coders to supply binaries for each of those platforms. That is a lot of work, especially for small IT companies (I know, been there, done that - had to support C++ code on different platforms with different graphics drivers). With Java (and other JIT systems) you supply one binary, and let the VM writers do the work. Your single shipped binary runs on platforms you haven't even heard about, providing there is a sun-certified JVM for that platform. I know this is not perfect in all cases, but it is still an important time saver. It certainly saves me time.
This may be irrelevant to you, but for 90% of all developers, its revolutionary.
Try loading a Doom3 or FarCry Level :) The start up time has to do with object loading and setting up the scene. C++ or Java.
Also, JAVA IS NOT INTERPRETED. It is COMPILED. It is just compiled at runtime.
Check it, buddy.s is/hallucinogenesis.jnlp
http://www.puppygames.net/downloads/hallucinogene
is it possible to write mods for jake2 like for quake2? is the code still separated in game engine and game? it would be great to write the mods in java. as a designer its hard to learn c to create your visualizations.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
A piece of software that has room for furhter improvements? Whatever will they think of next.
sudo ergo sum
Which fully functional OS would that be?k e&site=eaga p lay.php p hp
:)
Sorry, applets=applications in a browser. So here you go!
http://ea.pogo.com/rooms/roomtabs.jsp?game=ccstri
http://www.crystalsquid.com/games/tjjx/trafficjx_
http://www.crystalsquid.com/games/mt/monkey_play.
Not a Zealot, just willing to believe that Java can do more than those without any knowledge of Java believe it can do