Quake Live Won't be Written in Java - And That's a Good Thing?

Quake2 running in a browser
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.

Quake2 applet in full screen mode
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

  1. ^ John Carmack - Cell phone adventures
  2. ^ 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.

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.

About what you said about fps

I don't agree.
"Nowadays you only need 60fps anyways since TFTs typically run at 60hz"
About that, I set com_maxFPS to 125, and I notice a significant difference between 60 fps and 125 on a 60hz monitor, as it seems more fluid and I can make more accurate shots.

re: About what you said about fps

Without vsync things cannot be smooth. The reason for that is very simple: The screen is updated irregularly and incompletely. The resulting artifacts are called tearing. In a nutshell: The upper half shows the old (partial) frame and the lower one shows the next... or the upper third shows some very old frame, the middle bit shows the previous one, and the lowest part shows the current frame. There can be also 10 partial frames or even more per frame. Those boundaries also randomly jump around all over the place. Looks pretty bad, if you ask me.

If you play vanilla Q3 disabling vsync and going with 125fps is the only option though. The reason for that are broken jump physics. CPMA for example addressed this issue pretty well. That fix alone makes it look so much smoother, since the jump follows the ideal arc (instead of randomly undershooting if the elapsed msec per frame aren't favorable).

However, if vsync is disabled there are more chances to poll the inputs. For example the default polling rate for USB mice happens to be 125hz. So, if you play with acceleration and/or smoothing you might notice an improvement. (I for one dislike both settings.)

Generally I'd say that 60hz aren't enough for first person shooters, but that's all you get with usual TFTs. However, Samsung recently released a 120hz TFT called 2233RZ. Get one of those if you want real smoothness.

I want to know how ... and WHY?

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

What are the obvious legal reasons? If the author just releases the source code necessary to do this (embedded applet with the ability to go fullscreen) and not any of the copyrighted material, then what legal reasons are preventing the author from releasing this work? I want to know why the author wouldn't provide source code for work that others are looking for? This work was obviously done with the use of the Jake2 open source project. Is this because the author is a technical thug and only wants it for themselves so in their little pathetic world they are king/queen? (what is the author Bill Gates?)

sfranzyshen

re: I want to know how ... and WHY?

Well, the applet apparently did use some of Quake2's assets. These assets had to be hosted somewhere and the applet had to download them. And well, that's something you can't really do with copyrighted material.

It would have been somewhat¹ alright if it would have pulled the shareware version from id's FTP (or other sources). I.e. download, extract, and then load the pak files. However, the initial download would have been quite a lot bigger (the applet only required the files it needed and it also utilized a far superior compression scheme) and I'm not really sure if the shareware version contained any mulitplayer maps (I sorta doubt it).

[¹ Apart from the bandwidth robbing aspect.]

>Is this because the author is a technical thug [...]

Eh? What? This was just a slightly bigger (and more interesting) tech demo, which was basically only used for some compatibility testing.

Since it wasn't released to the public there is also no obligation for the author to release any of the source code.

Post new comment

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options