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.
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.
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.
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.
The usual 'support' for this argument goes: "Java programs have to be interpreted from bytecode and then run, but native code only has to be run. Bytecode interpretation slows you down.".
That seems to ignore HP Labs' Dynamo project, which showed that an HP-PA 8000 emulator running on an HP-PA 8000 could run code faster than native HP-PA 8000 code.
If interpreted HP-PA 8000 code is faster than native HP-PA 8000 code, I imagine a bytecode would have to be pretty poorly designed to perform worse. In fact, since JVM was built to be interpreted, I hope it's a lot better.
Java probably isn't the best example of this, but I see no reason why a high-level, byte-compiled language couldn't run as fast or faster than native code, assuming a standard operating system with libraries and so forth.
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.
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++.
With delete/free maybe? ... maybe not?
maybe?
To which OS exactly do you refer?
Neither: Mac OS X, Mac OS 4 to Mac OS 8, DOS, Windows (3.1, NT, 95, 2000, XP) , Unix, Linux, or Mainframe OS does that.
You simply have a misconception what freeing of memory (using free() etc.) means.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The thing to remember from all this is that the garbage collector doesn't work in a vacuum, and cannot be blamed for poor performance per se. You application and the garbage collector together form a system about which you can draw conclusions on performance. A well-written application can give hard real-time performance with a naive garbage collector, but any number of stupid things you can do while writing a program can bring even the best garbage collector to it's knees. (A fun thing to try in systems that support it - try re-defining a class to be it's own superclass. Makes a great practical joke!).
In the great CONS chain of life, you can either be the CAR or be in the CDR.