Quake 3: Arena Source GPL'ed 485
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!"
Do stores still have the game? (Score:4, Interesting)
What can be done with it? (Score:5, Interesting)
How about optimized builds? (Score:2, Interesting)
Also, will any builds made by us work with punkbuster?
Quake 3 Mods (Score:2, Interesting)
Re:What can be done with it? (Score:5, Interesting)
Re:Hmm (Score:4, Interesting)
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.
MacOSX Version... (Score:5, Interesting)
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.
Re:Hmm (Score:5, Interesting)
Re:porting (Score:1, Interesting)
Nice (Score:2, Interesting)
i = 0x5f3759df - ( i >> 1 );
Always good to know that the engine coders don't know what is going on.
Re:porting (Score:4, Interesting)
Re:Unreal Engine 4 (Score:3, Interesting)
Re:Hmm (Score:4, Interesting)
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
Radiant (Score:5, Interesting)
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.
Re:Nice (Score:4, Interesting)
Re:Nice (Score:1, Interesting)
q_math.c:
i = 0x5f3759df - ( i >> 1 );
ui_atoms.c:
sv_main.c:
ui_main.c:
ui_shared.c:
Re:MacOSX Version... (Score:2, Interesting)
I do have the full version of Q3A installed, so I just fired up the resulting binary and noticed all these problems.
The first thing I noticed is that the Quake 3 header that hovers back and forth over the setup screen (when you first log in) was missing.
Normally I try to connect to multiplayer servers first whenever I try out a Q3A update, which crashed the game.
Next I decided to tackle a single player game with bots, and that's when I noticed that the bots had no bodies or heads... just legs.
The interesting part is that the collision detection was functioning correctly, because if you tried to shoot where the body was supposed to be, you wouldn't hit anything, however going for the leg shot worked... weird.
So, I can't really offer any tips, since C is a foreign language to me. In this case I just clicked a button.
Effectively, anything. (Score:2, Interesting)
I could easily imagine someone making a isometric/topdown RPG like Freedom Force with the Q3 engine. Even though I doubt the Quake 3 engine could handle the wide-open spaces and poly counts, hell, someone could use it as the base engine for a MMORPG or something.
It's just the amount of additional coding and re-writing you want to do.
We'll probably just get a really bitchin' version of pong though. Having an engine is one thing, having artistic talent is another.
Compiling on x86_64 and pointer to int casts (Score:3, Interesting)
Emit4( (int )vm->dataBase );
but dataBase here is a pointer to a byte. It seems like he's probably trying to do something like this:
Emit4( *(int *)vm->dataBase );
Is the former line some sort of casting shortcut with the compiler that makes it do the right thing on x86 architecture, or am I missing something?
Can someone with more C-fu than I comment on this?
What I'd like to see... (Score:3, Interesting)
Re:porting (Score:2, Interesting)
-Z
Re:And that's why id Software rocks. (Score:3, Interesting)
It's also really cool that id stayed independent. In a day and age when the normal lifecycle of a game developer looks something like "release, release, release HIT, get purchased by EA", it's refreshing.
Quake 3 executable without checks (Score:2, Interesting)
1. Download the 1.32 Point Release
2. Download the Quake 3 Demo.
3. Download my executable (or compile your own) here [earthlink.net]
4. Install the Point Release and demo to separate directories.
5. Replace the quake3.exe in the Point Release directory with the one you downloaded / compiled.
6. Move pak0.pk3 from the demoq3 directory in your Demo install to the baseq3 directory in the Point Release install. (This may cause weird problems if you try to play online with the normal game.)
7. Quake 3 should now be able to play with TCs, or just the demo with custom maps, without complaining.
I can't guarantee any of this will work, but it seems to have worked for me. The reason for transferring the pak0.pk3 file is that most TCs are not true TCs, but rather use some basic files such as fonts, etc. that they load from the baseq3 directory.
If you don't have any luck with my executable, you could try producing your own. I only made a few simple changes to files.c. I commented out the following lines:
I also commented out the entire function FS_SetRestrictions and just made it return.
I have not made any changes to cd-key related code, so there may be some more work needed.
If anyone is having trouble with getting the project files to work on VC++ 6, download the following tool to convert the
Re:Unreal Engine 4 (Score:5, Interesting)
We didn't charge much, but I still think they should have just saved the money and released their source.
John Carmack
Re:Hmm (Score:5, Interesting)
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
Re:And that's why id Software rocks. (Score:5, Interesting)
John Carmack
Re:Hmm (Score:3, Interesting)
1) GNU Screen: k&r C, uncommented, undocumented mass of long functions and macros everywhere.
2) Nethack: k&r C, uncommented, undocumented mass of long functions and macros everywhere.
3) Vim: k&r C, uncommented, undocumented mass of long functions and macros everywhere.
Um... is there any application code in C out there that is even written in ANSI C, let alone well commented and understandable to someone new to the program? All the C code I look at seems to be ridden with macros which would seem to be in there for cross platform purposes - but - how do people get a feel for these macros?
Re:And that's why id Software rocks. (Score:1, Interesting)
Indie developers have to compete with the cream of the crop that comes out of EA or Activision. Comparisons between a 4 man team and a 400 man team abound when critics write their reviews. It's not always a rewarding effort.
A company like id might be indie, but they enjoy the clout of a commerical dev. They aren't totally in-touch with the indie crowd anymore. I commend them for releasing their engines to the public, but that's the cutoff line for indie when talking about id.
I make $0 for my product right now. It's an effort of love and dedication and crapshoot whether it'll make any $$$. Carmack and crew make many more dollars because they have a) money bankrolled from previous successes and b) commerical contracts because -- well, because of their name.
They may have been indie, but they are much further from indie today than when they started.
- SphericalCow