

=============================================================================

                   _             /////    /////   //////  /////   /////

  __ _ _   _  ___ | | _____    //        //  //  //     //      //

 / _` | | | |/ _ || |/ / _ \    /////   /////   ////// //       /////  2.1

| (_| | |_| | (_|||   <  __/       //  //      //     //           //

 \__, |\__,_|\___||_|\_\___|  /////   //      //////   /////  /////

    |_|

=============================================================================



    The Most Sacred and Most Unofficial Quake Technical Specification.

                      As derived by Nezu the Unworthy

                           (montanuy@dmi.ens.fr)

                  From the holy Long Words of the id Gods

            found in an Ancient Scroll retrieved by the Vandals

              and read according to the Lores of the Cavemens.



---------------------------------------------------------------------------

Sure, go ahead. But all that info is way outdated. Everything has changed.



                               -- John Romero

---------------------------------------------------------------------------



List of Contents



 0    Introduction

 1.   New WAD file

 1.1  Directory

 1.2  Pictures Format

 1.3  Wall Textures Format

 2.   Level Maps

 2.1  Organisation

 2.2  Level

 2.3  Sectors

 2.4  Walls and Skies

 2.5  Texture references

 2.6  Planes

 2.7  Vertex

 2.8  Nodes

 2.9  Visibility lists

 2.10 Light maps and lighting

 3.   Entity Models

 3.1  Organisation

 3.2  Animation

 4.   Sound Capabilities

 5.   Network Capabilities

 6.   Miscellaneous Information

 6.1  The Quake programming language

 6.2  Definition of entities

 6.3  Definition of light maps

 7.   Final word







---------------------------------------------------------------------------





0. Introduction





 Yes, I know what you're saying.



 It's not possible. It can't be. It's another ridiculous hoax.

 A complete nonsense. Probably some llama's joke.



 Well actually, if you feel that way, you're right:



 So don't read that specification.

 It's obsolete, outdated, completely imagined from scratch and doesn't

 even bear any remote relations to Quake. All my imagination.



 Go back to DOOM editing, and assume you've been very clever!



---------------------------------------------------------------------------



                               Legal Warning



Quake is a Trademark of id Software, inc, hereby acknowledged.

The technical details presented here are all Copyright id Software.

This document is not an official id Software publication.



Do not bother id Software concerning the contents of this file.



This document is copyrighted. You are not allowed to publish it via any

electronic or non-electronic means without the explicit consent of id software.

You are not allowed to put any part of this document on non-free support (like

magasines, newsletter or CD-Rom) without my prior consent.



In no event shall I be held responsible for any degradation of your health,

wealth, mental sanity or social relations.



All rights reserved. No guaranty. That's life!



---------------------------------------------------------------------------



                                   Thanks



  This document would not have been possible without the hard work of

  id software (of course) and some hackers whose name is not to

  be made public without their consent. I think I did my share of hard

  work, but it was considerably easier than what any of them did.



                  So mainly thank them, not me!



 Special Thanks to Jens Hykkelbjerg for the HTML version.



---------------------------------------------------------------------------





1. The new WAD2 format





It is expected that the WAD2 format is only temporary.

Quake will probably directly read common picture and sound formats.

However, stuff like MIP textures and Alias models might not be

very easy to store in a traditional file format, so it is still

possible that WAD remain in use.





1.1 Wad Directory





// WAD Header

struct QKHEADER

{ char Magic[4]= "WAD2";  // Name of the new WAD format

  long NbOfDirEntries;    // Number of entries

  long DirPosition;       // Position of WAD directory

};



// Directory

struct QKENTRY

{ long Start;             // Position of the entry in WAD

  long Wsize;             // Size of the entry in WAD file

  long Size;              // Size of the entry in memory

  char Ident;             // Entry identification

  char Cmprs;             // Compression

  short Dummy;            // Not used

  char Name[16];          // 1 to 16 characters, '\0'-padded

} Dir[NbOfDirEntries];    // like in DOOM



1.1.1 Entry identification



The field Ident in the directory identifies the entry. It's a single byte,

which give 256 possibilities. Only 3 are actually used for the moment.



 0x40=  '@'=  Raw bytes (Console, Color Palette)

 0x42=  'B'=  Pictures (for status bar)

 0x44=  'D'=  MIP Textures (for 3D brush models)



1.1.2 Color palette Format



This format is Exactly the same as in DOOM:



struct RGB {char R; char G; char B;} Palette[256];



1.1.3:Console lump format



Modifying this console lump is of very limited interest, anyway here is the

format:



The console lump is a similar in structure to the flat pictures of DOOM.

It's a simple lump of color indexes:



char  Console [192][128];  //This means it's a 128x192 array



The first 64 rows are devoted to the decription of the character font (each

ASCII character below 0x80 has a 8x8 cell attached to it. The characters

below 0x20 are special).



The rest of the picture is made of four 64x64 quadrant: one grid, and

threes other with somewhar random texture. These might be some background

for the maps. Who cares actually?



1.2 Picture Format



The pictures will probably used for everything concerning the status bar

(animations, numbers, ...). They are not used for sprites, countrary to

DOOM.



This is essentially the same format as in DOOM, except that the picture is

drawn by row, not by columns, and that 16-bit numbers are used, because a

screen is 320 or 640 wide.



// Picture header

struct QKPIC

{ long Width;           // Picture width

   long Height;          // Picture height

  long Row[Height];     // Offset to the rows, from start of picture

}



// Each column is a set of lumps, placed one after the other.

// if for a lump Hpos=0xFFFF, then it's the end of the set.

struct PICLUMP

{ short Hpos;           // Horizontal offset

  short Count;          // number of pixel

  char Pixel[Count];    // pixels color index (in current palette)

  char Dummy[Count&1];  // to align the structure PICLUMP on 16-bit boundary

}



1.3 Level Wall Textures



The MIP Textures are very special pictures, made of a set of 4 pictures,

scaled by 1, 1/2, 1/4 and 1/8, in order to avoid the Aliasing effect that

made DOOM walls and floors look so jerky in the distance.



Those textures are used to cover the walls, the floors, the ceilings and

the skies surfaces. Actually, they just cover any surface. Those textures

are NOT used for sprites or Entity models, so those models are not (yet?)

protected from ugly Aliasing effects.



1.3.1 Texture names



The names of textures can contain up to 16 characters.



If the texture is not animated, the name can be anything, provided the

first character is not '*', the asterisk.



1.3.2 Animated Texture names



If the texture is animated:



   * the first character is '*'

   * the second is '0' plus the frame number of the texture

   * the third is '0' plus the number of frames



So for instance an animated sky will be composed of 3 textures:



  1. *02cloudsky

  2. *12cloudsky

  3. *22cloudsky



1.3.3 Texture Lump format



When stored in a WAD, the MIP textures are made of just one lump,

containing a header, then the texture scaled by 1, then by 1/2, then by

1/4, then by 1/8.



//Texture header

struct TEXHEAD

{ char Name[16]         // Texture name, useless. To be removed?

  long W;               // Width

  long H;               // Heigth

  long Scale1Pos;       // pointer to Tex, scaled 1

  long Scale2Pos;       // pointer to Tex, scaled 1/2

  long Scale4Pos;       // pointer to Tex, scaled 1/4

  long Scale8Pos;       // pointer to Tex, scaled 1/8

}

// At offset Scale1Pos, from start of file

// Picture, scale 1

char Tex1[ W*H];

// At offset Scale2Pos, from start of file

// Picture scaled by 1/2

char Tex2[ (W/2)*(H/2)];

// At offset Scale4Pos, from start of file

// Picture scaled by 1/4

char Tex3[ (W/4)*(H/4)];

// At offset Scale8Pos, from start of file

// Picture scaled by 1/8

char Tex4[ (W/8)*(H/8)];



All those Tex1, Tex2, Tex3, Tex4 represent color indexes, And the picture

is 256 colors. The picture palette is usually indicated in the begining of

the WAD that contain a set of textures.



The color palette index zero is used to represent transparency.



1.3.4 Texture Anti-aliasings



(Nonsense ahead. Go get some Aspirin)



The sampling theorem states that when you sample any signal (sound,

picture, anything) the highest frequency contained in this signal must be

at most one half of the sampling frequency. If there is any frequency above

that, the sampling process will map it into a lower frequency, thus

creating a terrible mess into the sampled signal. This mess is called

Aliasing.



When you try to display a picture on a smaller space, you increase all the

frequencies contained in that picture, and thus risk Aliasing. That's

basically what happend in DOOM at long distance.



Now, all you need is only to low-pass filter the picture, with a cut

frequency equal to half the sampling frequency. Easy! But... There is no

DSP on the video memory, so those calculations would take too much time.

It's much easier to pre-calculate 4 scaled down pictures, that can be used

across the most common range of scales:

infinity-1, 1-1/2, 1/2-1/4, 1/4-1/8.

Below 1/8, there will be some aliasing...



Here is how the right texture is selected in Quake:



int R_MipLevelforScale(float scale)

{

  if(scale>= 1) return 0;       // 1 and above. no aliasing.

  if(scale>= 0.4) return 1;     // shouldn't it be 1/2 ?

  if(scale>= 0.2) return 2;     // shouldn't it be 1/4 ?

  return 3;                     // down to 1/8 (below, aliasing!)

}



---------------------------------------------------------------------------



2. Level Map structures



The level structure looks fairly complex, but it contains only the minimal

amount of information. In that respect, it is much cleaner than the level

structure of DOOM. It seems clear that with Quake, id has learnt how to

make almost optimal use of 3D BSP tree.



This 3D structure is real simple compared to the formats used by 3D Studio

or even POV, so conversion should be possible.



However, Quake will also necessitate 3 special structures which are not

common to 3D graphic packages:



  1. A 3D BSP tree, optimised for speed (minimum number of face splits, and

     minimum number of nodes and leaves). It's not that hard to calculate,

     but it's hard to optimise correctly.

  2. One visibility list per leaf, also optimised for speed (only the

     leaves that can actually be seen from another leaf should be there).

     It will probably require rather tedious calculations.

  3. A light map, that is used to make the rendering of surfaces more

     realistic. I have no idea how this can be handled.



2.1 General description of levels



A Quake level is basically organised around a huge BSP tree. All is derived

from the BSP tree, and all depends on the BSP tree. So if you don't like

BSP trees, forget about making Quake editors.



Of course, if you intend to edit Quake levels, chances are that you will

never have to deal with the BSP tree itself. What you will edit is a rather

complex 3D map, a bit like those of DESCENT, except that almost any shape

is allowed, not only combination of cubes.



Quake will require a very clever 3D editor, because there seems to be quite

a lot of things to calculate that can't entirely left to the user, light

ambient lights, alignement of light maps and texture offsets.



2.1.1 Level boundaries:



The levels are considered by Quake only as a kind of entity, like any other

entities, and it seems possible to put one level inside another. Although

this sounds a bit strange, it could be useful in order to 'smoothly'

transit from one level to the other. In DOOM or even in HEXEN, there is

only one level displayed at the time, so transits between levels must be

done via teleports. This may not be the case in Quake.



2.2 Level organisation



So here is the level organisation on a file. As mentionned before, it is a

huge BSP tree. All the components of this tree are detailed below, but

first here is a general description:



the BSP tree is made of nodes, starting with a root node, which has two

childs, which in turn have two childs, and so on, as you go down the

branches of the BSP tree. The nodes only represent a way to partition the

space, they do no ever appear in a level.



Some of the childs are extremities of the branches. They are called BSP

tree leaves, and in fact each branch must be terminated by one leaf. Those

leaves are in fact portions of the actual 3D level, and usually they

represent portion of rooms. So to any leaf is associated one or more

surfaces, that represent the actual walls, floors, ceilings and sky for

this portion of level.



Those surfaces are defined by a plane in which they lie, an ordered set of

vertex, that define their boundary, an constant base light level, a single

texture, and a light map and offsets for the texture.



The textures are defined by a reference to a picture or a set of animated

pictures, some base offsets, and some flag that say if they must be flipped

horizontally, vertically or both.



I seriously doubt you could make any sense of the above, so there is some

more details, to add to the confusion. If by the end of this chapter you

still don't understand how the level are organised, go play DESCENT to

increase your experience with 3D volumes :-)



2.3 The Tree Leaves (Sectors)



The tree leaves are the Quake equivalent of the sectors in DOOM. You can

imagine them as rooms, or part of rooms, where the monsters, players and

object will be placed.



Actually the tree leaves are the equivalent of the Sub Sectors: each sector

in DOOM is decomposed by the BSP into smaller and simpler convex sub

sectors, that contain only part of the sector lines.



Technically, each tree leaf, made of some surfaces and bound by the BSP

node split lines, appears in 3D space as a convex polytope.



Think of them as big rooms without any corners where you can hide from any

part of the room. (Sorry, I'm just trying to be AOLicaly correct).



Well, if you don't understand the above, I'm real sorry but the best you

can do is go ask your mother for a system upgrade.



Technically, a tree leaf is defined by



   * A bounding sphere (an origin point and a radius)

   * A list of Surfaces (a first surface, and a number of surfaces)



2.4 The Surfaces (Walls, floors and skies)



The surfaces represent the visible boundaries of a tree leaf. The surfaces

are the Quake equivalent of the Sidedefs of DOOM, in the sense that they

tell what sector boundaries look like.



Depending on the name of their texture, they will appear are a sky texture,

or as a wall or floor (that can eventually be animated). Note also that

though the skies are ordinary wall textures, they are drawn in a very

special way, that make them look like skies. That is basically the same

trick as in DOOM, except that it doesn't need to use a F_SKY fake sky

marker.



The surfaces will be rendered as a texture-mapped polygon. The texture

somewhat takes into account the distance, for better realism. Technically,

the polygon is split based on the inverse of the distance, and fragments

are mapped linearly.



The texture mapping also takes into account the orientation of the surface,

because calculations of points in texture space is done by selecting only 2

coordinates among the three coordinates of the points. So depending on the

orientation of the surface, the most representative set of coordinates must

be chosen.



Technically the surfaces are defined by:



   * The plane where they lie in, (for distance calculations)

   * An indication that they are on the front or back side.

   * A set of vertex, ordered, to that the segments from one vertex to the

     next actually represent boundaries of the surface.

   * A texture, and a rectangle in texture space, so that the same texture

     may be used differently for many surfaces

   * A constant light level, a style of light, and a light map that is part

     of the general level light map.



2.4.1 Open Passage ways



When a surface is just a passage way (like a hall, a door, or a hole in the

floor) and need not be covered by a texture, it is just... ignored. There

is nothing that describes it in the level structure.



This is a contrast with DOOM, where that kind of passage had to be

indicated by two sided lines. There is no 2 sided surface, unless you want

to create a transparent wall (and even then, it would be made of two

independant surfaces).



2.5 Texture definitions



The texture definitions are not actual textures, but rather special

references to the true textures. One or more texture definition can point

to the same texture data, and it will look somewhat different each time.

There is no equivalent of this intermediary texture definition in DOOM.



Each texture definition contains:



   * the name of the actual texture (that could be animated)

   * two offsets in the texture's picture space

   * an indication of the scale of the texture

   * 3 flags that say if the texture must be flipped horizontally,

     vertically or if if horizontal and vertical must be exchanged.



2.6 Planes definitions



The planes are used as split planes in the BSP tree nodes, and as reference

plane in the Surfaces.



They are the Quake equivalent of the DOOM Linedefs and Segments.



The planes are defined by a normal vector and a distance. This normal

verctor must be of norm 1.



The plane equations are used for distance calculation and to determine if a

given vertex (of a surface, or an entity) is on the front side or the back

side of the plane.



It is highly recommended that if a node and some set of surface use the

same plane equation, they point to the same plane definition.



2.7 Vertex definitions



The Vertex as the Quake equivalent of the DOOM vertex. the only difference

is that they are in 3D, not in 2D.



There can only be 12 vertex per face, and in fact, 16 vertex when taking

into account the clipping of the face by the BSP planes. In fact, there are

so many limitations related to this 16 number of vertexes that we can

expect it's only temporary.



2.8 BSP tree Nodes definitions



The nodes are the Quake equivalent of the DOOM nodes and also of the DOOM

blockmaps. They are parts of a 3D BSP tree, not a 2D BSP tree like in DOOM.



The nodes are used for level display, placements of entities and collision

detections (and maybe even more). So there is no need for a blockmap in

Quake.



Technically, nodes are defined by:



   * A plane that split them in two

   * A bounding sphere (origin point and radius)

   * A front child node (or leaf)

   * A back child node (or leaf)



The root node of the BSP tree is the first node in the list of nodes (in

DOOM, it was the last node).



The front child node (and all the nodes below it) is entirely contained in

the half-space that is in front of the split plane.



The back child node (and all the nodes below it) is entirely contained in

the half-space that is in the back of the split plane.

(The 'front' and 'back' of a split planes are defined by the plane equation

giving a positive or negative result for any given vertex)



If the split planes reference is -1, then in fact the node is a tree leaf,

see the definition above.



2.9 Visibility list



This tricky structure is the Quake equivalent of the REJECT map of DOOM.

And yes, it will take ages to calculate (I hope not!).



Unfortunately, it is much more important than the REJECT map, since it can

be used to make the level rendering much faster. This is due to the fact

that sectors are now the leaves of the BSP tree.



The REJECT map in DOOM was only used to control the monster's behaviour. It

could not be used for rendering, since it was sector based.



So it can be expected that the REJECT special effects of DOOM (blind

monsters and such) are something of the past... though in fact, screwing

the visibility list is a very good way to obscure some areas of the levels.

But I'm not sure Quake will be of much fun in blindfold mode.



Basically, the Reject map is an array of bits, one array per tree leaf. The

bit number n, if set to 1, tells that when laying in the tree leaf, one can

see the leaf number n.



When the player is in a leaf, the engine finds all the leaves that are

visible from that leaf, and tag those leaves. Then it tags back all the

nodes that are above the tagged leaves. That way, only the part of the BSP

tree that is really visible will actually be tagged, and later displayed.



2.10 Lighting



Quake apparently uses some static light model: there is no Gouraud or Phong

shading calculated in real time. However, the constant light level of

surfaces may possibly be updated in real time (as when you walk around with

a torch, or open a window).



Note that recent information released by id software indicate that the

light mapping and shadowing in Quake would be done dynamically. The fact

that everyone thinks it's damn impossible to make any dynamic shadowing on

a 486 or pentium is only a minor concern. So chances are that the

description below is outdated. I hope so at least!



The way Quake makes it's surface lighting so realistic is a bit special. It

works with each surfaces independently of others, and the lighting is

calculated once for a set of similar surfaces, so it can't possibly be

Gouraud or Phong. Yet, it might be much more realistic!



The basic idea behind the Quake lighting is to take into account 3 things:



   * A constant light level

   * A special thing called type of lighting.

   * A light map, which is no more than a basic light level, for each

     texture pixel.



Constant light level



The lighting principle is that of so-called 'flat shading'.



There is one such light level for each surface, and we can assume it

depends on the orientation of the surface, and on the static light sources

defined before the level is calculated. I suppose that a good Quake editor

would let the user define some sources of lights (windows, torches, sky)

and then do the lighting calculations once and for all, for all surfaces.

Of course, this is fairly primitive (no way to move torches, to switch off

lights) but then again the game engine could possibly update this static

light in real time, under certain conditions.



Type of lighting



This strange attributes seems to translate internally into some kind of

multiplicator for the light map below. Apparently, it only multiplies the

light level, it doesn't affect the colors. I supppose it's here to give a

bit more variability to light maps.



Light Map



The light map, basically, is a byte field, one byte per pixel of the

texture. This byte give the light level of this pixel. This allows for some

fairly realistic apparent surface irregularity. However, the light map is

not defined for each pixels: it's only one light value every 16 pixels, and

it is bilinearly interpolated in the intervals. Also, the light maps are

shared between surfaces.



Pixel Lighting



Using the pixel's color index, and the light level calculated as:

light(x,y) = lightmap(x,y) * lightstyle[style] + constant light



This light level is used to select an internal color palette. Then using

the texture's color index and an index in this palette, it's possible to

find the actual lighted color. This mechanism is basically the same as in

DOOM, except that there is 256 (?) color palettes, not 32. This mechanism

takes into account both 8-bit or 16-bit color palettes, so Quake will look

better on 16-bit per color display, but will still run on 8-bit per color

display.



Dynamic light mapping



Franckly I have no idea how this could work. However, the static light

mapping is already so calculation intensive that I wonder if, after all, a

simplified dynamic light calculation wouldn't be as fast. Descent is

supposed to do light calculation fer every vertex of the cubes, and then

apply linear mapping between the vertex. A similar technique could be used

in Quake, but it would probably involve much more vertex calculations.



2.11 Model format



This is the format of the model, when stored in a single lump.





                DELETED BECAUSE OBSOLETE



         The format will probably be some ASCII.



2.12 The Quake 3d engine: rendering of levels



(Thanx to Jens for some critical reflexions)



I'm not going to explain in details how the Quake 3d engine works. It

wouldn't be fair to id software, and anyway I still don't understand a lot

of critical features. Also, if such an explanation was to be read by the

conceptors of Quake, chances are that they would die laughting, and I don't

want to take that risk.



Let's say only that the Quake 3D engine looks like an ordinary

texture-mapped polygon engine, where the polygon sorting is not done via

classical backface elimination and distance sorting, but by using a BSP

tree.



Countrary to DOOM, there is no ray-casting, so some surfaces are sometime

rendered, then later overwritten by closer surfaces. Hence the visibility

list is critical for this engine, otherwise it might really crawl.



The Quake engine bears definitely no relation to the Descent level display

engine, though there might be some similarities with the engine that

display the vessels of Descent.



The Quake engine keeps a list of clip 3D planes that is used to avoid

rendering too much of the non-visible surfaces.



There is apparently no polygon-clipping in screen space. Probably the

conceptors of Quake judged that the cost of 2D polygon clipping was too

high, compared to the use of a simpler, though less efficient, painter's

algorithm.



Well, this description gives only the general features of the Quake engine,

and actually don't make a lot of sense. Here are some temporary

conclusions:



   * There is apparently NO limitation to the 3D engine of Quake.

   * This engine could be faster than the engine of Descent, and at least

     won't crawl on large rooms, like Descent does.

   * The shapes of the levels should be rather critical. Chances are that

     if the level parts are very far from convexity, then the engine might

     crawl. I hope not.



This part will be updated later.

---------------------------------------------------------------------------



3. The 3D Alias Model Format



Alias models are used for entities (players, objects, monsters).



3.1 Organisation of Alias Models



An alias model is made of:



   * a skin (a flat picture)

   * a set of skin vertex (vertexes positionned on skin)

   * a set of triangles (the model layout)

   * one or more set of 3D vertexes (one set per animation frame).



How doe it work? First imagine a wireframe model of the entity, made of

triangles. This gives the general shape of the entity. For instance,

imagine you have the general shape of a cow, made of triangles in 3D space.



   * the set of 3D vertex is the vertex that bound the triangles.

   * the triangles are defined as made of 3 particular vertex

   * there is no coding for line segments, planes or surfaces, all is

     implicitely defined by the triangles.



Then, on each of those triangle, map one small triangular area of the skin

of the model. For instance, imagine you have that flat carpet made of the

skin of a cow. Cut a small triangulat piece and put it at the right place,

on the 3D model. What you made is just a mapping between the list of 3D

vertex and the list of vertex on the skin. It happens that in an alias

model, the index of the skin vertex (in the list of skin vertexes) is the

same as the index of the 3D vertex (in the list of 3D vertex, for a given

frame).



That's all Quake needs to display your model, with texture mapping.



3.2 Animating alias models



The animation is not done by changing the skin picture, countrary to

sprites. Rather, the animation consists in providing one set of vertex

positions for each frame of animation.



That means that the animation is still based on frames, like in DOOM. It is

not based on compulation derived from a physical model of the entity. So

the frames of animations had better be calculated carefully, or they will

look unrealistic.



Since skin vertex positions are not changed, and the skin texture is not

modified, and the triangles remain the same, it also means that the entity

can move but it can't change colors, or get some blood stains... unless

some of the triangles are pushed in front of others, during the animation.



3.3 Rendering of alias models



The rendering of entities is a bit mroe complicated than the ordinary

back-face elimination and triangle sorting that is common in games like

X-Wings, Terminal Velocity or the like. It doesn't use a BSP tree like (so

they say) in Descent, but it takes into account the BSP tree structure of

the Quake levels.



I'm not sure the description below will make a lot of sense to you, but it

will be enough to get a general idea: It's basically a combination of BSP

tree rendering, painter algorithm and 3D clipping.



When Quake needs to display an entity, it first determines the hightest

node in the tree that splits this entity. Then starting from this node, it

decomposes the entity in non-overlapping parts, using the split planes of

the BSP tree nodes. That way, one entity part ends up in each tree leaf.

Then, when the whole level if being displayed, each leaf will be painted

first, then the entities parts in this leaf will be displayed, after being

sorted according to distance. When displaying an entity, Quake first

elimitates the back faces, then clip this entity taking into account the

nodes split planes, and the view clip planes. That leaves a set of

triangle, that are sorted (using a very trivial method) and displayed using

the painter's algorithm, and of course texture mapping of the entity skin.



Yes, I know. It's more than confusing, and probably sub-optimal, so don't

trust this description too much. The important point is the conclusion:



   * Do not map many triangle to the same 3D area, that will slow down the

     rendering.

   * The more convex your entity, the faster it will be.

   * The triangles will be sorted according to distance of the closest

     vertex, so if your entity is very complex, with partly overlapping

     triangles, chances are that some triangle will be sorted the wrong

     way.



General conclusion: the simpler the better. Hardly a surprise.



3.4 Alias Model format



                DELETED BECAUSE OBSOLETE



         The format will probably be some ASCII.



        All you need to know is that there is only one picture, and

        that frames are done with vertex, rather than with changes in

        the picture.



---------------------------------------------------------------------------



4. Sound capabilities



This area is being investigated. I'm not a sound expert.



The Sound is definitely stereo, and definitely takes into account the

source position (in 3D) toward the player.



The sound can use the Sound Blaster (damn! what a surprise!), and I'm

totally incompetent to say if it can run on the GUS.



There is no music whatsoever. Fetch some NiN CDs, and that will do the

trick.



This part will be updated later.

---------------------------------------------------------------------------



5. The network capabilities



This area is being investigated. However, no result will be published here:

the network capabilities of Qu*ke are presumed to be a trade secret of id

software, and revealing any technical details about it may hurt id.



Let's just say that Quake maintains a representation of the world were

entities can be added an removed dynamicaly, and players can log in at any

moment. Not really surprising...



It is not known if the player's characters are preserved, like in MUDs.



It is not known if the 3D models can be sent by the server to the clients,

so maybe you won't be able to run around in Quake disguised as Blackadder,

unless everyone uploads your great graphics beforehand.



This part will be updated later.

---------------------------------------------------------------------------



6. Miscellaneous Info



Here you will find some obsolete descrition of various stuff that don't

make a lot of sense yet.



6.1 The Quake Programming Language



This language is very similar to C. It is loaded dynamically by the server,

read, and most probably transformed in an internal representation. The

names of variables in the code are reminiscent of MUDs code, and there is

all reason to beleive Qu*ke will be MUD-like. Of course, there isn't much

code compared to even the simplest MUDs.



There is code that describe how the Qu*ke server should handle the clients,

as they join an existing world. BTW, they can join dynamically, like in

DESCENT. And they can join the level they wish.



The Things are all represented by C-like objects, with a set of attributes

whose name are fairly intuitive (frags, velocity, health...) and the

language provides a set of functions of the basic stuff.



Vectors values are represented as character strings like "1 2 3", and can

be added, scaled and multiplicated. The attribute think is used to tell or

what code function the object shall apply. The attribute nextthink is used

to tell when the next call to the object's code shall happen.



Like in DOOM, the Object/monsters will be implemented as finite state

automats, based on frames. But you won't need DeHacked to read them. The

Objects frame tables are provided in the code (with a special macro

structure, that expands trivialy into code)



Programmer's Corner



The language seems syntacticaly clean, but there seem to be no strict type

checking anywhere, so odds are that any complex code module will be real

difficult to debug. Not to mention the 'goto' lying around. I wonder what

happen when one mixup frames from different monsters... Apparently the

language is entirely event driven (not a surprise) and timers can be set

for certain events. Mind the event loops!



No details will be given on the actual code: the parser and probably the

language were rewritten by id, for more efficiency.



It is not known if some fair level of AI can be implemented using this

language. I seriously doubt it is possible to manipulate some accurate

representation of the world. Quake isn't really a wargame, is it? ;-)



6.2 List of Entities



the *.key file contains object class definition, with default parameters.

These classes are written as a list, in some LISP-like language, except

that the ( ) are { }.



Attribute include the class name, the color, the 3D model, the size of the

object (a scaled cube, not a sphere), the light, the style, the actions

(use, touch, think) the movement mode, the sensitivity to gravitation...



That's what it looks like, somehow:



{

  {classname   "bestiole"}

  {color       "1.0 0.9 0.4"}

  {orgofs      "64 64 80"}

  {size        "32 32 70"}

  {model       "s_bestiole"}

}



6.3 Light maps



This information is probably totally outdated.



The light maps were a trick used in early versions of the Quake engine. It

was a way to implement some cool shadows without too many calculations

involved. Countrary to what was supposed initially, it bears no relation to

dynamic changes in the light level.



Example:



ccmdefabcdefgmmmmaahijlkmmaamm 9 BOUGIE (third variety)



See the level description to know how these light maps are used in levels.

They don't seem to be used with entities.



6.4 Player Movements



There are some reasons to believe that there is no restriction in 3D

movements Quake. 6-axis movement seems technically possible, and at least

the movement internal structure allows all combinations, and the graphic

engine is not restricted to any rotation.



Here are the known movements:



 turn left/right, up/down,

 move front/back

 strafe left/right, up/down



no key is defined for roll turn, jump, climb, fly. This may/should change.



6.5 The Language of the Gods



The language of the Gods, countrary to common Tleilaxu beliefs, is C. It

was C in DOOM, it is C in Quake.



Let's just say that the code if id is characterised by... the absence of

almost all security tests. That means that if the data structures are not

100% perfect, the code will bug or crash without warning. This is

especially true when you deal with indexes. Don't even make a mistake on an

index, in a file.



It can be noted that the code was not optimised at all and used floating

numbers (and thus, used the floating point unit). This makes it especially

unsuitable for 386 (no surprise) and in fact unsuitable for anything below

an helium-cooled 300 Mhz 686, with 500k of primary cache and 20 meg of s

econdary cache. However the code was certainly completely rewritten and

optimised since these first experiments, and it will run at decent speed

even on a DX2/66 (Or, shall I say, DESCENT's speed. At least.)

---------------------------------------------------------------------------



7. Final Word



This material is provided to you as general information.

You are in no way obliged to believe anything of the above.



   * This specification contains all the information that I estimate I can

     make public without bringing any trouble to id software. Don't ask for

     more.

   * If you want trustable information, you'd better wait for the official

     specifications from id software. Chances are that they won't have

     reliable description themselves, until Quake is nearly finished.

   * If you intend to write a game as cool as Quake and think that it would

     be very clever to get some technical information from me, then you are

     taking some serious risks. I'm not supposed to keep your name secret.



Last remark: this document was written quickly, and I'm not that proficient

in English. So it's full of mistakes.



                             Nezu the Unworthy

---------------------------------------------------------------------------

Come visit my Home Page for the last updates to this specification.

---------------------------------------------------------------------------

List of cool Quake Related pages:



   * Jen's Quake page.

   * Colin's Quake page.

   * Jos's Quake page on the Doom Gate.

   * Hank's Quake Rumor Mill.

