Let's start in the middle, shall we? Wad represents a single file on disk. This class parses out the data into Lumps, which it stores inside of itself. As it inherits from the STL Containers library, it providers iterators and all the other C++ goodness that make it easy to use.
WadGroup is, as its name suggests, a group of Wad files. When you load up a map in an editor, the Wad only has that map. The editor must get its other data, for example textures, from the main Wad file. It does this by opening a group of files together. When it requests a certain piece of data, it prioritizes these files and grabs it from the correct one. The WadGroup class contains the logic to do this on its own.
Finally, Lumps are the basic contents of a Wad file. They act somewhere between a string and a vector, and the WadEntry classes know how to use them to extract the data they need.
The foundation is the vertex. It is just a point identified with a number. Linedefs are walls and other vertical surfaces, and stretch between vertices. Sidedefs attach to sides of Linedefs, and provide texture information. Sectors are the empty space between lines and define floor and ceiling textures, as well as lighting, height, and special effects.
If your house is a Doom map, the vertices are corners of a room. Linedefs are the studs and insulation in the walls. Sidedefs are the drywall nailed to the studs, and sectors are the carpeting and paint on the ceiling.
Things are just that, objects that are not part of the static level. This includes the player start point, monsters, weapons, health, ammunition, and keys.
The rest of the map resources are not important to most people. The game engine cannot display a level directly, it must first divide it up into convex chunks. This uses a binary space partitioning (BSP) algorithm simplified to 2D (while Doom is 2.5D, the BSP process only concerns itself with the first 2D and ignores the .5). The results are the segs, subsectors, nodes, reject, and blockmap resources. The first three divide the map into convex pieces, the last two provide other information.
Reject helps with line of sight calculations. It can mask out sectors, so, for example, if the player and a monster are in sectors that cannot see each other, ever, the engine does not need to calculate whether they can see each other. Essentially the BSP compiler just performs this calculation ahead of time. Given the power of today's machines, reject is not necessary and a blank reject resource works just fine. Its main purpose nowadays is to create special effects with monsters.
Blockmap is similar to Reject but for collision detection. Unlike Reject, it is not only widely used, but required. Maps are not playable without a Blockmap that is accurate and correct.
Texture definitions have two parts. A large chunk of the original Doom wad files is textures, and there are many parts of textures that are repeated. To make maximum use of space in an era when software was sold on floppy disks, textures consist of reusable pieces called patches. Patches are the actual graphics in a custom bitmap format. Textures are made up of patches, and each patch has an offset in the texture.
The PNAMES lump lists all the patches in the wad, or it combines the patches in an IWAD and PWAD. Either way, it is a list of entry names for patches. Each one has an implicit number that is its offset in the lump.
The TEXTURE1/2/3 lump has a list of textures. It lists which patches make up each texture, using that number to reference them. It also specifies where to draw the patch.
The actual patches are listed between PP_START and PP_END markers in the wad. If it is an IWAD, there will be P_START, P1_START, P1_END, P2_START, P2_END, and P_END markers. Libdoomwad handles all of this.
Flats are similar to patches, but are always 64 by 64 and oriented on a preset grid. They exist between FF_START and FF_END markers in PWADs. Back in the day it took some ugly hacks to get flats to work in PWADs, but this is no longer the case with source ports.
OpenGL source ports usually work with 3D models as well. Sometimes the models do not replace every sprite, so you may have sprites and 3D models on screen at the same time.
Playpal is a collection of palettes, each used for a different purpose (e.g. certain powerups). Colormap is primarily used for lighting effects within the same palette. All it does is map colors to different palette entries. For example, a fullbright sector would be mapped to the same entries, while a dark sector might have pixels mapped several shades darker.
Some source ports, especially OpenGL ones, support 16 or 32 bit color modes. They also handle dynamic lighting and alpha translucency, making these two entries almost entirely obsolete. Colormap for sure is obsolete, but the palette is used because textures contain no actual color data.
Inside the Doom executable is a list of animated textures and flats, and switches. These are hard-coded. It used to be that the only way to create your own animations and switches was to hijack an existing sequence, replacing existing textures. This solution sucks for a variety of reasons. Thankfully, Boom provides a method of adding new sequences that is so easy even I can do it.
The ANIMATED lump contains a list of animations (no, really), compiled from a simple text file using TeamTNT's Boom utilities (or libdoomwad). TeamTNT had the great thought to store texture names (strings) in the C-string (null terminated) format, making lump handling easier. It is important to know that texture order is important. There is a start texture and an end texture, and when you use this in a level, the game cycles through each texture between them. If you put one at the start of your texture resource and one at the end, guess what, the game will cycle through every texture.
The SWITCHES lump is similar, but it contains switch sequences.
Boom added several nice features to DEH support, named BEX. This is also a plain text file, but easier to use and able to do more things.
You can write a patch, give it a DEH or BEX extension, and load it separately; or you may embed it in a wad file in a lump named DEHACKED. Not all source ports support this, however, most do.
The SCRIPTS lump is optional; it contains your scripts in uncompiled text format. The game engine ignores this lump, but other wad authors may want to see how you performed some cool scripted action. By including a SCRIPT lump, you help the community learn and make better map scripts.
1.4.0