Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

I've been poking around the source since yesterday afternoon (late as usual slashdot) and it's generally MUCH cleaner than Q2. Things are well organized, categorized, and sensible. The id penchant for clumping a dozen header files into just one continues, but overall it's easy to find the code you're looking for. Hell, it took me 3 days to find the BSP code in Quake 2 because they had called it model_t or some such meaningless thing. I can see why Q3 was so popular for licensing, despite being in C. Indeed, it's some of the cleanest C code I've seen laid out to date. Naturally there are hacks here and there, and a few very weird design things...and the C versions of what would in C++ be inheritance and aggregation are hilarious. Overall though, I think this code is going to go a lot farther than Q1 or Q2 source ever did. Compared to everything else out of id, this source is really quite nice. No stretches of pages of uncommented assembly code. Most functions have documentation if it's not obvious what they do. All of the members of the major engine structs are well commented, for the most part.

In short, I like. 1 thumb up. (Hey, it's still C, and I'm a C++ guy in and out.)

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

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:-/

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.

I've also had the engine source for over a year under contract with Id/Activision so I could write this [anime.net]. You might have heard of this little get together called Quakecon [quakecon.org]. It was used to broadcast the qualifier and tournament matches.

Care to tell us what exactly is your experience with the q3 engine code?

OK - so where *can* someone find good example of C code? I have read that a good way to learn C is to download the source to a program that you respect and then get a feel for that and try and extend that. First three programs I try: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 everywher

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?

In this day and age of everyone trying to patent this, litigate that, and everything in between, it's refreshing to see a company, that really doesn't have any motive to make any money off of this, AND in an industry where this concept seems somewhat unusual, release its source code, instead of letting this go off into some useless void. Actions like can only help the industry as a whole, as some burgeoning programmer will have many sleepless nights ahead spending his/her own time learning the tips and tricks employed in this source code.
Thank you.

It does seem ironic, especially since just a few comments above someone asks whether you can actually still buy it in the stores (which, having tried, I can confirm is next to impossible) that there are other companies out there who hold onto their intellectual propetry beyond reason. There are so many classic DOS games that would be great to play, but you can't buy. The games industry may have matured, but it still hasn't reached the critical level where (like movies and music) classic titles are held with

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?

One might assume that with the source being available, popular Q3 mods such as urbanterror could be released as standalone games. However, most mods depends on the PAK files from the game, which have not been open sourced.

No, id Software doesn't rule because they are open sourcing an outdated graphics engine. There will always be complainers...

They rule because they are open sourcing it to make room for cheap games based on that engine. Carmack and Co know that they don't have to give the engine out, but the people that follow their games religiously, this is kind of 'giving back to the community'. The fact this engine will be open sourced means that it can also be improved upon, free of charge. Indy developers (mind you, id Software is one of the FEW left) get a chance to develop a great game -- albeit one that lacks a bit graphically compared to the D3 and HL2 standards -- to cater to a niche crowd and make a name for themselves.

The sheer price to enter the market for game developing is HUGE. Especially when it costs more money to develop a reliable engine than to buy one from somebody else. Those engines can run into the hundreds of thousands of dollars, and for a small gaming firm, or even a lone developer, that entry fee is too high a price to pay.

id Software should be commended for their efforts to continue supporting open source, make room for solo developers, and help broaden the PC gaming genre as we know it by including those who previously had restraints on their investment into gaming.

And to those of you assholes who continually compare Doom3's engine to the Source engine, and say it sucks... just write an engine that's even half as good as the Q3 engine, and then maybe you can say what sucks, and what doesn't. Doom3 may not have been graphically spectacular in its own instance, but I have a feeling that the engine behind it will do much of what the Q3 engine did -- pave the way for amazing games, and challenge hardware AND software vendors to up their efforts to support the T&L and effects that the D3 engine is spectacular at.

Carmack also rocks for working on XFree's 3d drivers, releasing Linux versions of his games (probably at a loss) to jumpstart the Linux game market, pushing for OpenGL usage, open sourcing many of his other games...

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.

Then you have to look harder. They weren't 'commercial' in the "I can buy it at EBGames!" sense, but there are games that came out of Q2 (at least that much for sure) that catered to a niche crowd making a neat game that appealed to only a handful of people, and did well at that.

id Software is not owned by anybody. They are INDEPENDANT of other owners. For example, look at Blizzard North (World of Warcraft, etc). They are owned by Vivendi. Epic Entertainment (Unreal Tournament) is owned by Atari.

These are just a few examples. There are very few "INDY" software shops that turn out a decent game, if any game at all.

In the keynote he said they've taken all the punkbuster stuff out, so it can't connect to a punkbuster protected server (not entirely sure how punkbuster works but I can guess).
He also said he doesn't know if there will be unforeseen circumstances this way, but they are ready and willing to deal with it if this does cause an influx of cheating.

While most of you probably know this, you have to do one thing before compiling the code. The '.md' files in the lcc/src need to be converted to unix end of line characters, otherwise one of the lcc compiler programs will barf. To fix this, jump into the lcc/src directory and run this little perl function on all the files in that directory.

cd lcc/src

tcsh
foreach i (*)
perl -p -e 's/\r/\n/g' $i.unix
mv $i.unix $i
end

and btw, if there is a nice unix utility that already does this, let me know.

So far, there's three pretty major bugs that I've noticed in my limited trial.

1. Trying to ping multiplayer servers crashes the game2. 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.

The build scripts are using -Werror when you do a debug build. Debug is also the default build. So those inline assembly constraint warnings cause the build to error out.If you do a release build the -Werror is not used and it should compile. To do a release build the command is./unix/cons -- release

Or you can get past the inline assembly constraint warnings by editing the Construct file in the code directory and removing the -Werror from $BASE_CFLAGS = $COMMON_CFLAGS . '-g -Wall -Werror -O ';

1.//NOW close the fucking brush!!2. i = 0x5f3759df - ( i >> 1 );// what the fuck?3.// fuck, don't have a clean cut, we'll overflow4.// since the cmd formatting can fuckup (amount of spaces), using a dumb step by step parsing5.// fuck, don't have a clean cut, we'll overflow6.// vm fuckage7.// vm fuckage8.//FIXME: this is a fucking mess9. Note: Unix CR/LF in *.dsw/*.dsp fucks up MSVC++.10. How the fuck did this happen?11. some files, and between their revisions and ours we fuck this up.12. break;// dragged backwards or fucked up13.// FIXME: this code is a TOTAL clusterfuck14. {"rem", "Less than half a fucking man."},15. {"rem", "You're fucking dumb! Suck it down."},16.// cleaning up after merging and thinks badly fucked up17. this could fuck up if you have only part of a complex entity selected...18.// FIXME: this bend painting code needs to be rolled up significantly as it is a cluster fuck right now

I see quite a bit of BSD licensed code in there or usage thereof. Any BSD license with an advertising clausal is incompatible with the GPL (see http://www.gnu.org/licenses/license-list.html [gnu.org]) still Quake3 is licensed under the GPL. Wouldn't this be a problem?

/*-
* Copyright (c) 1992, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/

The advertising clause was officially rescinded [berkeley.edu], so it shouldn't be a problem. It should be deleted from that file, though.

I decided to take a swipe at compiling this on x86_64, but the compiler is choking rather regularly with complaints about pointer to int casts of different size. The code seems to do a lot casts from pointers to int. For instance:

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?

Pfft. 5 MB of code turns into *at most* 100MB of game binary, and that's being way, way generous. I haven't compiled it yet myself, but I'm expecting around 20-50MB.

It's the textures and models and sound that drive up the cost of the diskspace with 3D games like Quake 3. Even with texture and sound compression, and some kind of model compression, these are still huge files, and the more compressed they are, the worse your game will perform having to do decompression on the fly. Why else do you think game

Ok, what I meant was this 5 MB of code, which is the engine for the game, ends up producing a full game, which we all know has graphics and sounds that take up the majority of the space. That its looks so smal against the ending product, but is a lot of code. I guess I was being poetic, but no one picked up on it.

5MB of code.... in a zip. Thats like 30mb of code. Also, the code to the engine is alot more complicated then what you do at work (well, at least the odds are it is) and thats why Carmack is a millionaire and builds rockets for fun.

WTF does D3 have to do with this, or UE3 for that matter? According to the timestamps in the source, the last time this code was touched by id (not counting preparations for GPL release) was 2002. And the number of games based on Q3 tech...it's a massive portion of the industry. If you play any FPSes, you've probably played a game based on the Q3 engine. Call of Duty, Jedi Academy, and Jedi Outcast, for example, are fairly well known examples.

Chances that UE3 will be GPL'd: 0Chances that Doom3 will eventually be open source (minus that code they had to license or something): 1

Carmack kics Sweeney's ass. By the way, doom3 etc was designed for - you guessed it - doom3, while UE3 is designed to be used as an engine for lots of games, so its not a fair comparision. But hey, if we're going to throw around numbers, how bout you take a guess at how many games have used the Quake engines? It's pretty damn high.

Quake 1 cleanly separated the graphics code from the game code. This means that any Quake 1 mod / total conversion (and there really is no difference between a total conversion and a different game based on the same engine) benefited from every advance made to the graphics code. If you take a look at some of the things being done with Quake 1, you will find that they are quite impressive - particularly when you bare in mind that they are basing it on 10 year old software.

Not really an answer to your question, but if you're interested in these things: read ShaderX2: Introductions and Tutorials with DirectX 9.0 [amazon.com]. Although the technology presented in this book is way ahead of that used in quake 3, it will give you both a nice introduction and some hands-on examples how to do things, as well as some more in-depth stuff. I liked it very much.

For a true annotation of what's going on in the code, newsgroups will probably be buzzing about it in a short while.

most first person shooters use some form of scripting language that allows people to make quite a lot of modifications without access to the source code.

the source is valuable to the community in three ways, firstly for porting to new operating systems/architectures, secondly for making changes to parts that aren't covered by the scripting system and thirdly because it allows true total conversions to be released as standalone downloads.

It's the first guess for finding an inverse sqare root using Newtons method. We're still waiting for a mathamatitian to tell us if it's the best choice, but it works. That's one of Carmack's claims to fame in the CS world.

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)?

the reason why this code isn't in libc is because this code is an approximation (but a good one). suitable for games but bad for scientific purposes.

there are several reasons why this code exists in quake3:

1) it was written back before modern FPUs and SSE etc. nowadays doing square roots in hardware is faster, especially if you vectorize. but back in 1999 it wasn't.2) it was written for mods to use in the quake vm (quake's bytecode interpreter). an engine trap may have been slower.

Take a look at Nexuiz [nexuiz.com]. It's a free FPS arena game, complete with a selection of levels, player models, weapons, music, sound effects and a range of AI bots.

The really interesting thing is that its engine is derived from the "Dark Places" engine, which is (in turn) an enhanced Quake I engine. Over the years, the developers of Dark Places and Nexuiz have done an incredible job of bringing this engine up to date and adding high quality eye candy - it's closer to the Q3 engine's capabilities than its modest