WAD Format
| Format type | Archive |
|---|---|
| Max files | 2,147,483,648 |
| File Allocation Table (FAT) | Internal |
| Filenames? | Yes, 8 chars max |
| Metadata? | None |
| Supports compression? | No |
| Supports encryption? | No |
| Supports subdirectories? | No |
| Hidden data? | Yes |
| Games |
The WAD ("Where's All the Data") Format is an archive file used by Doom and Rise of the Triad, as well as Doom engine games such as Hexen, Heretic and Strife to store individual game data files (known as lumps) in a single large file. The files can be internal (IWAD) or external/patch (PWAD). Typically a game will only load one IWAD, but it can additionally load zero or more PWADs. Any PWADs specified override resources found in the IWAD. In this way, a mod can be entirely contained with a PWAD, and any lumps that were not modified do not have to be included in the PWAD as the game will automatically go back to the IWAD to load them.
Despite BUILD games having their own GRP Format archives for game data, they also use WAD files in the form of RTS Format "RemoteRidicule" audio, first introduced with Rise of the Triad.
File format
The basic architecture is a header, followed by a variable sized 'directory', followed by the raw file data.
Signature
All WAD files begin with the WAD type, the number of files stored within, and where the filenames are located.
| Data type | Field name | Description |
|---|---|---|
| char[4] | sig | "IWAD" or "PWAD", not NULL-terminated |
| INT32LE | numFiles | Number of files |
| INT32LE | offFAT | Offset of FAT (directory) from start of file |
The signature is followed immediately by a file entry structure, repeated numFiles times.
File entry
The directory associates names of lumps with the data that belong to them. It consists of numFiles 16-byte entries, one for each lump of data in the file. The name lacks a file extension as the games are programmed to recognize lumps by their format.
| Data type | Field name | Description |
|---|---|---|
| INT32LE | offData | Offset of lump's data (from start of WAD file) |
| INT32LE | lenData | Size of lump, in bytes |
| char[8] | name | Name of lump, not NULL terminated but padded with 0x00 if necessary |
Lumps
More than one lump can have the same offset, if two files point to the same data. A lump may include (overlap) data from another lump. This makes extraction difficult. It is also notable that some lumps have an invalid size, usually 0 bytes. These are known as 'virtual lumps' and are basically placeholders, signalling the start and end of a certain collection of lumps that are related in some way.
Note that the order of data lumps in the file does NOT have to be the same as that in the directory, some tools can import new data to a WAD, attaching it to the end of the file but leaving the directory entry where it is, 'jumbling' the order. The majority of lumps have no restrictions on where they must be located in WAD files, although there are typically some guidelines to make the file easily readable by other people. For certain lumps, however, the location is crucial.
Some lumps are known by their names and apply to the game as a whole. Some of these are:
- Sound effects
- Music
- PLAYPAL: Color palettes for various situations.
- COLORMAP: Map to adjust pixel values for reduced brightness.
- ENDOOM: Text displayed when vanilla Doom exits.
- TEXTURE1, TEXTURE2, PNAMES: Data defining the wall textures.
- DEMOs: Recorded games, auto-played before any level is started.
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 form ExMy or MAPxx, where x and y could not exceed 4 and 9 respectively (Ultimate Doom), and xx could not 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 and Y coordinates, starting angles, type and flags. As with all of these lumps, this list will be generated by your level editor and should generally be left alone. 1
- 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 line segments called "segs" that connect to form subsectors. Created by a node builder.
- SSECTORS
- A list of subsectors, created by a node 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 a node builder.
- SECTORS
- 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 the node 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. Some modern source ports do not require this lump any more; ZDoom for example 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 cannot 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 is 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. Patches are not required to have any markers. Some lump management utilities require P_START and P_END.
These markers are required by all versions of Doom:
| Start marker | End marker | Content |
|---|---|---|
| F_START | F_END | Flat delimiters |
| S_START | S_END | Sprite delimiters |
Tools
The following tools are able to work with files in this format.
| Name | Platform | Extract files? | Decompress on extract? | Create new? | Modify? | Compress on insert? | Access hidden data? | Edit metadata? | Notes |
|---|---|---|---|---|---|---|---|---|---|
| Camoto | Linux/Windows | Yes | N/A | Yes | Yes | N/A | N/A | N/A | |
| Camoto/gamearchive.js | Any | Yes | N/A | Yes | Yes | N/A | N/A | N/A | |
| SLADE | Windows/Mac | Yes | N/A | Yes | Yes | N/A | N/A | N/A | |
| Eureka | Windows/Mac/Linux | Yes | N/A | No | Yes | N/A | N/A | N/A | |
| Wombat | Windows | Yes | N/A | No | ? | N/A | N/A | N/A |
See also
- RTS Format - RemoteRidicule files are in WAD format