Quake Live Won't be Written in Java - And That's a Good Thing?
- Quake2 running in Firefox 2.x
No Java
There aren't much details out there about Quake Live (formerly known as Quake Zero) yet. One of the few things that were made public a few months ago was that it won't be written in Java (nor ActionScript... haha... very funny). Some people were really happy about that. Java is slow after all, right? Even Carmack himself said so.
While it's true that Carmack said "Java is really slow"[1], he didn't mean Java in general but J2ME. And he's of course right - J2ME is slow and it really is a platform of pure horror. There are simply too many differences between all those handsets. Different resolutions, color depths, key layouts, features, extensions, glitches, processing speed, memory, and whatever else might get in your way - it gets in your way with J2ME. I salute to the bravery of everyone who's doing that stuff for a living.
Java in Theory
"Real" Java (i.e. SE and EE), however, is something entirely different. Since 1.4 (February 6, 2002) Java is pretty decent. 1.5 (September 30, 2004) improved performance again. And 1.6 (December 11, 2006) gave us another massive speed boost.
Additionally, there are now various game libraries such as LWJGL and jogl/joal/jinput. There is even a very good engine called jMonkeyEngine. And thanks to kappaOne's hard work LWJGL applets are a lot more usable now. Horray for progess!
Apart from the browser integration there is another big benefit; Java is cross-platform. Supporting Windows, Mac OS, Linux, and maybe even less popular operating systems - all of that with a single code base. It's that mythical WORA thing.
In theory all this sounds pretty good, doesn't it? But how feasible is Java really?
Java in Practice
Well, you can't tell unless you port Quake3 (the base for Quake Live) to Java first. But there is actually something which comes pretty close: Jake2 - a Java port of Quake2.
Jake2 was put into an LWJGL applet. The pak file was stripped down to a minimum, which reduced the download to about 7mb. Pack200 and LZMA compression were also thrown in for good measure.
I participated in the secret experimental testing session a few days ago. Well, ok... we were just playing some deathmatch for the fun of it. But - and that's the important part - everything did work really well. The applet worked as intended and we got some good mindless fragtastic fun - with different operating systems on a wide range of machines spread across the globe. Even switching to full screen mode worked fine.
- Figure 1: Full screen mode (1152x864)
If you take a close look at the two screenshots you can see the FPS counters. The 640x480 applet reaches 175fps and 1152x864 full screen reaches 123fps at that position. No that impressive for a gaming rig, is it?
Well, that's the interesting point here. It wasn't a gaming machine. The screenshots were taken on a 199€ office machine[2] with integrated graphics (ATI X1250). The GPU is the only bottleneck here. While Quake3 pushes more polygons, the frames per second won't be much lower since the overdraw isn't much higher. Quake3's rendering in general seems to be more optimized (more batching), which is quite advantageous if an OpenGL binding is used.
Nowadays you only need 60fps anyways since TFTs typically run at 60hz. Reaching this target with common low end hardware should be a piece of cake. Today Java would have been an excellent choice. While it's too late for Quake Live, we'll probably see other Java powered 3D web games in the future. Unlike Quake Live they will actually run in the browser (Quake Live is only launched from the browser).
Where can I try it Myself?
For rather obvious legal reasons a link to the applet cannot be provided. It was only meant to be a private proof of concept and that will never change.
Footnotes
- ^ John Carmack - Cell phone adventures
- ^ AMD Athlon64 X2 4200+, upgraded from 512mb to 2gb DDR2 800 (the 199€ machine comes nowadays with 1gb), ATI X1250
Comments
link to JOGL applet
if you have RE6 U 10 and firefox 3 installed, check out this Jake2 applet:
http://download.java.net/javadesktop/plugin2/jake2/
(uses jogl&joal)
Compatibility
That one doesn't seem to work for anyone I know. LWJGL's applet stuff is more compatible in general since it doesn't use any AWT context or message passing anymore.
Thanks for the pointer though. :)
really?
JOGL is not compatible because it uses AWT? I know no one who has problems with JOGL but not having problems with OpenGL in general on his/her system (if you pass -Dsun.java2d.noddraw=true everything works fine).
(on older JREs (<5.0) you will probably have some issues with fullscreen mode - thats true)
I tested it on Geforce7/5, FireGL1000 (very old), ATI X1600 mobile and on two PCs with on-board intel chips without problems. I would be interested in the hardware configuration where LWJGL with its native window works but JOGL on top of AWT not (on Java 6).
What is the FPS currently
What is the FPS currently for? Just standing there? Or is it actually doing something?
If it's just standing there, way to go on absolutely abusing statistics to promote your own agenda.
If it's actually doing something (firing, moving, enemies on screen, etc) then I will be impressed.
re: really?
The AWT context and message pumping was the source of some glitches over at LWJGL. Things are working a lot better now. On of the issues was a 100% CPU lockup on mouse enter with Radeon 9100 (8500) cards on 2k/xp with the latest available drivers (they weren't updated for a few years). JOGL had the very same problem. There were also other configurations with similar or identical issues.
With LWJGL all of this seems to be gone now. Less potential error sources = less issues.
Compare CPU and memory use to the original game
Compare CPU and memory use to the original game, and the Java version will suck ass in comparison.
Another Java Game Engine that is very good
http://www.xith.org
re: What is the FPS currently
Everything is rendered over and over again. Looking around or walking around doesn't change this. The frame rate does go up and down depending on the PVS stuff. E.g. if you're looking at a wall the frame rate goes up and if there is more geometry (a representative view was chosen for the screenshots) the frame rate goes down.
Firing weapons for example has basically no impact at all. It's too little geometry to change anything. And usually it also won't require much additional fillrate.
During deathmatch it never dropped much. Maybe down to 140fps with the 640x480 applet.
re: Compare CPU and memory use to the original game
>Compare CPU and memory use to the original game, and the Java version will suck ass in comparison.
And? No one will give a damn. Even if it would use 512mb (max heap was 64 though) and 5 times as much CPU most people won't even notice that. CPUs are bloody fast and ram is ridiculously cheap these days.
You only need to reach 60+fps on common low end hardware. That's it. Everything beyond that point is rather pointless.
And as I said the bottleneck was the GPU. Using C or even ASM doesn't help there.
What is the FPS currently
What is the FPS currently for? Just standing there? Or is it actually doing something?
If it's just standing there, way to go on absolutely abusing statistics to promote your own agenda.
If it's actually doing something (firing, moving, enemies on screen, etc) then I will be impressed.
you are an idiot.
re: What is the FPS currently
"If it's actually doing something (firing, moving, enemies on screen, etc) then I will be impressed."
Then impress yourself and just test it! :-D
Just let it run the timedemo (which has of course all the firing and moving etc that you want), compare it with the original and you'll see that Jake2's frames per second is about the same as the original C code. Sometimes slightly less, sometimes even slightly more, depending on your setup.
I tested on 2 machines, and (perhaps surprisingly) Jake2 is slightly faster than Quake2 on one of them (by a really small amount but there you go), on the other slightly slower (also by a small margin).
The benchmarks on the jake2 homepage also show similar results, although I don't know if that was tested with using timedemo.
And then again (as jh pointed out) even if it were really much slower, nobody would probably care nor notice as the original is an old game with rediculously low system requirements by today's standards, so the 'magical' 60fps are easily achieved.
Anyway the fact remains that I can't tell the difference between Jake2 and Quake2.
RE: Compare CPU and memory use to the original game
I really, really don't care - honestly... mayhap we should right it in assembly etc, etc; we all know where this argument goes. User experience is the main thing, if it runs and is enjoyable so what?
Not impressed
So I can play a 10 years old game on a computer that is much much faster than the machines 10 years back?
Why should I be impressed by this? Only because I can start it from a browser? Sorry, but that is no argument for me.
And why do you tell us about 640x480? Today nobody wants to play in this resolution especialy if your native resolution of the TFT is 1600x1200 or something along this. I expect it to work at this resolution with playable fram rates. I mean ... com on .. a ten years old game?
re: Not impressed
>And why do you tell us about 640x480?
Because that's the size of the applet. It also shows how the fps are limited by the fillrate of the puny integrated GPU.
>Today nobody wants to play in this resolution especialy if your native resolution of the TFT is
>1600x1200 or something along this. I expect it to work at this resolution with playable fram
>rates.
If your graphics card offers enough fillrate, it will run fine at that resolution. Pretty odd that you don't even understand that.
Quke3 viewer written in Java
I tried to remake Quake3 in java a few years back. The graphics is fairly complete, although the game is not. The framerate is about the same as on the original game.
http://home.halden.net/tombr/squareheads/squareheads.html
re: Not impressed
It only runs at 640 * 480 when its embedded in the browser as that is a reasonable size for an embedded game. If however you switch to fullscreen (that is on the fly from the browser) it'll match your native resolutions and so yes will be running at 1600 *1200.
Why are people so nasty about it?
So, you disagree with someone, but why get so worked up about it. Time to chill out.
re: Not impressed
> So I can play a 10 years old game on a computer that is much much faster than the machines 10 years back?
Yes. AT THE SAME SPEED AS THE ORIGINAL C AND ASSEMBLY PERFORMS ON THE SAME HARDWARE.
Be impressed or be ignorant. Your choice.
My God!!
That's powerful stuff!!
It amuses me that some people commenting to this blog and acting as if they know something, cant even comprehend the sheer potential of this.
Congratulations to the dev team!!!
re: My God!!
Yes, it's very powerful indeed. Especially if you consider that most web or shareware games are a lot smaller in scale than Quake2. Doing something similar requires a big skilled team and lots of time. About 2-3 years if they are fast and working full time. Many people seem to underestimate the amount of required resources.
While it's possible to spit out massive amounts of geometry (e.g. a nice looking cathedral level with Gothic architecture touches), you won't actually do that because it's simply too expensive to create. Even the level of detail of Quake2 or Quake3 is a bit far-fetched from a realistic point of view.
Everything I could ever do requires about as little geometry as a simple PS1 game. After that point content creation becomes an even bigger issue. Additionally, the size of the download would increase too much. No one wants to waste half of his/her coffee break with a download. Things have to be quicker if you want to fill some short slice of spare time.
Most of the negative comment writers seem to get the scale wrong by several orders of magnitude. It really isn't about the next AAA game. Those won't run in a browser.
By the way I tried to clarify some of the points in a follow up article.
re: My God!!
Its even more interesting since Quake 2 deathmatch is a client/server game and since its in Java, you can deploy a client anywhere on any popular OS and browser, correct?
Additionally, the size of the download would increase too much.
Is it not possible to save the applet so it will download once and just stream the important thing/updates when it requires them?
It really isn't about the next AAA game. Those won't run in a browser.
But a very accessible, moderately sophisticated graphical app/game with client/server capabilities looks very promising.... *gasp* an MMO!?!
lol :)
re#3: My God!!
[...]since its in Java, you can deploy a client anywhere on any popular OS and browser, correct?
Yes. As I said we were using different operating systems and browsers and it worked really well.
Is it not possible to save the applet so it will download once and just stream the important thing/updates when it requires them?
Yes, they are cached and only changed jars (or whatever) are downloaded if the cache is primed. But even AAA demos exceed 2gb(!) these days. With web games you usually want to offset the hosting costs and make a profit with ads alone. So, most people would aim for something reasonable like 5mb rather than 50mb (or even more). And well, all that content has to be created first anyways.
Things are a bit different with a subscription model, I guess. But even then you probably don't want excessive download times.
[...]an MMO!?!
It would be a great choice for MMO stuff. However, as we all know MMOs aren't really feasible for most people/teams. It's simply far too much work. It also requires a big set of skills, a good infrastructure, and yet another pile of money to get it going.
lol :)
Indeed. ;)
This is great
This is just great. I'm waiting for the time when Java becomes the standard for game development. It's a pretty good technology. Developers' attitude towards its performance is too hyped though.
Post new comment