Slashdot Mirror
Quake 3: Arena Source GPL'ed
inotocracy writes "At John Carmack's Quakecon 2005 keynote he promised that the Quake 3 Arena source code would soon be released-- turns out he wasn't just pulling our leg! Today it was released, weighing in at 5.45mb, it makes for a quick download and a whole lotta fun. Developers, start your compilers!"
I'd like to get it but don't shop online (I know, I know, I'm being a fool), and I haven't been able to find it anywhere, even second hand. It looks like it was never released on Sold Out or Xplosiv or anything like that. Anyone know if there are plans to do any sort of re-release?
I am trolling
So what can be done with this? Since it's the Q3 Arena code, are developers limited to similar games of running around shooting each other? Or, could someone use this code and remake some older game such as Ultima Underworld?
Lollerskates.
Cleaner than q1 or q2 maybe, but it is not really a good example of clean / well written C code in general.
For example, take a look at CL_DemoFilename() for some real "OMGWTFBBQ".
I can't tell if that code is serious or a joke. But it's there.
As for stretches of pages of uncommented assembly code -- it's still there. See BoxOnPlaneSide() in game/q_math.c for example. Or S_WriteLinearBlastStereo16() in client/snd_mix.c.
I really wouldn't use quake3 source as an example of well formatted / readable code.
Well, it compiles and runs under OSX, but it's not pretty.
So far, there's three pretty major bugs that I've noticed in my limited trial.
1. Trying to ping multiplayer servers crashes the game
2. Several of the 3D models are really messed up, and some are missing. I was playing against a bunch of bodyless people... all that were present was legs.
3. The Quake 3 header on the setup screen is missing.
The odd thing, is that I assumed that since the last build to come out of iD worked great on my G4, that the source would just compile and run without problems... boy was I wrong.
Of course I compiled under 10.4.2, and I think the last time it was compiled under 10.2.x, so the difference in compilers could probably be the difference.
Ok, admittedly there are stretches where you can feel Carmack's..."magic" work. They clearly wanted to leverage MMX. But, as a whole, the engine is nicely laid out and the architecture is pretty nice. Ignoring the lower level math code -- which frankly tends to look horrendous on ANY engine, due to the MMX, SSE, and whatnot that's usually involved in production code -- things are easy to find and understand. The renderer could still use a lot more commenting as to why it's doing some of the things it's doing (the sky code, for example), but it's really not that difficult to figure it out. No, it's not the best C code on earth. But it is pretty good C code, and besides which it's probably relatively hack free compared to most production source. (It WAS intended for licensing, after all.)
Carmack mentioned during his keynote that the PSP should be able to handle Quake 3 level graphics, but I'm not sure if that means it would be able to handle a port of Quake 3.
The platform independent code is mostly ok (eg server/ and client/), but the platform specific code is an ugly mess.
:-/
While most of the code in game/ cgame/ ui/ etc are ok, most of the code in unix/ and win32/ is really ugly.
As for ugly low level C math code (game/q_math.c) most of it is actually pretty clean -- its the gobs of uncommented asm that's ugly.
The doom3 sdk is much better -- the simd asm code is in general very well commented.
But there's really little reason to use asm anymore, since the autovectorization in gcc is very nice. It also allows the compiler to optimize much better -- inlined asm functions are hard for the compiler to optimize.
As for hack free... no.. there are plenty of ugly hacks in the quake3 code. It's the nature of the beast
First off, a big thanks to John Carmack for opening doors for developers... again.
The most exciting thing about this release is the GPL'd version of QeRadiant included with it. Radiant is a tool that many professional level designers swear by. For the first time ever, it is now available for independents to use when creating content for their own games. Prior to this, you needed a license from Id Software in order to use it for commercial purposes.
I'm intrigued. If this method is faster than the `standard' one, then why isn't it in libc? After all, math.h only defines the interface, and the C standard only defines the input-output semantics, not the implementation. Is it just laziness / ignorance on the parts of libc developers, or are there disadvantages associated with this approach (other than assuming a 32-bit float size and a specific format for floating point values)?
I am TheRaven on Soylent News
Yes, there was a budget title (Paintball somthing or another) that was developed based on the Q1 source that purchased a commercial license.
We didn't charge much, but I still think they should have just saved the money and released their source.
John Carmack
Personally, I think the Q3 code is pretty clean on the whole. It was a commercial product done under time pressure, so it isn't a polished gem, but I consider it good.
Anyone working on the Q3 codebase today should just delete all the asm code and use the C implementations. Making a commercial game with fairly high end requirements go 10% faster is sometimes worth writing some asm code, but years later when the frame rate pressure is essentially gone, the asm code should just be dumped in the name of maintainability. All the comments in the world wouldn't change this decision a bit.
>But there's really little reason to use asm
>anymore, since the autovectorization in gcc is
>very nice.
I was pretty much with you until that point. I fully agree that there is little reason to use asm anymore (I haven't written any in years -- Jan Paul did all the SIMD work for Doom 3). Knowledge of asm is good to allow you to manipulate compiler output by changing your C++ code, but there isn't much call for writing it by hand.
However, autovectorization in gcc is a particularly bad argument against writing asm code. Scalar compiler code is much, much closer to hand codeed asm in performance than compiler generated SIMD code is. Optimized SIMD coding almost always requires significant transformations that compilers can't really do on their own.
The argument about inline asm hurting compiler optimizations is only true if you are trying to use short snippets of asm, which is generally a bad idea. Asm code that doesn't loop a lot isn't likely to contribute significantly to your performance, with the exception of things like ftol replacements.
John Carmack
Thank you.
John Carmack