The Doom Engine WAD Reader and Extractor is an application designed for viewing and extracting information found inside data files known as “WAD” files.

For the longest time since I created levels for DOOM and DOOM-based games I wanted to get into the technical side of the idTech1 engine, but sadly I never got around that. I don’t know why it turned out this way. Maybe because there’s never enough time, or maybe because I was so much involved in the Quake engine development scene.

I always wanted to build a DOOM-like game. I have a great appreciation for the technical design style and fast game-play. To save valuable time I decided to use DOOM’s original art assets while I develop the game engine to spare myself the extra effort and management of new original art asset development. Using original DOOM assets will further help doing a more direct comparison against the original DOOM.

Then my first anticipated problem steps into the limelight… I’m going to use Microsoft .NET and Microsoft XNA for the project. That means for XNA best practices I should use its content pipeline and not write my own WAD reading code and content management. It is totally possible technically to write my own code to load DOOM assets in the game engine, but that would make my code probably less compatible when thinking along the lines of making versions for other Microsoft platforms that are not PCs. It becomes obvious that the assets stored inside the WAD file needs to be extracted and written to disk as standard multimedia assets that can be loaded and compiled by XNA’s content pipeline to its binary XNB file format.

I searched the internet for a tool that could extract the assets and I found one developed by Terry Butler.
His tool did the job well to extract the data from the WAD, but unfortunately there were no source code available for download on his website. I realized I had to actually have an understanding how the WAD file structure functioned, because at some point in time I may need to write another tool that can package standard art assets back into a WAD for level design purposes as I’m planning to most likely use DoomBuilder as the level editor. I started doing some research on the internet regarding the WAD file format and came across a great specification document written by Matthew Fell detailing not only the WAD file structure, but also the individual lumps of data that make up the assets of the game.

The formats of the individual art assets are pretty interesting…

The digital sound format were pretty easy to get loaded. It is stored as raw sound data in mono channel at a sample rate of 11025 hz, 8-bits per sample. All we had to do is to take this raw sound data and write it to disk as a standard wave file with a custom wave writer built into the project.

The graphics format is stored in two different formats.
The floor and ceiling textures are all 64×64 pixels stored as raw 8-bit pixel data, which is also known as “flats”. All other graphics are stored in another custom format which seems to be stored as columns of pixels. My take on why this is the case is that all textures that are stored in this custom column-based format are all displayed on the screen either as 2D images or are rendered in the 3D environment vertically as opposed to “flats” that are rendered horizontally. It is probably a speed optimization feature of the original DOOM engine to allow easy access to columns of pixels in a texture to render, because the engine itself does ray-tracing which draws columns of pixels to the screen with probably little to no overdraw.

Even drawing the columns themselves are quite optimal. No CPU power is wasted on transparent pixels. Each column of pixels may be made up of one or more “posts” of pixels. A post is basically a starting offset where to start drawing pixels within the column followed by how many pixels to draw downwards. If the following byte after the last pixel of the post has a value of 255 it marks the end of the column, but if it doesn’t have a value of 255 it marks the position of the start of the next post within the column.

The level data gets loaded into a custom data structure and saved to disk as LEV files. These files consist of a header which is followed by the level data lumps and closer to the end of the file a directory structure that contains information regarding the name of each lump, its offset within the file and the length of byte data following the offset position. The lump data is saved exactly as its read from the WAD file. The level data doesn’t get visualized within the tool at the time of this writing.

Most of the lumps that are not recognized as graphics, levels or sounds are not visualized or extracted to disk at the moment, but this will be fixed with the next update to the Doom WAD Reader & Extractor.

Special thanks goes out to Matthew Fell for his excellent Doom specifications document which made this tool and source release a possibility.

Download the latest version of the Doom WAD Reader & Extractor project.
Doom Engine WAD Reader and Extractor v1.0