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?"

Comments

Java != Slow

[kannibal_klown]

But I used java once, and it took forever to print Hello World. Java is slow. Java is stupid.

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

[angel'o'sphere]

MFC is wonderful compared to 6502 assembly on the Atari 800 I dare to challange that.
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

But do we care?

[Turn-X Alphonse]

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..

Re:But do we care?

[iwadasn]

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. :-)

Re:But do we care?

[kaffiene]

No, users shouldn't care at all. But I can tell that there has been huge developer resistence to the idea that Java can do games at all.

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.