Cool, thanks for your answer. Also, that code is quite possibly the console that appears when you launch the game. I had forgotten about it. I'd say you are right about that.

A few things...

So i've never attempted to mod quake3 but did a little quake 2 copy and paste modding back in the day. I read a few tutorials online, and they are ok ways to get understanding of the quake3 source code, engine and game. Then i broke down and bought Focus on Mod Programming in Quake III Arena. Regardless of the amazon comment that it was just a copy and paste of tutorials, it is very informative and i like it.

So i'm hacking around in the game code, and all is well, but what i really would like some info on is the audio portion of the engine, and the rendering portion. I haven't fired up the sources yet, but i am guessing that the audio and graphics rendering is abstracted from the OS it runs on? am i right? i should i expect to see three implementations of the audio and rendering code, one for each OS?

One last note...
http://quake3.quakesrc.org/wiki
make a contribution - I did.

~It's time to get OS X a damn good engine, we need to squash some bugs first.~

I actually think this code is a lot more readable than the Quake 2 source code, admittedly your still gonna have to spend some time going through it to see how it all fits together but thats to be expected with any large piece of software.

who says the big pro's make neat code?...lol
neat code is for people with loads of time, game devs dont always have forever to decide on ways to make their code pretty

and if the game code works and never crashes then thats all that is required

when is the last time a game was a smashing hit because it had pretty source code?

Well-organized code can actually make development faster.

It's not as disorganized as most people think it is. Remember, they have to read it too! I'm just amazed that only a few guys wrote and debugged all this code.

For those that are interested:

1) Look in code/win32/win_input.c for information on how Q3 handles input in windows with DirectInput.

2) For those that wonder how the pros initialize OpenGL, this is copied and pasted straight from my notes I made while digging through the source code (so it's not pretty).

InitOpenGL – code/renderer/tr_init line 190  GLimpInit – code/win32/win_glimp.c line 1350    Get versions, vendors, extensions, chipsets.    GLW_StartOpenGL – line 1280	Attempts to Load OpenGL through various means      GLW_LoadOpenGL – line 1167	QGL_Init – win_qgl.c line 3235	  Binds a HUGE list of Quake specific function pointers to their addresses in the dll using GetProcAddress	GLW_StartDriverAndSetMode – line 90	GLW_SetMode – line 741	Inits glw_state stuff from glw_win.h.  Fullscreen mode and all the good stuff.  GLW_InitExtensions – line 961    Inits exts (multitextures, compiled Vertex arrays, etc.)

At id, they seem to prefer using their own function pointers initialized using GetProcAddress() and DLL's (look in win_qgl.c) instead of the library functions.
i.e. qglVertex3f() instead of glVertex3f().

3) To see what is done every frame, look at the Com_Frame() function in code/qcommon/common.c (line 2635).

More interesting, though, is what is done on the client-side every frame, look at the function CL_Frame in code/client/cl_main (line 1997).

Some people dig straight through this code (quite a task, believe me) trying to find some straight foward code that renders triangles, etc. You won't find it this way. Q3 rendering is not just something done by calling Render() 60 times per second, it's done through event processing, and I suggest you start there (and in the render folder) for rendering engine stuff. The main game loop simply alters game states.

The good news is that all the rendering engine stuff is part of the core game, so you don't have to dig through QVM stuff.

I want to ask how to compile the Q3 sources code?