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:5, Informative)
Re:Java != Slow (Score:2, Insightful)
I would be more inclined to agree if this story were on the main page.
Re:Java != Slow (Score:2, Flamebait)
Until you run it on a 500-mHz iBook, don't make that claim.
Re:Java != Slow (Score:2)
That would be a fair comparison.
But yeah, wonderful point I wish would be conceeded before comparisons are made.
Re:Java != Slow (Score:2)
Can't find one? Neither can I find a P233/64MB
any more.
But yeah, what the world needs is a good 50k VM.
Re:Java != Slow (Score:1)
I found it in the garbage.
Re:Java != Slow (Score:1)
Actually, I've got a K6 200 that first ran Windows 95 OSR2, then ran Linux. Still not sure what to do with it now.
Re:Java != Slow (Score:1)
Up until a few weeks ago, when I found the majority of the parts in the trash, the box was a P 100, with 32 MB of RAM.
I'm running Slack 8 on it, and it runs perfectly well. Once upon a time, when it was the P 100, it ran Win95B, and had a security camera attached that was known by those not in the know as
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 + C != Slow (Score:1)
Re:Java + C != Slow (Score:1)
Re:Java != Slow (Score:5, Interesting)
Re:Java != Slow (Score:5, Funny)
I hear ya, man. I did Java programming once and it made me heave.
Turtle language (Score:5, Funny)
No, that is Logo.
Re:Java != Slow (Score:1, Flamebait)
Well, it may lay waste to claims that Java is slow, but I think it's hard to argue that it's not bloated. And, of course, Java does suck for rapid prototyping. However, it doesn't suck so much in other contexts.
Mostly, I just wanted to type the word suck.
Re:Java != Slow (Score:2)
And, of course, Java does suck for rapid prototyping.
then look for a better IDE or better RAD tool. There are plenty.
angel'o'sphere
Re:Java != Slow, but that doesn't mean it's good. (Score:2)
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.
Re:Java != Slow, but that doesn't mean it's good. (Score:2)
Re:What?! (Score:2)
It had BETTER perform as good on todays hardware, and that I kinda doubt...though I haven't tried yet.
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 exi
VB a language? (Score:1)
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.
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:Java != Slow (Score:2)
Oh, it's definitely noticable, even on the server. For our use, anyway. Unfortunately.
We're trying to run IBM's WebSphere Portal and Lotus Workplace Manager, both of which are written in Java. The web server is a dual Xeon 2.4 GHz with 4 GB RAM and SATA drivers. The database server is also a dual Xeon 2.4 GHz with 2 GB RAM. Both are running RedHat Enterprise Linux 2.1 AS. Get three people signed into Workplace,
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:0.9.2 version released (Score:5, Funny)
I guess that's why they didn't port Wolfenstein.
[FFFish waves good bye to his karma...]
Re:0.9.2 version released (Score:2)
Well, it is of course possible that the game was an illegal copy anyway. I don't really know. At that time I didn't really understand any copyright stuff as I do now, and I couldn't discuss with the boy who played it, as I was only somet
Re:0.9.2 version released (Score:2)
Or the shareware version.
Re:Quake II .NET (Score:1)
Re:Not cross platform, so why java? (Score:1)
Re:Quake II .NET (Score:1)
Re:Quake II .NET (Score:3, Insightful)
Hooray (Score:4, Funny)
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:1)
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.
Re:But do we care? (Score:2)
I'm no java expert ( I'm a rabid portable C/C++ guy... ) but it looked like the opengl bindings loaded by webstart weren't compatible. Could be a packaging error (x86 native JNI binary?), or it could be any number of things.
Anyway, I still think it's incredibly cool.
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:But do we care? (Score:2)
The performance is alright now... (Score:3, Insightful)
Re:The performance is alright now... (Score:1)
Re:The performance is alright now... (Score:1)
Also, Q2 was written for a time with significantly different CPU:GPU performance ratios (eg before Hardware transform & lighting) so the benchmarks don't mean much.
I have seen JOGL and I am quite impressed with it, I wouldn't be suprised to see multithreaded Java bein
Re:The performance is alright now... (Score:2)
Re:Why Java ? (Score:1)
The language does not always matter (Score:5, Interesting)
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!
Re:The language does not always matter (Score:2)
Re:The language does not always matter (Score:1)
When you write code in C, it translates pretty naturally into machine code.
With C++, some unexpected stuff can happen. Implicit conversions, temporary objects, late binding when resolving virtual methods, etc. But if you know what you're doing, you can still pretty much avoid the C++ gotchas.
In Java, there is even more unexpected stuff that happens behind the scenes, and that's sorta of
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-P
Re:The language does not always matter (Score:2)
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.
Re:The language does not always matter (Score:2)
Re:The language does not always matter (Score:2)
What really bothers me is how rarely (if ever) a Java or C# program will release memory back to the system. It seems that they just take more and more resources away from the system and never release it back. This combined with a lazy garbage collection and programmers that don't worry about memory makes many Java programs horribly bad neighbors to other processes running on a dekstop.
And how exactly does a C/C++ program release memory to the system?
By calling strunbrk() or what?
Future operation systems,
Re:The language does not always matter (Score:2)
With delete/free maybe? Freeing the memory explicitly allows the OS to decide when it will reallocate that memory to something else, rather than the VM, which has no knowledge of other processes.
Even if you have enough swap, wasting available physical memory will kill performance as the OS swaps data in and out.
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:2)
The fact that many OS's will not *actually* release the memory straight away if there isn't much pressure on memory in order to reduce memory fragmentation and speed up allocations for the program doesn't alter the fact that it is at least available - you don't have a second operating system running inside the main OS.
Re:The language does not always matter (Score:2)
AFAIK, freeing the memory marks it as available for the OS to reuse elsewhere.
Yeah, but that is wrong
Freeing the memory with free() makes it available again to: the process/the application. The "swap space" a process uses gets onyl reclaimed when the process terminates.
Your original argument was something about Java and freeing memory. So while the Java language don't has a "free" keyword or function, the Java VM uses garabge collection to support Java programs. And? Guess what, the VM uses free() t
Re:The language does not always matter (Score:2)
I suppose next you're going to complain that they mmap too much memory when they start up. The fact is this is done to get the best performance out of the VM systems of modern OSs. The vast majority of garbage-collected runtimes do not release memory given by the OS based on the very safe assumption t
Re:The language does not always matter (Score:3, Interesting)
Actually on mobile phones, where you're working with extremely limited hardware and very little RAM, it's common practice to force the garbage collector to run regularly. I usually call the gc in the central game loop to prevent "hitches" during play as a large(ish) block is freed up randomly.
Since just about every game I've written is under 30k in size (including graphics and sound), and mo
Re:The language does not always matter (Score:1)
Do you work at Microsoft by any chance?
Re:The language does not always matter (Score:3, Insightful)
Here's a hint: it happens after you've allocated too much memory. Even if you are so deprived that you can't even turn the garbage collector on and off, if you don't allocate in your inner loop, the garbage collector won't kick in! Who would have thought? In Java allocation is very easy to control (a big reason for this has to do with it's separation of built-in types and classes), and as long
garbage collection? (Score:3, Interesting)
Re:garbage collection? (Score:2)
Re:garbage collection? (Score:2)
Re:Nah, not really (Score:1)
http://www.puppygames.net/downloads/hallucinogene
Re:Nah, not really (Score:1)
Sorry, applets=applications in a browser. So here you go!
http://ea.pogo.com/rooms/roomtabs.jsp?game=ccstrik e&site=eaga [pogo.com]
http://www.crystalsquid.com/games/tjjx/trafficjx_p lay.php [crystalsquid.com]
http://www.crystalsquid.com/games/mt/monkey_play.p hp [crystalsquid.com]
Not a Zealot, just willing to believe that Java can do more than those without any knowledge of Java believe it can do
High performance Q3/D3 graphics engine (Score:4, Informative)
A brief snippit from the developer site:
Re:High performance Q3/D3 graphics engine (Score:1, Troll)
Re:High performance Q3/D3 graphics engine (Score:1)
Havn't you seen Fast and Furious?
Re:High performance Q3/D3 graphics engine (Score:1)
I just assumed they were ricing up shitty cars...
Native Libraries? (Score:2)
-Russ
Re:Native Libraries? (Score:3, Informative)
Re:Native Libraries? (Score:2)
Re:Native Libraries? (Score:2)
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.
Re:Wow, what a crock (Score:1)
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:Yes, sorta (Score:1, Interesting)
There are games and then there are games :) One should make difference between traditional rich games (sold in boxes at store shelves) and small games (browser games and mobile J2ME games). Popcap seem to be designing the latter. The amount of work for browser games is not comparable to rich games. Browser games are simple, taking maximum few months to develop. Rich games cost average 5 million dollars [dfcint.com], have h
Vampire: the Masquerade (Score:3, Interesting)
Nihilistic [nihilistic.com]'s Vampire: the Masquerade - Redemption [nihilistic.com], back in 2000. As I recall, in the Gamasutra postmortem [gamasutra.com], 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.
Re:Vampire: the Masquerade (Score:1)
Re:Vampire: the Masquerade (Score:1)
Re:Vampire: the Masquerade (Score:1)
Re:Vampire: the Masquerade (Score:2)
Nothing new (Score:3, Interesting)
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.
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.
Compiled code in the distribution (Score:2)
If so, why does there have to be a wrapper shared library created to interface with the opengl libraries?
Not all native Java code (Score:1)
>sound. Currently supported operating systems are Linux
>and Windows2000/XP.
This isn't native swing and double buffered Jpanels
what about mods? (Score:1)
Room for improvement, eh? (Score:1)
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 trac
Re:If Java is so portable... (Score:2)
>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 Ja
Re:If Java is so portable... (Score:2)
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
Re:If Java is so portable... (Score:2)
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
Re:If Java is so portable... (Score:1)
Re: Chrome is a example. (Score:1)