doom maps

8/3/2019 Doom maps

1/3

I wrote a custom Java program to parse the Doom WAD file format and render all the levels in a simple obliqueprojection. All the hidden areas are shown, and the sprites from all the skill levels are shown. I wrote all the 3D codemyself, and I'm not exactly stellar in higher math, so these may not be as great looking as they could be. Likewise, Ihave not settled on the best presentation, so I may regenerate these maps as I find better ways to represent all theinformation in a clear way. Technical details on these maps at the bottom of the page.

Maps

E1M1 - Hangar (1.45MB) E1M2 - Nuclear Plant (3.09MB) E1M3 - Toxin Refinery (1.92MB)

E1M4 - Command Control (2.04MB) E1M5 - Phobos Lab (1.50MB) E1M6 - Central Processing (3.45MB)

E1M7 - Computer Station (2.38MB) E1M8 - Phobos Anomaly (11.7MB) E1M9 - Military Base (1.71MB)

E2M1 - Deimos Anomaly (1.00MB) E2M2 - Containment Area (4.19MB)E2M3 - Refinery (1.79MB)

Page 1 of 3Doom Maps - Ian-Albert.com

12/6/2011http://ian-albert.com/games/doom_maps/

8/3/2019 Doom maps

2/3

E2M4 - Deimos Lab (3.00MB) E2M5 - Command Center (3.31MB) E2M6 - Halls of the Damned (2.16MB)

E2M7 - Spawning Vats (2.35MB) E2M8 - Tower of Babel (3.75MB) E2M9 - Fortress of Mystery (1.37MB)

E3M1 - Hell Keep (2.19MB) E3M2 - Slough of Despair (1.90MB) E3M3 - Pandemonium (1.87MB)

E3M4 - House of Pain (2.29MB) E3M5 - Unholy Cathedral (3.06MB) E3M6 - Mt. Erebus (12.2MB)

E3M7 - Limbo (3.66MB) E3M8 - Dis (3.10MB) E3M9 - Warrens (3.63MB)

Technical Details

The Doom WAD format is very well documented. Seeing as any new device with a screen and buttons gets a Doomport written for it, there's plenty of info about how the game works. In a nutshell, Doom maps are actually 2D


12/6/2011http://ian-albert.com/games/doom_maps/

8/3/2019 Doom maps

3/3

blueprints with different floor and ceiling heights. The game is not truly 3D, as there are no floors on top of f loors,such as in a two-story house. This makes it very suitable for mapping, since you can see everything at once withoutoverlap when viewed overhead. Even if I could decode other 3D games and render them they would not look verygood because there would be no good way to show everything without some areas being obscured by other areas.

My renderer was written from scratch. I might have been able to use some existing libraries out there, but my needswere a bit unique. For one, most 3D rendering is done in perspective. Farther objects are smaller than near objects.But for this project I wanted things "flattened out", more like an isometric or oblique drafting drawing. Secondly, most3D programming is intended for immediate screen display, and is thus limited to the screen resolution of yourcomputer. In order to render some of these maps at full 1:1 resolution that would require an impossibly large screen.So I rolled my own simple 3D renderer. It's not fast, but it has the advantages of doing exactly what I want and isable to output images of almost unlimited size.

Pixel data is written directly to a BMP on disk. While this is slow, it means I can create images larger than myphysical memory would otherwise permit. It also means I can recover partial output in case of a crash. Very useful indebugging. For 3D rendering I encapsulate this BMP object inside a Z buffer wrapper. The Z buffer wrapper createsa parallel file of 32-bit floating point numbers to record pixel depth. For small images, both the BMP and Z bufferclasses do everything in memory and write the results out at the end (much faster!).

If you don't know what a Z buffer is, allow me to explain (because I thought it was pretty neat when I first came tounderstand it). When you're drawing a 3D scene you will often have two polygons that overlap. The way thecomputer decides which to draw in front is by using a Z buffer. The Z buffer is a set of depth values, one for eachpixel, that tells how "deep" each pixel is. When you draw the first polygon it will draw the pixels and record the depthof each pixel of the polygon in the Z buffer. When you draw the second polygon it will check the Z buffer for eachpixel and compare it to the depth of the pixels of the second polygon. If the depth of the new polygon is on top ofwhat's in the Z buffer then the polygon will be rendered. If it's below what's already been drawn then the polygon willnot be rendered because it's obscured in the scene. Except instead of it working on a polygon-by-polygon basis itworks on a pixel-by-pixel basis, so you can even render intersecting polygons properly.

(Just to be clear, by depth I mean how far the polygon is from the viewer in the 3D scene. Polygons that are closerto the viewer should be drawn on top of polygons that are farther from the viewer.)

On these maps you'll notice the walls facing away from the viewer are translucent. Translucent polygons pose a bitof a problem with Z buffering because you no longer have a single depth to test for. If you had two polygonsrendered, an opaque one with a translucent one on top, and then rendered a third polygon at a depth in between thefirst two then what happens? It will either not draw at all because it thinks the translucent polygon will cover it up, orit ignores the translucent polygon and draws right over the top of it. Both choices would produce undesirable results.My solution was to make my renderer queue up such translucent polygons and render them last. I don't know if thisis the "right" answer, but it seems to get the proper result.


12/6/2011http://ian-albert com/games/doom maps/

doom maps

Documents