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?"
Java != Slow (Score:5, Insightful)
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.
Re:Java != Slow (Score:2, Insightful)
I would be more inclined to agree if this story were on the main page.
But do we care? (Score:5, Insightful)
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..
Re:But do we care? (Score:5, Insightful)
I'm a Mac user, I care. Too often Mac games come out years late and with dozens of bugs added in just for the fun of it. If the development houses would either do as blizzard does, and develop quality software, or at least write in java so I get the same bugs as everyone else, I'll be happy.
This is after all the bottom line. I don't want to wait 4 years for a buggy Mac port to come out, and I don't want to use windows at home just so I can run the latest games. If more people went this route then it's likely that there would be more high quality games for everyone. Just write it once, release the java for OS X, Linux, BSD, Windows, whatever, and then use something like GCJ to turn your java code into a good executable for XBox or PS2. Of course I'll hear the C coders say "But C can be portable." and it can, but only if you know what you're doing and actually put in the effort. History has shown that very few people fall into this category, so we need java.
Everybody wins, especially me.
The performance is alright now... (Score:3, Insightful)
Re:The language does not always matter (Score:3, Insightful)
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 [arstechnica.com] 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.
Re:Quake II .NET (Score:3, Insightful)
Re:But do we care? (Score:5, Insightful)
That's relevant because games need good quality game libraries and noone will write them for a target they think can't cope with the task.
Re:If Java is so portable... (Score:3, Insightful)
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.
Re:If Java is so portable... (Score:1, Insightful)
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++.
Re:Java != Slow (Score:3, Insightful)
I'm not suggesting that Java sucks unless it can run on a P 233, which is how I think you took my comment.
Re:Java != Slow (Score:5, Insightful)
MFC was created a long time ago, during the 16-bit era. Thats no excuse for creating bull shit.
It made some compromises for speed (e.g. message map macros instead of gazillions of virtual functions). A virtual function is in most circumstances faster than a message map macro.
It was created before C++ was standardized, and frankly, true!
before the OO community had learned some lessons (some of which Java directly benefitted from). wrong!
When the MFC was crafted there existed plenty of better alternatives.
a) MacApp, Apples C++ Application FrameWork
b) TCL, Think Class Library, later Symantec, a simplyfied clone of MacApp
c) Borlands Application Framework
e) ET++, a cross platform C++ GUI and Application FrameWork
f) Taligent research Frameworks, off springing from ET++
g) BedRock a Borland + Apple + others attempt to make a Mac/PC cross platform Application FrameWork
Every SmallTalk environment was allready far better than MFC in the early 70ties. CLOS and other lisp derivates allready had pretty well working GUI and Application FrameWorks.
Bottom line: M$ was unable to craft a good C++ compiler. So they made a shitty incompatible slow monster with M$ specific extensions. Crafted a library relying on that extensions and sold that as "development environment".
But it provided a nice MVC framework, and handles all your menu and toolbar and other GUI stuff for you. I started with C and the Win32 API, so MFC was "a dream to code with" in comparison. I wish we would evolve from saying something sucks or is horrible, and just accept that they "are", and pick the best one for each task.
Your luck was that you did ot know better, I allways went out for one hour to hack lumber to get my agressions off, when I needed to work on a PC in 1993 till 1998 in "Windows" C++ and "Windows" libraries. Using Symnatec C++ (Walther Bright, anyone?) softened that pain a bit. The pain was further softend by using the zApp GUI libraries and not MFC. After searching 6 weeks for a good GUI Framework, the GUI of my app was made in 2 days, not with MFC, but with a true framework.
I really don't blame M$ and gates for making money and trying to dominate the market.
I blame them for throwing the whole computer age back by 30 years at least. They did so by killing so many good ideas and good companies. It took until 2000 to get again new ideas established in using and programming computers.
Now hey are copying all good ideas from unix/linux/mac os x from KDE and GNOME. If they can dominate again, by killing Sun and bying SCO, or whatever, a lot of progress will be "removed from the market" again.
Compare AppleScript versus Visual Basic. The first one is ingenious easy and the second one is ruling front end programming, but is utter crap.
angel'o'sphere
Re:The language does not always matter (Score:3, Insightful)
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
Re:The language does not always matter (Score:3, Insightful)
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!).