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