Lump

A lump is any section of data within the structure of a WAD file, or a file containing such a portion of a WAD file. Each lump has a name (up to 8 characters), which is not necessarily unique. Lumps contain data such as:


 * Graphics
 * Sounds
 * Music
 * Demos
 * Sprites
 * Wall textures
 * Wall patches
 * Flats
 * Level maps and associated data (REJECT tables, NODES, etc.)

Some lumps have specific reserved names. Examples of these are (from DOOM.WAD):


 * The PLAYPAL and COLORMAP entries, which define the colour palettes and the lighting level adjustments respectively;
 * ENDOOM, the 80x25 DOS screen containing credits and a humorous reminder about piracy, displayed at the console after quitting Doom;
 * DMXGUS, an ASCII text lump that maps the instrument patches used by Doom's music for the Gravis Ultrasound (GUS) soundcard.
 * DEMO1 through up to DEMO4, the internal gameplay demonstration recordings, which are played in a loop when the player is not actually playing the game. The total number of demos depends on the IWAD: three for Doom, Doom II, both halves of Final Doom, Heretic and Hexen; four for Ultimate Doom and Chex Quest; just one for Strife.

Map lumps
Each map is made of several lumps, the precise number of which depends on the map format and the port used. Since the map data is stored in lumps that do not have unique names, all maps require a map header with a unique name that serves to identify it in the engine. For example, the map data for MAP01: Entryway is not contained in the MAP01 lump itself, but in the lumps that come directly after it.

Trivia
During development of the Doom games id Software created many of the contents of the IWADs as separate lumps which could be merged into the WAD files, or loaded separately. Using DeHackEd or a hex editor to read Doom's executable, it's possible to see development mode loading commands that read some data, such as TEXTURE1, directly from a lump file. Not long after the release of Doom's source code, the developers released the sources for the utilities with which they handled lumps and wads, including Wadlink, their lump merging tool.

In DOOM.WAD and DOOM2.WAD, each lump is padded such that the following lump is aligned on a four-byte boundary. The padding, when present, is always the first byte of the preceding lump repeated either one, two, or three times. For example, the DEMO1 lump of DOOM.WAD is 6,854 bytes long. The remainder of 6,854 divided by 4 is 2, and so two padding bytes appear after the DEMO1 lump data and before the DEMO2 lump data. Both of those padding bytes are 0x6D because the first byte in the DEMO1 lump is 0x6D. Note that many modern WAD editing tools do not pad lumps in this way when saving a file.