Unofficial Quake3: Arena Specs ============================== rev 0.4/9900504 [1] Introduction ---------------- This is a simple working notes file I keep for my own purposes, it might be handy for others. It is currently not sorted, but will be soon. With a nod to Matt Fell - without his "Unofficial DOOM Specs", a lot of things wouldn't have happened. [1-1] Conventions ----------------- In this document, Java data types are presumed: if given as C code, we use JNI types: jint is 32bit integer, jlong is 64bit integer, jybte is 8bit, jshort is 16bit. Java integral types are signed (the 16bit jchar type is unsigned), but C data might not be. If given as Java code, we use int,short, float etc. [2] Resource Files ------------------ [2-1] PAK File Format --------------------- PAK files are ZIP archives. There is a number of subdirectories in the archive. Archive: pak0.pk3 Length Date Time Name ------ ---- ---- ---- 0 04-23-99 22:12 gfx/ 0 04-23-99 22:12 gfx/2d/ TGA files 0 04-23-99 22:12 gfx/colors/ TGA files 0 04-23-99 22:12 gfx/damage/ TGA files 0 04-23-99 22:12 gfx/misc/ TGA files 0 04-23-99 22:12 icons/ TGA files 0 04-23-99 22:13 maps/ BSP files 0 04-23-99 22:12 models/ 0 04-23-99 22:12 models/ammo/ MD3/TGA 0 04-23-99 22:12 models/flags/ MD3/TGA 0 04-23-99 22:12 models/gibs/ MD3/TGA 0 04-23-99 22:13 models/mapobjects/ TGA 0 04-23-99 22:12 models/misc/ MD3 0 04-23-99 22:12 models/players/ various 0 04-23-99 22:12 models/powerups/ 0 04-23-99 22:12 models/powerups/ammo/ MD3/TGA 0 04-23-99 22:12 models/powerups/armor/ MD3/TGA 0 04-23-99 22:13 models/powerups/health/ MD3/TGA 0 04-23-99 22:12 models/powerups/holdable/ MD3/TGA 0 04-23-99 22:12 models/powerups/instant/ MD3 0 04-23-99 22:12 models/weaphits/ MD3/TGA 0 04-23-99 22:12 models/weaphits/bfgboom/ TGA 0 04-23-99 22:12 models/weaphits/glboom/ TGA 0 04-23-99 22:12 models/weaphits/rgboom/ TGA 0 04-23-99 22:12 models/weaphits/rlboom/ TGA 0 04-23-99 22:12 models/weapons2/ 0 04-23-99 22:12 models/weapons2/chainsaw/ TGA 0 04-23-99 22:12 models/weapons2/fister/ TGA 0 04-23-99 22:12 models/weapons2/gauntlet/ MD3 0 04-23-99 22:12 models/weapons2/machinegun/ MD3/TGA 0 04-23-99 22:12 models/weapons2/plasma/ MD3/TGA 0 04-23-99 22:12 models/weapons2/railgun/ MD3/TGA 0 04-23-99 22:12 models/weapons2/rocketl/ MD3/TGA 0 04-23-99 22:12 models/weapons2/shotgun/ MD3/TGA 0 04-23-99 22:11 scripts/ shader scripts 0 04-23-99 22:12 sound/ 0 04-23-99 22:12 sound/doors/ WAV 0 04-23-99 22:13 sound/items/ WAV 0 04-23-99 22:12 sound/misc/ WAV 0 04-23-99 22:12 sound/player/ WAV 0 04-23-99 22:12 sound/player/male/ WAV 0 04-23-99 22:12 sound/switches/ WAV 0 04-23-99 22:12 sound/weapons/ WAV 0 04-23-99 22:12 sound/weapons/melee/ WAV 0 04-23-99 22:13 sound/world/ WAV 0 04-23-99 22:12 sprites/ MD3/TGA 0 04-23-99 22:13 textures/ 0 04-23-99 22:13 textures/base_floor/ TGA 0 04-23-99 22:13 textures/base_light/ 0 04-23-99 22:13 textures/base_support/ TGA 0 04-23-99 22:13 textures/base_trim/ TGA 0 04-23-99 22:13 textures/base_wall/ TGA 0 04-23-99 22:12 textures/effects/ TGA 0 04-23-99 22:12 textures/gothic_block/ TGA 0 04-23-99 22:12 textures/gothic_button/ TGA 0 04-23-99 22:12 textures/gothic_ceiling/ TGA 0 04-23-99 22:12 textures/gothic_door/ TGA 0 04-23-99 22:12 textures/gothic_floor/ TGA 0 04-23-99 22:12 textures/gothic_light/ TGA 0 04-23-99 22:12 textures/gothic_trim/ TGA 0 04-23-99 22:12 textures/gothic_wall/ TGA 0 04-23-99 22:12 textures/liquids/ TGA 0 04-23-99 22:12 textures/organics/ TGA 0 04-23-99 22:13 textures/sfx/ TGA 0 04-23-99 22:13 textures/skies/ TGA 0 04-23-99 22:12 textures/skin/ TGA ------ ------- 39295758 639 files [2-2] arenas.txt ---------------- Arenas are defined by name, skill level, bots that might be spawned, and map to use. This is defined in 747 04-23-99 22:11 scripts/arenas.txt The configuration for a given arena is listed in entries like this: { name arena3 skill 100 bots "TimBot XianBot BrandonBot PaulBot" map "tim4" } The arena.txt in the test lists maps tim1, tim2, tim4, with skill 0 or 100, and one or more bots to spawn, for a total of 10 arenas. [2-3] bots.txt -------------- Bot logic is in the qagame DLL. The base are listed in 185 04-23-99 22:11 scripts/bots.txt as entries like this: { name BrandonBot model brandon skill 100 } Skill ranges from 100-400. This specifies which player model to use, which name to use when listing a bot for an arena. [2-4] MD3/Models ---------------- The data for each player avatar data is lumped into a single directory, e.g. for the "Visor" avatar here are some files: 0 04-23-99 22:14 models/players/visor/ 1019 04-23-99 22:12 models/players/visor/animation.cfg 3300 04-23-99 22:12 models/players/visor/head.md3 637804 04-23-99 22:12 models/players/visor/lower.md3 478460 04-23-99 22:12 models/players/visor/upper.md3 196652 04-23-99 22:12 models/players/visor/Visor01.tga 52 04-23-99 22:14 models/players/visor/head_default.skin 53 04-23-99 22:14 models/players/visor/lower_default.skin 78 04-23-99 22:14 models/players/visor/upper_default.skin There are various MD3's, and skin files for red/blue team, all for a 3-part model composed of lower/upper torso and head. The actual skin TGA files are also in this directory. Model animation is listed in 1019 04-23-99 22:12 models/players/visor/animation.cfg Layout is: 1st_frame num_frames looping_frames frames_per_sec // comment 0 30 0 25 // BOTH_DEATH1 The duration is given by frames_per_sec/num_frames. The first frame of the next entry is 1st_frame+num_frames. In some cases, animation can be looped (walking cycle etc.), so the looping_frames counter lists the cycle, which is usually identical to num_frames. In some cases, the comments state: MUST NOT CHANGE -- hand animation is synced to this The walk animation is also sync'ed with player speed. There is some information in the md3view source release by Sander van Rossen and Matthew Baranowski. Models come in three pre-edited levels of LOD: "high detail" with around eight hundred triangles, "medium" with about five hundred which is comparable to Quake II, and three hundred or less for "low detail". The three parts split the animation space into smaller, independend spaces: e.g. [SHOOT, TAUNT]x[WALK,RUN,DUCK]. The lower part is for direction of movement (e.g. strafe) and posture (crouching), the upper part for the direction the weapon is pointing, as well as taunts, and the head gives direction of view for angles where the upper torso will not follow (looking straight up will only give a small bent to the torso, not 90 degrees). There are still possible artifacts: weapon aim is done by view, so the body (torso with weapon) still would have to follow the view (at least the gun has to) or projectiles/trails will leave the barrel at an angle. [2-5] Skin Files ---------------- The actual skins are TGA files, but the *.skin files assign map TGA filenames to mesh surfaces stored in the MD3 files. The *.skin files are short text files like these: demoq3/models/players/visor/lower_default.skin l_legs models/players/visor/Visor01.tga tag_torso demoq3/models/players/visor/lower_red.skin tag_weapon l_legs models/players/visor/Visor01.tga tag_torso demoq3/models/players/visor/lower_blue.skin tag_weapon l_legs models/players/visor/Visor02.tga tag_torso demoq3/models/players/visor/head_blue.skin h_head models/players/visor/Visor02.tga tag_head demoq3/models/players/visor/upper_red.skin tag_head tag_weapon u_torso models/players/visor/Visor01.tga tag_torso Default is also the CTF/team red skin, while the alternative skin is used for the blue team. In total, a single 3-part model could refer to 9 TGA's - single,red,blue times head/upper/lower. Skins are listed as NAME for selection, if head_NAME.skin etc. are present. As John Carmack states: The necessity for skin files is that a given model may have multiple surfaces inside it with different textures. As an example, the environment mapped faceplate on the DOOM marine's head needs to be a seperate shader than the back of the head, due to the way environment texture coordinates are generated ("tcGen environment" in a shader script). Neither separating commas nor line breaks seem to be required, as long as there is some whitespace or separation. Order also does not seem to matter. You note that all three components will refer to the same TGA file, but this is not necessary: you could mix three skins for head/upper/lower by referring to three different TGA files. The MD3 files contain the 2D texture coordinates for each triangle vertex, which map to the TGA texture. Rod Green's skinning tutorial and others list a reference sheet image for the q3atest "Visor" MD3, which basically labels and names the unfolded parts of the MD3 geometry, drawn as triangles in the image (see visor_skingeom.gif for the triangle placement, and visor_skinref.gif for the names). Quoting: A-0 Front chest plate A-1 Upper arm and forearm A-2 Back plate A-3 Shoulder pads underside A-4 Buttocks A-5 Top of face's visor A-6 Right hand A-7 Face and neck A-8 Groin A-9 Knee B-0 Shoulder pad B-1 Left hand B-2 Heel hydro-ram top connection B-3 Inside thigh B-4 Foot B-5 Thigh B-6 Hip extrusions B-7 Calf and shin B-8 Heel hydro-ram bottom connection B-9 Heel hydro-ram Note that this is specific for each MD3 model, and that different geometries (different player models), or even the same geometries with different texture coordinates will require different sheets. A better naming scheme would use H/L/U prefixes for the three parts. Gibs do not refer to the same TGA's, or any skins, explicitely, so you can't do avatar-specific gibs w/o copying the MD3. As Kenneth Scott explained, they are doing a lot of "flipping", i.e. they use the same texture twice, and mirror it. If they do one arm they can flip it by just setting proper texture coordinates, and use the same pixels for the other arm. Symmetrical models benefit from this - if you use two different arms (e.g. one claw or blade), it will not work that well. Another example is doing the front of the face and then just one ear. Another possibility is rendering large blurry/single color areas by just having a small one, and use texture coordinates close to each other. Everything sits on a 256x256 texture, which is the largest texture supported by all hardware (3dfx Voodoo line limitation). In GLQuake2, the arbitrarily sized skins used with software rendering were scaled down to 128x128 for hardware, which blurred them. In Quake3, you have 4x the pixels if you manage to use all the area (not easily done), and you can triple that by using different TGA's for each part. That would give you a total of 256x256 for the head alone if you wanted to, but you could also use lower resolutions. For example, you could use a 256x256 base skin, but have various avatars use different 128x64 face textures (scanned photographs). [2-6] Shader Scripts -------------------- Q3 uses procecural textures defined by "shader scripts". See the Renderman API, as well as: "A Shading Language on Graphics Hardware: The PixelFlow Shading System", Olano, Marc and Anselmo Lastra, UNC Chapel Hill, Proceedings of SIGGRAPH 98. (available on the web, as is an earlier 1995 paper). Shader scripts combine base textures (TGA, data) by using OpenGL like semantics (glBlendFunc), multi-resolution textures ("detail") and pre-defined texture coordinate modification ("wave"), to create modified or even runtime dynamic composite textures. Shader scripts also provide runtime mesh deformation ("deformVertexes"). To get into shader programming, a look at David S. Ebert (ed.), F. Kenton Musgrave, Darwyn Peachey, Ken Perlin, Setven Worley, "Texturing and Modeling - A Procedural Approach" Academic Press 1994, ISBN 0-12-228760-6, ISBN 0-12-2278761-4 is recommended. To understand Q3 shader scripts, it is also recommended to read chapter 6 of the OpenGL "Red Book", namely the section entitled "Blending" (pp. 213-225), or even the related part of the OpenGL specs. A "shader file" is simply a text file with a bunch of "shader" entries in it. From Brian Hook's internal "Shader Manual": "A Quake 3 shader file consists of a series of brace ({ and }) delimited, line[s of] surface attribute and rendering specifications." The example below is a shader entry for a portal texture, with an alpha texture applied over it to give a sort of "TV-Static" effect. [2-6-1] Portal Shader --------------------- Example given by Christian Antkow: the "portal" texture is a special shader which is applied to the surface where we wish to see through to another area. textures/common/portal { qer_editorimage textures/common/qer_portal.tga portal surfaceparm nolightmap { depthWrite blendFunc GL_ONE GL_ONE map textures/common/static.tga tcMod scroll 1292.7 11233.9 } } [2-7] TGA Files --------------- Q3A uses TGA files. Truevision's TGA File Format comes in many variations, and many applications take some liberty in creating the files - as does the tool chain used by id software. There is usually no colormap, IFF/ID or other information in the Q3A TGA files. Exceptions like: demoq3/textures/sfx/pentfloor_diamond2c.tga include e.g. an IFF with the file name in it. In nearly all cases, id uses the following TGA formats: Type 2 32bpp e.g. /demoq3/sprites/bubble.tga Type 2 24bpp e.g. /demoq3/gfx/2d/quit.tga In few cases, other formats are used. Type 3 8bpp e.g. /demoq3/sprites/splash.tga Type 3 means uncompressed black and white/grayscale image, used here for 8bit alpha information, with 8 bit pixel size and 8bit attribute announced. This is possibly an abuse of the format - tools like pbm, xv, or gimp fail to load this properly. Type 10 24bpp e.g. /demoq3/gfx/2d/backtile.tga This is RLE-encoded, with some mere 30% savings, and seems to be the only one - possibly an artificat from writing with a different tool (config). This, too, breaks xv and gimp, as they do not seem to be able to deal with the extension following the data (in this case, appended strings like "Paint Shop Pro" and "TRUEVISION-XFILE"). There might also be bogus pixel format bit flags. Skin files (Visor1.tga etc.) have correct headers, and most of the TGA files in models/ are 24bpp. In theory, the image origin mechanism could be used for DOOM-like "patches", but the Q3A shader scripts provide a more flexible and powerful mechanisms for that. In theory, DOOM, Quake, and Quake2 textures could be converted preserving the colormap, using Type 1 (or Type 9 with RLE), effectively. This depends on the ability of the Q3A TGA loader to handle palettes. [3] Configuration Files (CFG) ----------------------------- In the PAK is a sample configuration file: 1634 04-23-99 22:11 default.cfg It has the familiar keywords: "unbindall", "bind", and the usual pre-defined commands ("god", "strafe"). Also works: set name "NN" [3-1] Lagometer --------------- From John Carmack's .plan: Interpreting the lagometer (the graph in the lower right corner): The upper graph (blue/yellow) slides one pixel for every rendered frame. Blue lines below the baseline mean that the frame is interpolating between two valid snapshots. Yellow lines above the baseline mean the frame is extrapolating beyond the latest valid time. The length of the line is proportional to the time. The lower graph (green/yellow/red) slides one pixel for every received snapshot. By default, snapshots come 20 times a second, so if you are running >20 fps, the top graph will move faster, and vice versa. A red bar means the snapshot was dropped by the network. Green and yellow bars are properly received snapshots, with the height of the bar proportional to the ping. A yellow bar indicates that the previous snapshot was intentionally supressed to stay under the rate limit. The upper graph indicates the consistancy of your connection. Ideally, you should always have blue bars of only a pixel or two in height. If you are commonly getting big triangles of yellow on the graph, your connection is inconsistant. In a heavy firefight, it is normal for modem players to see yellow bars in the bottom graph, which should return to green when the action quiets down. If you are getting several red bars visible, you may want to look for a server that drops less packets. There are a few tuning variables for people trying to optimize their connection: The most important one is "rate", which is what the connection speed option in the menu sets. We are fairly conservative with the values we set for the given modem speeds: 2500 for 28.8, 3000 for 33, and 3500 for 56k. You may actually be connecting faster than that, and modem compression may be buying you something, so you might get a better play experience by increasing the values slightly. If you connect at 50000 bps, try a rate of 5000, etc. I err on the conservative side, because too low of a rate will only make the movement of other things in the world choppy, while too high of a rate can cause huge amounts of lag. Note that the optimal rate will be somewhat lower than a rate for QW or Q2, because I now include the UDP packet header length in the bandwidth estimate. You can ask for a different number of snapshots by changing the "snaps" variable, but there isn't a lot of benefit to that. Dedicated servers run at 40hz, so stick to divisors of that: 40, 20 (default), 10. A snaps of 40 will usually just cause you to hit your rate limit a lot faster. It may be usefull for tuning rate, if nothing else. You can adjust the local timing point with "cg_timenudge ", which effectively adds local lag to try to make sure you interpolate instead of extrapolate. If you really want to play on a server that is dropping a ton of packets, a timenudge of 100 or so might make the game smoother. One more addition to net cvars: "cl_maxpackets" will restrict the maximum number of outgoing packets to prevent client to server rate problems. This does not limit the client framerate. This defaults to 20, which might actually be a bit low. You might try experimenting with raising this to 40. "cl_maxfps" still exists, but it will never need to be used for networking reasons. Q3 can run networked player movement in either an asynchronous or synchronous manner. The default mode is to allow all client movement to be done asynchronously with the servers advancement of time. The primary reason is to allow player movement to be predicted on the client side. The primary drawback is that while your movement is smooth, the other players that you see running around in the world move with a jerkiness that is relative to their framerate and network connection quality. It is NOT necessarily relative to their ping - a player on a fast system with a clean modem connection can move smoothly. If you see a player stuttering around, either they have a bad framerate, or the network connection between them and the server or you and the server is poor. The amount of stuttering is sort of the sum of the dropped or variable packets on BOTH connections. You can force Q3 to run all clients synchronously by setting "g_synchronousClients 1" on the server. This will make Q3 behave similar to Q1 for networking. All movement will be lagged except view angles, which are still short-circuited immediately. Some people claim to prefer synchronous movement when everyone had a very good ping, but I don't personally think it is ever a play benefit. It makes leading players a bit easier, but I think the crisp movement control of client side prediction is a much better tradeoff. However, there is still a reason for using it: recorded demos come out a LOT smoother looking when running with sync. Note that q3test does not allow demo recording and playback, so this is just for future reference... [3-2] String Embedded Color --------------------------- From info handed out by Dave Kirsch: Quake3 has support for embedded color codes. They are present in Q3Test. In order to say or make your name with added color, you must preset the codes in your config file. Q3Test does not allow you to have external config files, so pretty much you are restricted to editing your name in the q3config.cfg file. In order to embed the color codes, you must have an editor that lets you insert special character into a text file. In this case the character. Some editors let you insert an escape character by using a special sequence such as Ctrl-P then Ctrl-[ (Ctrl-[ is the same character code as the ESC character sequence). Your mileage may vary. The colors are: 0 -- Color 0--Black 1 -- Color 1--Red 2 -- Color 2--Green 3 -- Color 3--Yellow 4 -- Color 4--Blue 5 -- Color 5--Cyan 6 -- Color 6--Magenta 7 -- Color 7--White For example, in my q3config.cfg file, I have the following for my player name: // Zoid.BC set name "1Z5oi1d7.3BC7" Where "" is replaced with the ESC character code. Note that I added 7 at the end to return the color to white. This makes things look better. [3-3] Server Configuration -------------------------- If you are running a Q3Test server, and would like for it to report to our master server, start the server with +set dedicated 2 else (non-advertising server) +set dedicated 1 To choose which network interface q3a uses when running a dedicated server, use +set net_ip +set net_port TODO: global motd/update server. Team-mode (read/blue, say_team, messagemode2): set teamflags 3 set dmflags 1 map [3-4] Client Configuration -------------------------- Firewalls: Q3ATEST has support for SOCKS5 (RFC-1928). There are three cvars that control it. They are only settable from at init time (from the OS command line). +set net_socksEnabled 1 +set net_socksServer +set net_socksPort Please note that you use the address (name or IP number) of the SOCKS server (firewall machine), NOT a Q3ATEST server. The port number defaults to 1080, you should not need to change this. Currently it does not do any authentication. The username/password authentication method (RFC-1929) will be added. The odds of id doing the GSS-API method (RFC-1961) are not very good. Only supporting IPv4 addresses. Demo viewing: demo q3test1 demo q3test2 Third person view cg_thirdPerson 1 cg_thirdPersonRange xxx cg_thirdPersonAngle xxx FPS: cg_drawFPS 1 [4] Executables --------------- Q3A ships with one main executable (e.g. linuxquake3). There might alternatively be a dedicated server binary that is not linked against Windows DLL's or X11, and does not require CGame or OpenGL DLLs. There might also be default OpenGL DLL's for a given platform (e.g. libMesaVoodooGL.so). The refresh code is now part of the executable. Finally, there will be two DLL's (or two QVM bytecode archives, or both) for CGame and QAGame game logic. [4-1] VM/DLL Handling --------------------- The way the QA game architecture has been developed has been as two seperate binary dll's: QAGame.dll for the server side game logic, and CGame.dll for the client side presentation logic. Using DLL's has two major problems: security and portability. If a mod is not ported to a client platform, those clients will not be able to connect to a server running it. Those that can connect might end up auto-downloading untrusted binaries from an unknown source over an unsecure network - not a good idea. For that reason, the default solution for Q3A is a custom Virtual Machine (VM) that runs bytecode compiled from C sources. There will be two instances of a VM, one for CGame and QAGame each, in single player mode. The VM an interpreter for a virtual RISC-like CPU. This should have a minor speed benefit over a byte-coded, stack based java interpreter. Loads and stores are confined to a preset block of memory, and access to all external system facilities is done with system traps to the main game code, so it is completely secure. No pointers are shared between engine and game bytecode running on the VM. The engine can load either a dll or a .qvm virtual machine file. Both are interchangeable to allow for debugging using the same code base for both. Client modules can only be debugged if the server is set to allow cheating, but it would be possible to just use the binary interface for server modules if you wanted to sacrifice portability. However, certain libc and other external C functions (networking etc.) available to a DLL will not be available on the VM. You can't link against any libraries, so every function must be resolved. Functions like strcmp(..), memcpy(..), rand(), etc. must all be implemented directly. Q3A's VM and CGame source will provide code and hooks for all the ones id uses, but mod coders may have to modify their coding styles or provide standalone implementations for missing functions. A good deal of common engine code (q_shared.c) will not be accessed via the engine/game API imported/exported, but will instead be duplicated - as native code in the engine executable, and as bytecode or native code in both game DLL's. Most mods will be able to be implemented with just the interpreter, but some mods that want to do extensive file access or out of band network communications could still be implemented just as they are in Q2. Distributing DLL's will not be endorsed, they are going to strongly discourage people from distributing .dll files, and the game will refuse to auto-download them. [4-2] LCC compiler ------------------ Creating new QVM files for Q3A will require that you install LCC, which is to be used to generate assembly for q3asm. LCC is a retargetable compiler for ISO/ANSI Standard C. The programming language for QuakeArena mods is interpreted ANSI C - the double data type will be missing, as will many external C functions you have gotten used to, but otherwise it should be conformant. LCC was written by Chris Fraser and David Hanson (while at Princeton, both at Microsoft now). See: ftp://ftp.cs.princeton.edu:/pub/packages/lcc/ http://www.cs.virginia.edu/~lcc-win32/ news://comp.compilers.lcc (unmoderated USENET newsgroup) LCC is described in the book "A Retargetable C Compiler: Design and Implementation", Hanson/Fraser, Addison-Wesley, 1995, ISBN 0-8053-1670-1. The book describes the v3.6 source code. The FTP distribution includes a PDF sample chapther of the book and other documentation, the v4.1 source code and binaries for the complete compiler, the code generators for all its common targets (ALPHA, SPARC, MIPS, i386, not Q3A), and the code-generator generator that produced them. [4-2] Q3ASM Bytecode Compiler ----------------------------- Q3A will have a tool called q3asm, which will map the LCC generated files to bytecodes understood by the Q3A VM. This tool depends on the details of the Virtual RISC CPU. In theory, it would be possible to create i386 code using LCC and its i386 backend. Another possibility is using a tool to compile existing bytecode from a mod the source of which is not available, to native i386 code. However, in most cases, it will be better to use GCC, DJGPP or other standard compilers to create a DLL. [5] QAGame ---------- The server side game logic. Has a Bot interface. [5-1] Bot AI ------------ According to John Cash, the bots do not use waypoint navigation. Bot navigation data has to be provided for maps, and is arena specific. The bots do not just have a simple 1 to 5 deal on their skills base. They have 12 to 14 different attributes. Some of them are simpler such as aiming skills, aggression, intelligence, manoeuvring. The bots can also have a "philosophy" (tactics, behavior patterns, personalities). [6] CGame --------- The client side representation logic. [7] Rendering Architecture -------------------------- These are notes complenting John Carmack's GL driver Optimization paper and Brian Hook's GC talk, from e-mail and other sources: We don't use interleaved vertex arrays. Because of the multi-pass organization of the shaders and optional multitexture collapse, there is not a one to one mapping of coordinates, colors, and texcoords. The renderer gathers everything that shares a shader defination and a coordinate space into large vertex arrays before passing a large batch to OpenGL. It would not make sense to set up interleaved arrays on a per-primitive basis. Particles are now complete gone from the engine, replaced by the more general sprite entity type. Now that there is no performance difference between drawing a dot and an arbitrary texture mapped triangle, the old particle model doesn't make sense. There is no runtime LOD on the curves, they are tessellated at load time. Video system manual control and restart: r_glDriver vid_restart or, at OS command line, +set r_glDriver The search path for a Win32 LoadLibrary (Q3A does not specify a path) is: 1. application directory 2. current directory 3. windows system directory (fetched from GetSystemDirectory()) 4. windows directory 5. the system path [9] Console Commands -------------------- Type "exec democycle" to watch a demo. TODO: "timedemo"/"timerefresh" You can bias the level of detail lower than allowed in the menu with "r_lodbias 2", which will force all models to the lowest lod. The view weapon will look very ugly. Another little speedup option that isn't offered in the menus is: "cg_simpleitems 1" this removes the extra rings and spheres around some items. You can also turn off all the gibs with "cg_gibs 0". If you experence a tearing problem possibly due to vsync problems, try at the console: "r_swapinterval 1". To enable stencil buffer shadows (which are available only one some cards, like TNT), you must be in 32-bit mode. Then do the following at the console: r_stencilbits 8 // default 0 vid_restart cg_shadows 2 // stencil shadows To try a benchmark run: cg_drawfps 1 timedemo 1 demo q3test1 It will load up, then hang for a minute or so, then continue. team s = spectator mode! cg_drawfps = show your framerate r_railcorewidth r_railsegmentlength cg_railtrailtime = all visible railgun graphic adjustments. cg_gibs = turn on or off gibs cg_footsteps = turn off your own footsteps, people still hear you though. cg_bobroll, cg_bobup = client view bouncing and rolling adjustments cg_gun = turn the weapon model on or off crosshairhealth = crosshair changes color to reflect your health (on or off) r_dynamiclighting = dynamic lights cg_thirdperson = gee, I wonder Affect rendering (triangle strips): r_drawstrips 1 Logging: quake3 +cvar_restart +set logfile 2 creates ./?/QCONSOLE.LOG [A] References -------------- See above for URL's and books. [C] Credits ----------- Many people have contributed to this document and the accompanying files, some knowingly, some not. I took quotes out of .plan files and e-mails, and from web pages, and fetched GIF and JPEG files where I found them. The web is anything but reliable and persistent. In no way I am making any claims on ownership or copyright. This collection is what I found useful, plus some personal working notes, made available so that others don't have to shop around for endless hours.