The Unofficial Quake III FAQ
Pre-Release v0.1



Last Updated: March 15th, 1998 GMT
Quake Quote: "Mess with me and your problems are all over... all over the floor."

1997, 1998 Richard "Sat" Connery. All rights reserved.



This document is provided "as is" without any guarantees or warranty. Although the author has attempted to find and correct any errors or mistakes he, and everyone who contributed to it, are not responsible for any damage or losses of any kind caused by the use or misuse of information in this FAQ. The author is under no obligation to provide service, corrections, or upgrades to this FAQ.



The following is legal information and refers to all the information in this document. This information pertains to all use of the FAQ worldwide. All specific names included in the package are registered trademarks and are hereby acknowledged. Any other trademarks not mentioned in the FAQ are still hypothetically acknowledged.

As long as you comply with the above rules you may do whatever you want with this document.



Sections added "+" or updated "u" since the last version of the FAQ.

Chapter I: Introduction

  1.     Foreword
  2.     Submissions
  3.     Getting the FAQ u
  4.     Credits & Acknowledgments u
  5.     History u
  6.     About the Author +

Chapter II: Basic Information

  1.     What is Quake III?
  2.     System Requirements


Chapter I: Introduction

    1.    Foreword

Welcome to The Unofficial Quake III FAQ!

The FAQ is maintained by Richard "Sat" Connery, the maintainer of The Official Hexen II FAQ and The Unofficial Quake II FAQ. This is intended to be a compilation of all the information floating around the various websites about the new game by id Software: Quake III. It's the place where all the features, news bits, scoops fall back to. The ultimate source of general information about Quake III. Please note that all text in gray are quotations and that actual content of the quotes may be outdated.

I, and everyone who has contributed so far, hope you enjoy reading it and that this FAQ ultimately answers all your questions about the game. The FAQ is now on pre game versions (v0.x format).

Strange Departures
The last few days have been hectic for the community: id Software announces American is leaving, the second Quake II demo is out and that Trinity is no longer as well as their Quake II Mission Pack that has been transformed into the all mighty Quake III. I started this FAQ to provide everyone seeking information about this new (and unespected) game from id since .plan updates and the rest of the information laying around will be forgotten.

This is a very preliminary version before I determine whether every Trinity feature will be ported over to Quake III so espect another version soon.


    2.    Submissions

If you wish to submit something to the FAQ (i.e. questions, comments or articles) then mail me and if your submission is accepted and incorporated into the FAQ you will be credited under section I.4. Please be advised each and every submission becomes the property of the author. If you wish to ask something then do but please keep it FAQ related. If you don't get a reply within two days then mail me again. Keep trying, as I do my best to answer everyone.


    3.    Getting the FAQ

The latest version of The Unofficial Quake III FAQ will always be uploaded to PlanetQuake first. You can get it as a file here. If you wish to mirror/store the latest version of the FAQ then please mail me with an elaborate request. If you're accepted your URL will go to the FAQ mirror list: - Maintained by Richard Connery [Sat]


    4.    Credits & Acknowledgments

The following people have made this FAQ a much better one than it would be otherwise:

My sincere thanks to all of these and to everyone who reads the FAQ.


    5.    History

The versions of the FAQ with the changes made in each are sorted below. The FAQ was started on 1998.


    6.    About the FAQ Author

I go by Richard "Sat" Connery and I live in Miramar, Portugal, Europe, Earth, Solar System, Milky Way, ad infinitum... My house is just three hundred yards from the sea. It really is great to wake up, go to the balcony and watch the waves caress the burning sand... :-)

I like to think of myself as a level designer. I've started with Doom back in the good 'ol days but I never actually released any of my work since I didn't think it was good enough. In January 1997 I was hired by Dark Designs, inc. a company which will release its first game, using the Quake II engine, in late 1998. I'm in charge of game and level design as well as doubling as the company's biz guy.

You can find me on IRC occasionally, on Undernet #3dgamers but I rather go out and live a little. You should too. If you'd like to get in touch with me you can mail me at For more personal matters you can catch me on ICQ. On the servers I go by "#3dgamers_Sat".

Past work include:

  1. Kraan, a world designed for Unreal
  2. Hexenworld along with Phoebus and Bakshra
  3. UAC Gateway, the first database of links exclusively dedicated to Quake II
  4. Serpent's Realm, the first database of links exclusively dedicated to Hexen II
  5. The Mailbag
  6. The Unofficial Trinity FAQ now discontinued



Chapter II: Basic Information

    1.    What is Quake III?

Quake III is a first-person 3D game developed by id Software. It's the third game from id Software to use a real 3D engine. Based on WinQuake, a native Win32 application, Quake III will run on either Windows 95 or Windows NT 4.0 or later in its first release. id Software is the company responsible for creating the first-person shooter perspective genre when they released Wolfenstein 3D and then Spear of Destiny, the sequel to Wolf3D. Then it was well underway to release the game that would make the PC a games platform to be reckoned with: Doom, arguably one of the top 5 games of all time, if not the first.

Doom 2, Ultimate Doom and Final Doom followed shortly. While every competing company was trying to beat Doom for its sheer gameplay brilliance, id started development on "the next big thing": Quake. Using a real 3D engine, Quake surpassed everything in terms of internet community known to date and now id did it all again. Quake II, much more than a mere sequel, is totally different from Quake fixing the incoherence present in that game plus adding tons of new effects which were impossible to do in Quake.

When everybody thought id was creating a mission pack for Quake II they announce they'll be developing Quake III.

The war engines are in place, the mines buried beneath the earth, and already the towers tremble; the ladders stand at the gates, the grappling hooks cleave to the walls and fire runs through the roof tops.

With the gleaming swords and the menacing faces of his enemies around him, and thinking utter ruin is upon him, why should he not quake and mourn?

Francesco Petrarca, in Secretum, 1342 A.D.


    2.    System Requirements

Since Quake III will feature a vastly superior engine it will require a much high-spec machine but I'll let John Carmack speak for himself:

The Old Plan:

The rest of the team works on an aggressive Quake 2 expansion pack while Brian and I develop tools and code for the entirely new Trinity generation project to begin after the mission pack ships.

The New Plan:

Expand the mission pack into a complete game, and merge together a completely new graphics engine with the quake 2 game / client / server framework, giving us Quake 3.

"Trinity" is basically being broken up into two phases: graphics and everything else. Towards the end of Quake 1's development I was thinking that we might have been better off splitting quake on those categories, but in reverse order. Doing client/server, the better modification framework, and qc, coupled with a spiced up DOOM engine (Duke style) for one game, then doing the full 3D renderer for the following game.

We have no reason to believe that the next generation development would somehow go faster than the previous, so there is a real chance that doing all of the Trinity technology at once might push game development time to a full two years for us, which might be a bit more than the pressure-cooker work atmosphere here could handle.

So, we are going to try an experiment.The non-graphics things that I was planning for Trinity will be held off until the following project -- much java integration with client downloadable code being one of the more significant aspects. I hope to get to some next generation sound work, but the graphics engine is the only thing I am committing to.

The graphics engine is going to be hardware accelerated ONLY. NO SOFTWARE RENDERER, and it won't work very well on a lot of current hardware. We understand fully that this is going to significantly cut into our potential customer base, but everyone was tired of working under the constraints of the software renderer. There are still going to be plenty of good quake derived games to play from other developers for people without appropriate hardware.

There are some specific things that the graphics technology is leveraging that may influence your choice of a 3D accelerator.

All source artwork is being created and delivered in 24 bit color. An accelerator that can perform all 3D work in 24 bit color will look substantially better than a 16 bit card. You will pay a speed cost for it, though.

Most of the textures are going to be higher resolution. Larger amounts of texture memory will make a bigger difference than it does on Quake 2.

Some key rendering effects require blending modes that some cards don't support.

The fill rate requirements will be about 50% more than Quake 2, on average. Cards that are fill rate limited will slow down unless you go to a lower resolution.

The triangle rate requirements will be at least double Quake 2, and scalable to much higher levels of detail on appropriate hardware.

Here are my current GUESSES about how existing cards will perform.

Voodoo 1
Performance will be a little slow, but it should look good and run acceptably. You will have to use somewhat condensed textures to avoid texture thrashing.

Voodoo 2
Should run great. Getting the 12 mb board is probably a good idea if you want to use the high resolution textures. The main rendering mode won't be able to take advantage of the dual TMU the same way quake 2 does, so the extra TMU will be used for slightly higher quality rendering modes instead of greater speed: trilinear / detail texturing, or some full color effects where others get a mono channel.

Permedia 2
Will be completely fill rate bound, so it will basically run 2/3 the speed that quake 2 does. Not very fast. It also doesn't have one of the needed blending modes, so it won't look very good, either. P2 does support 24 bit rendering, but it won't be fast enough to use it.

ATI Rage Pro
It looks like the rage pro has all the required blending modes, but the jury is still out on the performance.

Intel I740
Should run good with all features, and because all of the textures come out of AGP memory, there will be no texture thrashing at all, even with the full resolution textures.

Rendition 2100/2200
The 2100 should run about the speed of a voodoo 1, and the 2200 should be faster. They support all the necessary features, and an 8 mb 2200 should be able to use the high res textures without a problem. The renditions are the only current boards that can do 24 bit rendering with all the features. It will be a bit slow in 24 bit mode, but it will look the best.

Probably won't run Quake 3. They don't have ANY of the necessary blending modes, so it can't look correct. Video Logic might decide to rev their minidriver to try to support it, but it is probably futile.

RIVA 128
Riva puts us in a bad position. They are very fast, but they don't support an important feature. We can crutch it up by performing some extra drawing passes, but there is a bit of a quality loss, and it will impact their speed. They will probably be a bit faster than voodoo 1, but not to the degree that they are in Quake 2.

Naturally, the best cards are yet to come (I won't comment on unreleased cards). The graphics engine is being designed to be scalable over the next few YEARS, so it might look like we are shooting a bit high for the first release, but by the time it actually ships, there will be a lot of people with brand new accelerators that won't be properly exploited by any other game.

Brian Hook: Shader has been making huge progress. I can now load .TRI files, and it correctly does our multipass rendering algorithms used in Trinity. I still need to add interactive lighting, but overall it's turning into a real tool. I struggled for a while on how to come up with a decent reference palette the artists could use. Given that a lot of our target hardware may suck our textures down to 4444 land, I figured a 12-bit palette window would be nice, but how to represent that in a humane way was tough. In the end I ended up doing a 64x64 texture palette, with +X going along the brightness axis and +Y going along the hue axis (I ended up using HSB space instead of RGB). The palette is divided into two sections: the upper 31 rows are with saturation = 100%, and the lower 31 are with saturation = 50%. The last two rows are for a 128-unit gray scale ramp. I'm not entirely happy with this, and there's no color wheel facility, so I may end up having to do something similar to a color wheel kind of thing. Irk. That can wait. Hopefully our stud muffin artists will save me the trouble by saying "We don't need no steenking palettes" or by creating their own in Photoshop or Paint Shop Pro.

Brian Hook: Well, now that John has spilled the beans on Quake3, I can start talking a little bit about what I've been working on. As I mentioned earlier, the DMPaint program has been completely redone (several times now) and is now called Shader. It allows you to put together different surface maps that represent diffuse, specular, emissive, etc. properties and combine them in an editor interface. You will be able to move the light source, viewer, and model around. By default it loads up a rectangle that slaps the textures onto it, but it also supports loading Alias .tri files (just got that working tonight). I've also had to do lots of cleanup and rewriting to make sure that full path names are properly handled (I was assumng relative paths before).