Doom Wiki
Register
m (→‎Lump order: some formatting and removed scripts since it's a non-required lump)
Line 41: Line 41:
   
 
==Lump order==
 
==Lump order==
 
 
For many lumps, where they're located in the WAD is of no consequence, though there are typically some guidelines to make the file easily readable by other people. For some lumps, however, the location is crucial.
 
For many lumps, where they're located in the WAD is of no consequence, though there are typically some guidelines to make the file easily readable by other people. For some lumps, however, the location is crucial.
   
Line 48: Line 47:
 
A map in Doom is made up of several lumps, each containing specific data required to construct and execute the map. The first lump gives the internal name of the map. In Doom, this had to be in the format ExMy or MAPxx, where x and y couldn't exceed 4 and 9 respectively (Ultimate Doom), and xx couldn't exceed 32 (Doom 2/Final Doom). Other than defining the name of the map, the lump is usually empty but can contain data. The level name marks the start of this map. In order to work properly, the following lumps must follow immediately after the the level name:
 
A map in Doom is made up of several lumps, each containing specific data required to construct and execute the map. The first lump gives the internal name of the map. In Doom, this had to be in the format ExMy or MAPxx, where x and y couldn't exceed 4 and 9 respectively (Ultimate Doom), and xx couldn't exceed 32 (Doom 2/Final Doom). Other than defining the name of the map, the lump is usually empty but can contain data. The level name marks the start of this map. In order to work properly, the following lumps must follow immediately after the the level name:
   
[[Thing|THINGS]]: A lump listing all the Things present in this map, their X, Y, and coordinates, starting angles, type, flags, special, and args. As with all of these lumps, this list will be generated by your level editor and should generally be left alone. Note: The standard Doom format does not contain Z and args.<br>
+
[[Thing|THINGS]]: A lump listing all the Things present in this map, their X, Y, and coordinates, starting angles, type, flags, special, and args. As with all of these lumps, this list will be generated by your level editor and should generally be left alone. Note: The standard Doom format does not contain Z and args.<br><br>
[[Linedef|LINEDEFS]]: A list of linedefs, defined by their starting and ending vertices, flags, type, tag, args and front and back sidedefs (if any). Note: The standard Doom format does not contain args.<br>
+
[[Linedef|LINEDEFS]]: A list of linedefs, defined by their starting and ending vertices, flags, type, tag, args and front and back sidedefs (if any). Note: The standard Doom format does not contain args.<br><br>
[[Sidedef|SIDEDEFS]]: A list of the sidedefs that are linked to the linedefs. These contain the data for what textures appear where on the side of each line, their X and Y offsets, and what sector this side of the linedef belongs to.<br>
+
[[Sidedef|SIDEDEFS]]: A list of the sidedefs that are linked to the linedefs. These contain the data for what textures appear where on the side of each line, their X and Y offsets, and what sector this side of the linedef belongs to.<br><br>
[[Vertex|VERTEXES]]: A list of each vertex in the map, using X and Y coordinates.<br>
+
[[Vertex|VERTEXES]]: A list of each vertex in the map, using X and Y coordinates.<br><br>
[[SEG|SEGS]]: A list of lines called "segs" that connect to form subsectors.<br>
+
[[SEG|SEGS]]: A list of lines called "segs" that connect to form subsectors.<br><br>
[[SSECTOR|SSECTORS]]: A list of subsectors, created by your nodes builder.<br>
+
[[SSECTOR|SSECTORS]]: A list of subsectors, created by your nodes builder.<br><br>
[[NODES]]: The node tree which Doom uses to speed up the rendering process. Similar to a vismap in modern 3D games (Such as Quake 3). Created by your nodes builder.<br>
+
[[NODES]]: The node tree which Doom uses to speed up the rendering process. Similar to a vismap in modern 3D games (Such as Quake 3). Created by your nodes builder.<br><br>
[[SECTORS|SSECTOR]]: Defines the floor and ceiling heights and textures, as well as light value, tag, and type of each sector in your map.<br>
+
[[SECTORS|SSECTOR]]: Defines the floor and ceiling heights and textures, as well as light value, tag, and type of each sector in your map.<br><br>
[[REJECT]]: Optionally compiled by your nodes builder, this lump contains data about which sectors are visible from which other sectors. Originally, Doom used this to optimize the game speed by skipping AI routines for enemies whose target was in a rejected sector. Modern machines have no real use for this lump anymore, and so ZDoom has been designed to work even without this lump present. For compatibility purposes, an empty (0-filled) REJECT lump should be included if nothing else. The REJECT lump can also be used to create certain special effects (sectors into which enemies can't see, for example) if modified carefully.<br>
+
[[REJECT]]: Optionally compiled by your nodes builder, this lump contains data about which sectors are visible from which other sectors. Originally, Doom used this to optimize the game speed by skipping AI routines for enemies whose target was in a rejected sector. Modern machines have no real use for this lump anymore, and so ZDoom has been designed to work even without this lump present. For compatibility purposes, an empty (0-filled) REJECT lump should be included if nothing else. The REJECT lump can also be used to create certain special effects (sectors into which enemies can't see, for example) if modified carefully.<br><br>
[[BLOCKMAP]]: Collision-detection information which determines whether objects in a map are touching.<br>
+
[[BLOCKMAP]]: Collision-detection information which determines whether objects in a map are touching.<br><br>
[[BEHAVIOR]]: Not originally a part of Doom, the BEHAVIOR lump was first used in Hexen and contains the compiled scripts that this map will use. Vanilla Doom and other ports designed for Doom only will crash when this lump is present because Hexen format levels are not compatible with Doom format levels. This lump is always present for Hexen format levels. Levels without this lump are Doom format levels.
+
[[BEHAVIOR]]: Not originally a part of Doom, the BEHAVIOR lump was first used in Hexen and contains the compiled scripts that this map will use. Vanilla Doom and other ports designed for Doom only will crash when this lump is present because Hexen format levels are not compatible with Doom format levels. This lump must be present for Hexen format levels since it is the only way to tell if a map is in Hexen or Doom format.<br>
[[SCRIPTS]]: It should contain a text (non-compiled) version of the scripts this map uses, so that other people can learn from your work. If you wish to keep your scripts a secret for whatever reason, you may of course leave this out, but it is considered a courtesy to the community to include it. The name can actually be any name, not just SCRIPTS. Sometimes using a different name is required to be compatible with utilities that will consider multiple SCRIPTS to be the same lump. Naming them SCRIPT01, SCRIPT02, etc is one way to keep all the names unique and fix that issue.
 
   
 
<b>Flats, Sprites, and Patches:</b>
 
<b>Flats, Sprites, and Patches:</b>

Revision as of 20:34, 30 January 2005

WAD (acronym for "Where's All the Data?") is the file format used by Doom and all Doom-engine-based games for storing data. A WAD file consists of a header, a directory, and the data that makes up the resources stored within the file. WADs can be either IWADs or PWADs.


Header

A WAD file always starts with a 12-byte header. It contains three values:

Bytes Content
0x00-0x03 ASCII string "PWAD" or "IWAD", defines whether the WAD is a PWAD or an IWAD
0x04-0x07 An integer specifying the number of entries in the directory
0x08-0x0b An integer holding a pointer to the location of the directory

All integers are 4 bytes long in x86-style little-endian order. Their values can never exceed 231-1 since Doom reads them as signed ints.

Directory

The directory associates names of lumps with the data that belong to them. It consists of a number of entries, each with a length of 16 bytes. The length of the directory is determined by the number given in the WAD header. The structure of each entry is as follows:

Bytes Content
0x00-0x03 An integer holding a pointer to the start of the lump's data in the file
0x04-0x07 An integer representing the size of the lump in bytes
0x08-0x0f ASCII string defining the lump's name. Only the characters A-Z (uppercase), 0-9 and []-_ should be used in Lump names (an exception has to be made for some of the Arch-Vile sprites, which use "\"). The string must be null-terminated if shorter than 8 bytes.

Lump order

For many lumps, where they're located in the WAD is of no consequence, though there are typically some guidelines to make the file easily readable by other people. For some lumps, however, the location is crucial.

Map data lumps:

A map in Doom is made up of several lumps, each containing specific data required to construct and execute the map. The first lump gives the internal name of the map. In Doom, this had to be in the format ExMy or MAPxx, where x and y couldn't exceed 4 and 9 respectively (Ultimate Doom), and xx couldn't exceed 32 (Doom 2/Final Doom). Other than defining the name of the map, the lump is usually empty but can contain data. The level name marks the start of this map. In order to work properly, the following lumps must follow immediately after the the level name:

THINGS: A lump listing all the Things present in this map, their X, Y, and coordinates, starting angles, type, flags, special, and args. As with all of these lumps, this list will be generated by your level editor and should generally be left alone. Note: The standard Doom format does not contain Z and args.

LINEDEFS: A list of linedefs, defined by their starting and ending vertices, flags, type, tag, args and front and back sidedefs (if any). Note: The standard Doom format does not contain args.

SIDEDEFS: A list of the sidedefs that are linked to the linedefs. These contain the data for what textures appear where on the side of each line, their X and Y offsets, and what sector this side of the linedef belongs to.

VERTEXES: A list of each vertex in the map, using X and Y coordinates.

SEGS: A list of lines called "segs" that connect to form subsectors.

SSECTORS: A list of subsectors, created by your nodes builder.

NODES: The node tree which Doom uses to speed up the rendering process. Similar to a vismap in modern 3D games (Such as Quake 3). Created by your nodes builder.

SSECTOR: Defines the floor and ceiling heights and textures, as well as light value, tag, and type of each sector in your map.

REJECT: Optionally compiled by your nodes builder, this lump contains data about which sectors are visible from which other sectors. Originally, Doom used this to optimize the game speed by skipping AI routines for enemies whose target was in a rejected sector. Modern machines have no real use for this lump anymore, and so ZDoom has been designed to work even without this lump present. For compatibility purposes, an empty (0-filled) REJECT lump should be included if nothing else. The REJECT lump can also be used to create certain special effects (sectors into which enemies can't see, for example) if modified carefully.

BLOCKMAP: Collision-detection information which determines whether objects in a map are touching.

BEHAVIOR: Not originally a part of Doom, the BEHAVIOR lump was first used in Hexen and contains the compiled scripts that this map will use. Vanilla Doom and other ports designed for Doom only will crash when this lump is present because Hexen format levels are not compatible with Doom format levels. This lump must be present for Hexen format levels since it is the only way to tell if a map is in Hexen or Doom format.

Flats, Sprites, and Patches:

These three resources must be located between special marker lumps so that Doom knows what it's looking at. Other than defining the beginning and end of a graphics section, these lumps contain no data and are 0 bytes long.

The markers consist of names X_START and X_END, where X is the first 1 or 2 letters of the appropriate resource. For example, sprites should be located between S_START and S_END markers. SS_START and SS_END are usually used for user WAD files. Similarly Flats are F_START and F_END (again FF_START and FF_END in user WAD files). Patches are not required to have any markers. Some lump management utitilies require P_START and P_END.