From MSFell@aol.com  Thu Dec 15 1994, upload as DMSPEC16.ZIP


------------------------------------------------------------------------------

                           T H E   U N O F F I C I A L
=================     ===============     ===============   ================
\\ . . . . . . .\\   //. . . . . . .\\   //. . . . . . .\\  \\. . .\\// . .//
||. . ._____. . .|| ||. . ._____. . .|| ||. . ._____. . .|| || . . .\/ . ..||
|| . .||   ||. . || || . .||   ||. . || || . .||   ||. . || ||. . . . . . .||
||. . ||   || . .|| ||. . ||   || . .|| ||. . ||   || . .|| || . | . . . ..||
|| . .||   ||. _-|| ||-_ .||   ||. . || || . .||   ||. _-|| ||-_.|\ . . . .||
||. . ||   ||-'  || ||  `-||   || . .|| ||. . ||   ||-'  || ||  `|\_ . .|..||
|| . _||   ||    || ||    ||   ||_ . || || . _||   ||    || ||   |\ `-_/| .||
||_-' ||  .|/    || ||    \|.  || `-_|| ||_-' ||  .|/    || ||   | \  / -_.||
||    ||_-'      || ||      `-_||    || ||    ||_-'      || ||   | \  / | '||
||    `'         || ||         `'    || ||    `'         || ||   | \  / |  ||
||            .===' `===.         .==='.`===.         .===' /==. |  \/  |  ||
||         .=='   \_|-_ `===. .==='   _|_   `===. .===' _-|/   `==  \/  |  ||
||      .=='    _-'    `-_  `='    _-'   `-_    `='  _-'   `-_  /|  \/  |  ||
||   .=='    _-'          `-__\._-'         `-_./__-'         `' |. /|  |  ||
||.=='    _-'                                                     `' | /==.||
=='    _-'         S         P         E         C         S          \/  `==
\   _-'                                                                `-_  /
 `''                                                                      ``'
                       Release v1.666 - December 15th, 1994
                   Written by: Matthew S Fell (msfell@aol.com)

          "The poets talk about love, ...but what I talk about is DOOM,
                  because in the end, DOOM is all that counts."
            - Alex Machine/George Stark/Stephen King, _The Dark Half_
------------------------------------------------------------------------------








----------
DISCLAIMER
----------

        These specs are to aid in informing the public about the games
DOOM and DOOM 2, by id Software.  In no way should this promote your
killing yourself, killing others, or killing in any other fashion.
Additionally, the author does not claim ANY responsibility
regarding ANY illegal activity concerning this file, or indirectly related
to this file.  The information contained in this file only reflects
id Software indirectly, and questioning id Software regarding any
information in this file is not recommended.

----------------
COPYRIGHT NOTICE
----------------

This article is Copyright 1994 by Matt Fell.  All rights reserved.
You are granted the following rights:

I.  To make copies of this work in original form, so long as
      (a) the copies are exact and complete;
      (b) the copies include the copyright notice and these paragraphs
          in their entirety;
      (c) the copies give obvious credit to the author, Matt Fell;
      (d) the copies are in electronic form.
II. To distribute this work, or copies made under the provisions
    above, so long as
      (a) this is the original work and not a derivative form;
      (b) you do not charge a fee for copying or for distribution;
      (c) you ensure that the distributed form includes the copyright
          notice, this paragraph, the disclaimer of warranty in
          their entirety and credit to the author;
      (d) the distributed form is not in an electronic magazine or
          within computer software (prior explicit permission may be
          obtained from the author);
      (e) the distributed form is the NEWEST version of the article to
          the best of the knowledge of the distributor;
      (f) the distributed form is electronic.

        You may not distribute this work by any non-electronic media,
including but not limited to books, newsletters, magazines, manuals,
catalogs, and speech.  You may not distribute this work in electronic
magazines or within computer software without prior written explicit
permission.  These rights are temporary and revocable upon written, oral,
or other notice by the author. This copyright notice shall be governed
by the laws of the state of Ohio.
        If you would like additional rights beyond those granted above,
write to the author at "msfell@aol.com" on the Internet.


--------
CONTENTS
--------

[1] Introduction
        [1-1] id Software's Copyright
        [1-2] What's New
[2] The Basics
        [2-1] Pwads
        [2-2] DOOM version information
        [2-3] Terminology conventions
[3] List of DOOM.WAD Directory Entries
[4] The Levels
        [4-1] ExMy or MAPxy
        [4-2] THINGS
                [4-2-1] Thing Types
                [4-2-2] Thing Sizes
                [4-2-3] Thing Options
        [4-3] LINEDEFS
                [4-3-1] Linedef Flags
                [4-3-2] Linedef Types
        [4-4] SIDEDEFS
        [4-5] VERTEXES
        [4-6] SEGS
        [4-7] SSECTORS
        [4-8] NODES
        [4-9] SECTORS
                [4-9-1] Special Sector Types
        [4-10] REJECT
        [4-11] BLOCKMAP
[5] Graphics
        [5-1] Picture Format
[6] Flats (Floor and Ceiling Textures)
        [6-1] Animated Floors, see [8-4-1]
[7] Sounds and Music
        [7-1] PC Speaker Sound Effects
        [7-2] Soundcard Sound Effects
        [7-3] Music
        [7-4] GENMIDI
        [7-5] DMXGUS
[8] Miscellaneous Lumps
        [8-1] PLAYPAL
        [8-2] COLORMAP
        [8-3] ENDOOM
        [8-4] TEXTURE1 and TEXTURE2
                [8-4-1] Animated Walls
                [8-4-2] The SKY Textures
        [8-5] PNAMES
        [8-6] DEMOs
                [8-6-1] Level changes from 1.2 to 1.666 DOOM.WAD
[9] Savegame Files

[10] The DOOM.EXE File
        [10-1] Version 1.2 DOOM.EXE Data Segment Overview
        [10-1] Version 1.666 DOOM.EXE Data Segment Overview
        [10-3] Detail on some EXE Data Structures

APPENDICES

[A-1] Backus-Naur Form definitions of wad elements
[A-2] Engine limits
[A-3] DOOM.WAD changes and errors
[A-3] A BLOCKMAP algorithm
[A-4] Other helpful documents
[A-5] Acknowledgments


-------------------------
CHAPTER [1]: Introduction
-------------------------

  DOOM is simply an all-time great game. A big factor in its success
and durability is the plethora of user-created add-ons. id Software
tacitly encouraged them by including the -FILE parameter, and by having
a data format that is both straightforward and easy to understand.
DOOM is basically two files, DOOM.EXE and DOOM.WAD. DOOM.EXE is the
"engine" which does the display and controls the game, and DOOM.WAD has
ALL of the graphics, sound, and map/level data that the engine uses.
The -FILE parameter allows small or large external "WAD" files to be
incorporated, changing any number of those graphics, sounds, and maps.
  DOOM 2 has many things in common with DOOM. It uses the same EXE file
as version 1.666 of DOOM, and the WAD file format is the same. It's just
the contents of the WAD file that are different; there are more enemies!
more pictures! more weapons! more stuff!!

  This document explains in great detail nearly all aspects of the doom
WAD file format. And a new chapter (10) documents the location of data
within DOOM.EXE itself, so that various unusual game-play changes can
be made. This information has been updated to apply to DOOM 2 as well
as DOOM 1.
  The specs were originally conceived as an aid to programmers making
DOOM utilities, especially map-editors. Coincidentally, there might also
be information useful to advanced level designers and players.
  The material herein is somewhat technical and it is not recommended for
beginners, unless they are determined. There are some other very useful
documents in existence; I list the ones I know of in Appendix [A-3].


[1-1]: id Software's Copyright and the Shareware Version
========================================================

  My comments and statements are by no means official, and the excerpts
below are just the parts that I think are relevant to these specs. Please
read the LICENSE.DOC and README.EXE that came with DOOM.

  The LICENSE.DOC says:

    "You shall not:  rent, lease, sell, distribute for money or other
    consideration, modify, translate, disassemble, decompile, reverse
    engineer, or create derivative works based upon the Software.
    Notwithstanding the foregoing, you may create a map editor, modify
    maps and make your own maps (collectively referenced as the
    "Permitted Derivative Works") for the Software.  You may not sell
    or distribute any Permitted Derivative Works but you may exchange
    the Permitted Derivative Works at no charge amongst other end-users.
    In order to commercially distribute any such map editor or data
    utility you must first sign ID's Data Utility License and ID
    reserves the right to deny authorization to commercial distribute
    the any such map editor or data utility.  You may request a copy of
    the Data Editor License from ID"

    "(except for backup purposes) You may not otherwise reproduce, copy
    or disclose to others, in whole or in any part, the Software."

  The README says:

    "id Software respectfully requests that you do not modify the levels
    for the shareware version of DOOM.  We feel that the distribution of
    new levels that work with the shareware version of DOOM will lessen a
    potential user's incentive to purchase the registered version.

    "If you would like to work with modified levels of DOOM, we encourage
    you to purchase the registered version of the game."

  If you are making add-ons, plan on them not working on the shareware
game, and plan on including statements about the trademarks and copyrights
that id Software owns, as well as disclaimers that they won't support your
add-on product, nor will they support DOOM after it has been modified.


[1-2]: What's New
=================

  Each new version of these specs renders the previous version obsolete.
  This document has grown considerably in size, and to fight that trend,
I'll not discuss it any more.
  It has now been five months since the specs were updated. I won't talk
about that either. I'll just apologize for not releasing updates in late
May and July like I should have. Those updates would have been numbered
1.4 and 1.5, so perhaps that's why this is version 1.666.
  Here's some of the new or revised sections since the 1.3 specs:

    - DOOM 2 info, especially in [4-2-1] and [4-3-2]
    - lots of info on the DOOM.EXE file in [10]
    - BNF style definitions in [A-1]
    - DOOM engine limits in [A-2]
    - the DEMO format [8-6]
    - the ENDOOM lump [8-3]
    - comprehensive list of WAD lumps in [3]

    - many parts rewritten for clarity
    - changes in terminology to reflect id's where possible, and to be
        more consistent throughout
    - reformatted again, errors and typos corrected


-------------------
CHAPTER [2]: Basics
-------------------

  The starting point is the concept of "WAD". It is not an acronym, it
just means a collection of data. Throughout this document, "WAD" or "wad"
will mean a file with a .WAD extension that contains data for the doom
engine to use.
  A WAD file has three parts:

  (1) a twelve-byte header
  (2) one or more "lumps"
  (3) a directory or "info table" that contains the names, offsets, and
        sizes of all the lumps in the WAD

  The header consists of three four-byte parts:

    (a) an ASCII string which must be either "IWAD" or "PWAD"
    (b) a 4-byte (long) integer which is the number of lumps in the wad
    (c) a long integer which is the file offset to the start of
          the directory

  The directory has one 16-byte entry for every lump. Each entry consists
of three parts:

    (a) a long integer, the file offset to the start of the lump
    (b) a long integer, the size of the lump in bytes
    (c) an 8-byte ASCII string, the name of the lump, padded with zeros.
          For example, the "DEMO1" entry in hexadecimal would be
          (44 45 4D 4F 31 00 00 00)

  A "lump" is just data, in one of several different formats. Some
contain sound data, some contain graphics data, some contain level
structure data, etc. These specs are mostly concerned with delineating
the formats of the various lump types. There are 10 different types of
map/level lump formats, each has a section in chapter [4] (sections 2-11).
There are 13 other types of lump formats, listed below with the section
where the format is explained, and the actual lump names in parentheses.
Also, Appendix [A-1] has definitions of the structures of all these
WAD elements.

  [8-1] palettes (PLAYPAL)
  [8-2] colormaps (COLORMAP)
  [8-3] dos exit text (ENDOOM)
  [8-6] demos (DEMO1, DEMO2, and DEMO3)
  [8-4] texture composition list (TEXTURE1 and TEXTURE2)
  [8-5] wall patch "number for name" indexing list (PNAMES)
  [7-4] midi mapping (GENMIDI)
  [7-5] Gravis UltraSound patch mappings (DMXGUS)
  [7-1] PC speaker sound effects (DP*)
  [7-2] Soundcard sound effects (DS*)
  [7-3] songs (D_*)
  [6]   flats (lumpnames between F_START and F_END)
  [5]   all other graphics (all other lumps)

  The "marker" and "label" lump names like "S_START" and "E1M1" (or
"MAP01") do not actually refer to lumps - they have zero length. They
merely serve to mark the beginning or end of a set of related lumps.

  It is possible to include other directory entries and lumps in a wad
file, e.g. an entry called CLOWNS could point to a lump that includes the
level creator's name, date of completion, and the latitude and longitude
of the Holy Grail. None of these non-standard entries will be used by
DOOM, nor will they cause it problems.


[2-1]: Pwads
============

  There are two types of wad files. The original DOOM.WAD and DOOM2.WAD
files are "IWAD"s, or "Internal wads", meaning they contain all of the
data necessary to play. The other type is the "PWAD" file, "Patch wad",
an external file which has the same structure, but with far fewer entries
in the directory. The data in a pwad is substituted for the original data
in the DOOM.WAD, thus allowing for much easier distribution of new levels.
Only those resources listed in the pwad's directory are changed,
everything else is loaded from the IWAD. All external wads should have
the "PWAD" indicator, as id has requested.
  A typical pwad might contain new data for a single level, in which
case it would contain the 10 lumps and 11 directory entries necessary
to define the level (as described in chapter [4]).
  A pwad file may contain more than one level or parts of levels, in
addition to replacement graphics, sounds, etc. (as of version 1.666,
sprites and flats do NOT work from pwads - see chapter [5] for more).
In fact, there is apparently no limit to how many entries may be in a
pwad. The original doom levels are pretty complicated, and they are
from 50-200 kilobytes each in size, uncompressed.
  Pwad files need to have the extension .WAD to work. Many of them have
descriptive names, e.g. if J.R.R. Tolkien made a new level, he might call
it GONDOLIN.WAD - to use this level, a player would type

  DOOM -FILE GONDOLIN.WAD 

at the command line, along with any other parameters. More than one
external file can be added, thus in general:

  DOOM -FILE [pwad_filename] [pwad_filename] [pwad_filename] ...

  If there are duplicate entries amongst the directories of all the
wads being "added", the pwads listed LAST take precedence.
  When the game loads, a "modified game" message will appear if there
are any pwads involved, reminding the player that id Software will not
give technical support or answer questions regarding modified levels.
  With DOOM version 1.666, there is also the @responsefile option for
listing command line parameters and -file specifications. See the DOOM
README or the latest FAQ for more information. Also, there are numerous
"front-end" utilities that make it easier to play pwads, e.g. load several
external files at once, warp to certain levels, specify options, etc.


[2-2]: DOOM versions
====================

Version Date    Time    Is

1.0     10dec93 01:00   first release (aka DOOM Operating System 0.99)
1.1     16dec93 01:10   slightly different from 1.0, newer dos extender
1.2     17feb94 01:20   modem play added!
1.3     -       -       unauthorized beta release
1.4     28jun94 01:04   shareware beta
1.5     ??jul94 ?       shareware beta
1.6     03aug94 01:06   shareware beta
1.666   01sep94 16:42   registered full upgrade!
1.666   ?       ?       DOOM 2!

  The important releases as of this writing are 1.2 and 1.666. Hopefully,
everyone will move up to 1.666 soon; it has many important improvements
over 1.2. The 1.4, 1.5, and 1.6 shareware betas contained increasing
amounts of the stuff that's now in 1.666, but there's no information
here about what exactly those changes were. One, I didn't keep track,
and two, they're not really important.
  See appendix [A-3] for some miscellany about what has changed from
version to version.


[2-3]: Terminology conventions
==============================

  Throughout this document, I will use the following conventions for
numbers and variable types:

(1) Most numbers will be decimal. Hexadecimal numbers will usually be
        labeled thus: 0xffff or $ffff. But sometimes I'll say "hex ...".
        And in tablature form, a column heading "HEX" indicates all the
        numbers in that column are hexadecimal.
(2) "byte" is of course the generic, 8 bits. It will usually mean one
        8-bit component of a larger data type, or an 8-bit ASCII
        character, or some such. As a number, it is an unsigned 8-bit
        integer (0..255).
(3) "short" is a signed 16-bit integer (-32768..32767), stored in
        lo-hi format.
(4) "ushort" or "unsigned short" is an unsigned 16-bit integer (0..65535).
(5) "integer" or "long" is a signed 32-bit integer. If you don't read
        this first, my use of the word "integer" might not be immediately
        apparent.
(6) "string8" or "8-byte string" is an ASCII string with length between
        1 and 8 characters inclusive. If its length is less than 8, the
        remaining bytes are zeros.
(7) The first byte of a file or any data structure, for addressing and
        offset purposes, is byte #0, not byte #1.
(8) Some abbreviations I use: E1, E2, and E3 refer to episodes 1, 2, and
        3 respectively. "The EXE" means the file DOOM.EXE.
(666) Any reference to this number is purely intentional.


-----------------------------------------------
CHAPTER [3]: List of DOOM.WAD Directory Entries
-----------------------------------------------

  There are over 2000 entries in the DOOM.WAD directory. Most of them
can be easily described in groups, and so are not explicitly mentioned
in this list. This includes the sprites (see [4-2-1] for sprite names
and [5] for the sprite lump naming system), the wall patches ([8-4] and
[8-5] have more info), the flats (chapter [6]), the sounds and songs
(chapter [7]), and the map data lumps (chapter [4]). All the others
are listed here.
  There have been several changes from version to version. The "Ver"
column indicates in which doom versions the lump exists:

___     no indication means it is in every version. Most are like this.
1.1     it was in 1.0 and 1.1, but not in 1.2 and later. It is obsolete.
1.2     it is not in 1.1 and earlier, only in 1.2 and up.
1.6     it is not in 1.2 and earlier, only in 1.666 and up.
r       it is only in the registered version, not the shareware.
1       it is only in DOOM 1, it is not in DOOM 2.
2       it is only in DOOM 2, it is not in DOOM 1.

  In the lump names, x (and y and e) indicates variable ASCII
characters, and * can be replaced by an ASCII string (up to the
8-byte lumpname limit).

LumpName  Ver   Description
--------  ---   -----------
PLAYPAL         fourteen 256 color palettes. See [8-1].
COLORMAP        maps colors in the palette down to darker ones. [8-2].
ENDOOM          text message displayed when you exit to DOS. [8-3].
DEMOx           x=1-3, are the demos. [8-6].
ExMy            subsequent entries define a single level's data. [4].
MAPxy     2     like ExMy, but for DOOM 2.
TEXTURE1        list of wall texture names and their composition data,
                  used in the SIDEDEF portion of each level. [8-4].
TEXTURE2  r     more wall texture compositions.
PNAMES          lists all lump names used as wall patches. [8-5].
GENMIDI         General Midi standard instrument data. [7-3].
DMXGUS          Gravis Ultra Sound instrument patches. [7-4].

D_ExMy          music for a doom 1 level. [7-2].
D_INTER         music played on the summary screen between levels.
D_INTRO         music played when the game starts.
D_INTROA  1.2   more introductory music.
D_VICTOR        music played on the victory text-screen after an episode.
D_BUNNY   r     music for while a certain rabbit has his story told...
D_*       2     music for a doom 2 level.

DP_*      vary  PC speaker sound effects. [7-1].
DS_*      vary  Soundcard sound effects. [7-1].

  All the remaining entries in the directory, except the flats between
F_START and F_END, and the "markers" like S_START, refer to lumps which
are pictures, in the doom/wad graphic format described in chapter [5].
The flats are also pictures, but in a format described in chapter [6].
  The next seven are full screen (320 by 200 pixel) pictures. After
that, ST* are status-bar pictures, WI* are for the screens between
levels, and M_* are for menus.

HELP1           Ad-screen says Register!, with some screen shots.
HELP2           Actual help, all the controls explained.
TITLEPIC        Maybe this is the title screen? Gee, I dunno...
CREDIT          People at id Software who created this great game.
VICTORY2  r     Screen shown after a victorious end to episode 2.
PFUB1     r     A nice little rabbit minding his own peas and queues...
PFUB2     r     ...a hint of what's waiting in Doom 2.

ENDx      r     x=0-6, big red "THE END" gets shot up.
AMMNUMx         x=0-9. Small grey digits for ammo count (15/200 etc).
STxBARy   1.1   x=M or A, y= L or R. Status bar used to be in pieces.
STCHAT    1.1   Status bar used to have a "chat" box.
STRSNUMx  1.1   x=0-9. Small red digits.
STWEAPx   1.1   x=0-5. COOL little weapon icons. Why'd they drop them?
STFRAGS   1.1   Tiny "FRAG" to be placed on top of part of status bar.
STBAR     1.2   Status Bar as used in deathmatches.
STGNUMx         x=0-9. Small grey digits used on the "Arms" panel.
STTNUMx         x=0-9. Big red digits used for Armor, Health, etc.
STTMINUS  1.6   Big red "-" used for negative frags.
STYSNUMx        x=0-9. Small yellow digits used on the "Arms" panel.
STTPRCNT        Big red % used in Armor and Health.
STKEYSx         x=0-5. Blue/Yellow/Red Keycards and Skullkeys.
STDISK          Disk, used at bottom right corner during disk accesses.
STCDROM   1.6   CD, used during CD-ROM accesses.
STARMS          "Arms" panel which replaces "Frags" in non-deathmatch.
STCFNxxx        xxx=033-095, also 121. Small red ASCII characters.
STFBx           x=0-3. Green/black/brown/red squares, for ST player faces.
STPBx           x=0-3. Squares with bottoms, for inter-level screens.
STFSTxy         x=0-4, y=0-2. Player face. x=0 is 100% health...x=4 is
                  very low health. y=0 is glancing right, y=2 left.
STFTLx0         x=0-4. Face looking left, player hurt from that direction.
STFTRx0         x=0-4. Face looking right.
STFOUCHx        x=0-4. Face looking surprised (hurt bad).
STFEVLx         x=0-4. Face with a grin (when pick up new weapons).
STFKILLx        x=0-4. Face with a grimace (when killing foes).
STFGOD0         Face with yellow eyes (invulnerable).
STFDEAD0        Dead face.
BRDR_*          Tiny pictures used as a border between a less-than-full
                  screen view and the "outside" marbleized zone. TL is
                  top left, BR bottom right, you can guess the rest.
WIBONUS   1.1   Medium sized red text "BONUS"
WISCORE   1.1   "SCORE"
WIMSTPx   1.1   x=0-3. Red text "ONE" to "FOUR".
WIMSTBx   1.1   x=0-3. Grey text "ONE" to "FOUR".
WIMINUS   1.6   Small red "-" used for negative frags.
WIMAPx          x=0-2. 320x200 maps used on inter-level screens for e1,2,3.
WIAe0x0y        patches used to animate inter-level maps.
WIURH0          "YOU ARE HERE" with an arrow pointing left.
WIURH1          "YOU ARE HERE" with an arrow pointing right.
WISPLAT         Splat mark that indicates a completed level.
WIOSTK          "KILLS"
WIOSTI          "ITEMS"
WIF             "FINISHED"
WIMSTT          "TOTAL"
WIOSTS          "SCRT"
WIOSTF          "F."
WITIME          "TIME"
WIPAR           "PAR"
WIMSTAR         "YOU"
WIPCNT          "%"
WINUMx          x=0-9. Medium sized red digits.
WICOLON         ":"
WISUCKS         "SUCKS"
WIFRGS          "FRAGS"
WILVxy          x=0-2, y=0-8. E(x+1)M(y+1) level names in grey/white letters.
WIPx            x=1-4. Red "P1" - "P4", for multiplayer summaries.
WIBPx           x=1-4. Grey "P1" - "P4"
WIKILRS         Small red "KILLERS" going sideways up, for deathmatches.
WIVCTMS         Small red "VICTIMS" for the top of the deathmatch chart.
WISCRT2         "SECRET"
WIENTER         "ENTERING"
M_DOOM          The DOOM logo
M_RDTHIS        Big red "Read This!"
M_OPTION        "Options"
M_QUITG         "Quit Game"
M_NGAME         "New Game"
M_SKULL1        The skull indicator with eyes lit.
M_SKULL2        The skull indicator with eyes unlit.
M_THERMO        The marker on e.g. the Sfx volume "thermometer".
M_THERMR        The right end of the thermometer.
M_THERML        The left end.
M_THERMM        The middle, repeated over and over.
M_ENDGAM        "End Game"
M_PAUSE         "Pause"
M_MESSG         "Messages:"
M_MSGON         "on"
M_MSGOFF        "off"
M_EPISOD        "Which Epsiode?"
M_EPI1          "Knee-Deep In The Dead"
M_EPI2          "The Shores Of Hell"
M_EPI3          "Inferno"
M_HURT          "Hurt me plenty."
M_JKILL         "I'm too young to die."
M_ROUGH         "Hey, not too rough."
M_SKILL         "Choose Skill Level:"
M_NEWG          "NEW GAME" (title of New Game menu)
M_ULTRA         "Ultra-Violence."
M_NMARE   1.2   "Nightmare!"
M_SVOL          "Sound Volume"
M_OPTTTL        "OPTIONS" (title of Options menu)
M_SAVEG         "Save Game"
M_LOADG         "Load Game"
M_DISP          "Display"
M_MSENS         "Mouse sensitivity"
M_GDHIGH        "high"
M_GDLOW         "low"
M_DETAIL        "Graphic Detail:"
M_DISOPT        "DISPLAY OPTIONS"
M_SCRNSZ        "Screen Size"
M_SGTTL         "SAVE GAME"
M_LGTTL         "LOAD GAME"
M_SFXVOL        "Sfx Volume"
M_MUSVOL        "Music Volume"
M_LSLEFT        Load/save box, left part
M_LSCNTR        Load/save box, center part (repeated)
M_LSRGHT        Load/save box, right part

  The following entries are markers that do not point to a lump; they
have zero size:

S_START         marks the start of the item/monster "sprite" section.
                  See chapter [5] for the naming convention used here.
S_END           is immediately after the last sprite.
P_START         marks the beginning of the wall patches.
P1_START          before the first of the shareware wall patches.
P1_END            after the last of the shareware wall patches.
P2_START  r       registered wall patches.
P2_END    r       registered wall patches.
P_END           marks the end of the wall patches.
F_START         marks the beginning of the flats (floor textures).
F1_START          shareware flats.
F1_END            shareware flats.
F2_START  r       registered flats.
F2_END    r       registered flats.
F_END           marks the end of the flats.


-----------------------
CHAPTER [4]: The Levels
-----------------------

  Each level has eleven directory entries and ten lumps: E[x]M[y] (or
MAPxy in a DOOM 2 wad), THINGS, LINEDEFS, SIDEDEFS, VERTEXES, SEGS,
SSECTORS, NODES, SECTORS, REJECT, and BLOCKMAP.
  In the DOOM.WAD file, all of these entries are present for every level.
In a pwad external file, they don't all need to be present. Whichever
entries are in a pwad will be substituted for the originals. For example,
a pwad with just two entries, E3M6 and THINGS, would use all the walls
and such from the original E3M6, but could have a completely different
set of THINGS.


[4-1]: ExMy or MAPxy
====================

  DOOM 1 levels have an ExMy label in a wad's directory. x is a single
(ASCII) digit 1-3 for the episode number and y is 1-9 for the mission
number.
  DOOM 2 levels have a MAPxy label in a wad's directory. xy can range
from (ASCII) 01 to 32, for the level number.
  This label just indicates that the lump names following it are part
of the designated level. The label does not actually point to a lump,
and the size field in the directory is 0. The assignment of lumps to
this level stops with either the next ExMy or MAPxy entry, or with a
non-map entry like TEXTURE1.
  Without these labels, there would be no way to differentiate amongst
the many lumps named "THINGS", "LINEDEFS", etc.


[4-2]: THINGS
=============

  "Things" in DOOM are player start positions, monsters, weapons, keys,
barrels, etc. The size of each THINGS lump will be a multiple of ten,
since each thing requires ten bytes to describe it, in five <short>
fields:

(1) X position of thing (at level's inception)
(2) Y position of thing
(3) Angle the thing faces. On the automap, 0 is east, 90 is north, 180
      is west, 270 is south. This value is only used for monsters, player
      starts, deathmatch starts, and teleporter landing spots. Other
      things look the same from all directions. Values are rounded to
      the nearest 45 degree angle, so if the value is 80, it will
      actually face 90 - north.
(4) Type of thing, see next subsection, [4-2-1]
(5) Thing options, see [4-2-3]


[4-2-1]: Thing Types
--------------------

  Short 4 of 5, occupying bytes 6-7 of each thing record, specifies its
kind. The table below summarizes the different types. They are listed
in functional groups. You can easily get a numerical-order list by
extracting this table and SORTing it.

Dec/Hex The thing's number in decimal and hexadecimal. This is the
          number used in the THINGS lump on a level (ExMy or MAPxx).
V       Version of DOOM needed to use this object:
          no mark indicates all versions have this object
r         requires registered DOOM or DOOM 2
2         requires DOOM 2
Spr     The sprite name associated with this thing. This is the first
          four letters of the lumps that are pictures of this thing.
seq.    The sequence of frames displayed. "-" means it displays nothing.
          Unanimated things will have just an "a" here, e.g. a backpack's
          only picture can be found in the wad under BPAKA0. Animated
          things will show the order that their frames are displayed
          (they cycle back after the last one). So the blue key
          alternates between BKEYA0 and BKEYB0. The soulsphere uses
          SOULA0-SOULB0-C0-D0-C0-B0 then repeats. Thing 15, a dead
          player, is PLAYN0.
+       Monsters and players and barrels. They can be hurt, and they
          have a more complicated sprite arrangement. See chapter [5].
CAPITAL Monsters, counts toward the KILL ratio at the end of a level.
#       An obstacle, players and monsters can't move through it.
^       Hangs from the ceiling, or floats (if a monster).
$       A regular item that players may get.
!       An artifact item; counts toward the ITEM ratio at level's end.
          Note that 2025, the radiation suit, was an ITEM in version
          1.2, but it is not an ITEM in version 1.666 on. Also note
          that 2022 and 2024, invulnerability and invisibility, do not
          respawn in -altdeath games.

Dec. Hex  V Spr  seq.     Thing is:

  -1 ffff   ---- -        (nothing)
   0 0000   ---- -        (nothing)
   1 0001   PLAY +        Player 1 start (Player 1 start needed on ALL
levels)
   2 0002   PLAY +        Player 2 start (Player starts 2-4 are needed in)
   3 0003   PLAY +        Player 3 start (cooperative mode multiplayer games)
   4 0004   PLAY +        Player 4 start
  11 000b   ---- -        Deathmatch start positions. Should have >= 4/level
  14 000e   ---- -        Teleport landing. Where players/monsters land when
  14                        they teleport to the SECTOR containing this thing

3004 0bbc   POSS +      # FORMER HUMAN: regular pistol-shooting zombieman
  84 0054 2 SSWV +      # WOLFENSTEIN SS: guest appearance by Wolf3D blue guy
   9 0009   SPOS +      # FORMER HUMAN SERGEANT: black armor, shotgunners
  65 0041 2 CPOS +      # HEAVY WEAPON DUDE: red armor, chaingunners
3001 0bb9   TROO +      # IMP: brown, hurl fireballs
3002 0bba   SARG +      # DEMON: pink, muscular bull-like chewers
  58 003a   SARG +      # SPECTRE: invisible version of the DEMON
3006 0bbe r SKUL +     ^# LOST SOUL: flying flaming skulls, they really bite
3005 0bbd r HEAD +     ^# CACODEMON: red one-eyed floating heads. Behold...
  69 0045 2 BOS2 +      # HELL KNIGHT: grey-not-pink BARON, weaker
3003 0bbb   BOSS +      # BARON OF HELL: cloven hooved minotaur boss
  68 0044 2 BSPI +      # ARACHNOTRON: baby SPIDER, shoots green plasma
  71 0047 2 PAIN +     ^# PAIN ELEMENTAL: shoots LOST SOULS, deserves its
name
  66 0042 2 SKEL +      # REVENANT: Fast skeletal dude shoots homing missles
  67 0043 2 FATT +      # MANCUBUS: Big, slow brown guy shoots barrage of
fire
  64 0040 2 VILE +      # ARCH-VILE: Super-fire attack, ressurects the dead!
   7 0007 r SPID +      # SPIDER MASTERMIND: giant walking brain boss
  16 0010 r CYBR +      # CYBER-DEMON: robo-boss, rocket launcher

  88 0058 2 BBRN +      # BOSS BRAIN: Horrifying visage of the ultimate demon
  89 0059 2 -    -        Boss Shooter: Shoots spinning skull-blocks
  87 0057 2 -    -        Spawn Spot: Where Todd McFarlane's guys appear

2005 07d5   CSAW a      $ Chainsaw
2001 07d1   SHOT a      $ Shotgun
  82 0052 2 SGN2 a      $ Double-barreled shotgun
2002 07d2   MGUN a      $ Chaingun, gatling gun, mini-gun, whatever
2003 07d3   LAUN a      $ Rocket launcher
2004 07d4 r PLAS a      $ Plasma gun
2006 07d6 r BFUG a      $ Bfg9000
2007 07d7   CLIP a      $ Ammo clip
2008 07d8   SHEL a      $ Shotgun shells
2010 07da   ROCK a      $ A rocket
2047 07ff r CELL a      $ Cell charge
2048 0800   AMMO a      $ Box of Ammo
2049 0801   SBOX a      $ Box of Shells
2046 07fe   BROK a      $ Box of Rockets
  17 0011 r CELP a      $ Cell charge pack
   8 0008   BPAK a      $ Backpack: doubles maximum ammo capacities

2011 07db   STIM a      $ Stimpak
2012 07dc   MEDI a      $ Medikit
2014 07de   BON1 abcdcb ! Health Potion +1% health
2015 07df   BON2 abcdcb ! Spirit Armor +1% armor
2018 07e2   ARM1 ab     $ Green armor 100%
2019 07e3   ARM2 ab     $ Blue armor 200%
  83 0053 2 MEGA abcd   ! Megasphere: 200% health, 200% armor
2013 07dd   SOUL abcdcb ! Soulsphere, Supercharge, +100% health
2022 07e6 r PINV abcd   ! Invulnerability
2023 07e7 r PSTR a      ! Berserk Strength and 100% health
2024 07e8   PINS abcd   ! Invisibility
2025 07e9   SUIT a     (!)Radiation suit - see notes on ! above
2026 07ea   PMAP abcdcb ! Computer map
2045 07fd   PVIS ab     ! Lite Amplification goggles

   5 0005   BKEY ab     $ Blue keycard
  40 0028 r BSKU ab     $ Blue skullkey
  13 000d   RKEY ab     $ Red keycard
  38 0026 r RSKU ab     $ Red skullkey
   6 0006   YKEY ab     $ Yellow keycard
  39 0027 r YSKU ab     $ Yellow skullkey

2035 07f3   BAR1 ab+    # Barrel; not an obstacle after blown up 
                            (BEXP sprite)
  72 0048 2 KEEN a+     # A guest appearance by Billy

  48 0030   ELEC a      # Tall, techno pillar
  30 001e r COL1 a      # Tall green pillar
  32 0020 r COL3 a      # Tall red pillar
  31 001f r COL2 a      # Short green pillar
  36 0024 r COL5 ab     # Short green pillar with beating heart
  33 0021 r COL4 a      # Short red pillar
  37 0025 r COL6 a      # Short red pillar with skull
  47 002f r SMIT a      # Stalagmite: small brown pointy stump
  43 002b r TRE1 a      # Burnt tree: gray tree
  54 0036 r TRE2 a      # Large brown tree

2028 07ec   COLU a      # Floor lamp
  85 0055 2 TLMP abcd   # Tall techno floor lamp
  86 0056 2 TLP2 abcd   # Short techno floor lamp
  34 0022   CAND a        Candle
  35 0023   CBRA a      # Candelabra
  44 002c r TBLU abcd   # Tall blue firestick
  45 002d r TGRE abcd   # Tall green firestick
  46 002e   TRED abcd   # Tall red firestick
  55 0037 r SMBT abcd   # Short blue firestick
  56 0038 r SMGT abcd   # Short green firestick
  57 0039 r SMRT abcd   # Short red firestick
  70 0046 2 FCAN abc    # Burning barrel

  41 0029 r CEYE abcb   # Evil Eye: floating eye in symbol, over candle
  42 002a r FSKU abc    # Floating Skull: flaming skull-rock

  49 0031 r GOR1 abcb  ^# Hanging victim, twitching
  63 003f r GOR1 abcb  ^  Hanging victim, twitching
  50 0032 r GOR2 a     ^# Hanging victim, arms out
  59 003b r GOR2 a     ^  Hanging victim, arms out
  52 0034 r GOR4 a     ^# Hanging pair of legs
  60 003c r GOR4 a     ^  Hanging pair of legs
  51 0033 r GOR3 a     ^# Hanging victim, 1-legged
  61 003d r GOR3 a     ^  Hanging victim, 1-legged
  53 0035 r GOR5 a     ^# Hanging leg
  62 003e r GOR5 a     ^  Hanging leg
  73 0049 2 HDB1 a     ^# Hanging victim, guts removed
  74 004a 2 HDB2 a     ^# Hanging victim, guts and brain removed
  75 004b 2 HDB3 a     ^# Hanging torso, looking down
  76 004c 2 HDB4 a     ^# Hanging torso, open skull
  77 004d 2 HDB5 a     ^# Hanging torso, looking up
  78 004e 2 HDB6 a     ^# Hanging torso, brain removed

  25 0019 r POL1 a      # Impaled human
  26 001a r POL6 ab     # Twitching impaled human
  27 001b r POL4 a      # Skull on a pole
  28 001c r POL2 a      # 5 skulls shish kebob
  29 001d r POL3 ab     # Pile of skulls and candles
  10 000a   PLAY w        Bloody mess (an exploded player)
  12 000c   PLAY w        Bloody mess, this thing is exactly the same as 10
  24 0018   POL5 a        Pool of blood and flesh
  79 004f 2 POB1 a        Pool of blood
  80 0050 2 POB2 a        Pool of blood
  81 0051 2 BRS1 a        Pool of brains
  15 000f   PLAY n        Dead player
  18 0012   POSS l        Dead former human
  19 0013   SPOS l        Dead former sergeant
  20 0014   TROO m        Dead imp
  21 0015   SARG n        Dead demon
  22 0016 r HEAD l        Dead cacodemon
  23 0017 r SKUL k        Dead lost soul, invisible
                              (they blow up when killed)


[4-2-2]: Thing Sizes
--------------------

  The list below gives the radius, height, mass, speed, and toughness
of all the monsters in DOOM 1 and 2. Almost all non-monster things only
differ in their "radius", dependent on whether they are obstacles or not.
For collision purposes, things are NOT circular. They occupy a square
whose side equals slightly more than 2 times the radius. This square
does not turn, it is always aligned with the x and y axes of a level.
Consider a simple collision detection in a coordinate plane:

    IF (ABS(x1-x2) =< (r1+r2)) AND (ABS(y1-y2) =< (r1+r2)) THEN *collision*

  This will result in square objects centered on their (x,y) positions,
and that is the behavior that DOOM objects exhibit.
  I don't know why the horizontal size is "slightly more" than 2 times
the radius, but it is. A player cannot enter a corridor of width 32, but
can enter a corridor of width 33. Experiments have shown that no monster
can enter a corridor that is exactly (2*radius) wide. It must be bigger.
Moving up to the next multiple of 8 is a good idea, if not 16 or 32.
  Monsters CAN enter sectors that are exactly "Height" high. But obstacles
are infinitely high for collision purposes. A player on a very high ledge
might not be able to jump off, because of an obstacle right next to him,
even though it is far below him.
  Height is also used when under a crushing ceiling, and to determine
if an object can move from one sector to another. The space between the
highest floor and the lowest ceiling must be "Height" or greater for the
object to fit.
  Toughness indicates how much punishment a monster can take until it
dies. Bullets do 10 damage, Shotgun shells 70 (7 pellets, each is 10),
Plasma 20, Rockets 100, and the BFG does 1000 for a direct hit. There's
more info on this stuff in the DOOM FAQ.

Dec. Hex  Radius Height Mass Tough Speed  Sprite name or class of things:

-    -      16     56    100  (100)    -  PLAY
3004 0bbc   20     56    100    20     8  POSS
  84 0054   20     56    100    50     8  SSWV
   9 0009   20     56    100    30     8  SPOS
  65 0041   20     56    100    70     8  CPOS
3001 0bb9   20     56    100    60     8  TROO
3002 0bba   30     56    400   150    10  SARG 
  58 003a   30     56    400   150    10  SARG (Inviso model)
3006 0bbe   16     56     50   100     8  SKUL
3005 0bbd   31     56    400   400     8  HEAD
  69 0045   24     64   1000   500     8  BOS2
3003 0bbb   24     64   1000  1000     8  BOSS
  68 0044   64     64    600   500    12  BSPI
  71 0047   31     56    400   400     8  PAIN
  66 0042   20     56    500   300    10  SKEL
  67 0043   48     64   1000   600     8  FATT
  64 0040   20     56    500   700    15  VILE
   7 0007  128    100   1000  3000    12  SPID
  16 0010   40    110   1000  4000    16  CYBR
  88 0058   16     16   6666   250     0  BBRN
  72 0048   16     72   6666   100     0  KEEN
2035 07f3   10     42    100    20     0  BAR1
   -    -   20     16      -     -     -  most non-obstacles (e.g. gettables)
   -    -   16     16      -     -     -  most obstacles
  54 0036   32     16      -     -     -  large brown tree


[4-2-3]: Thing Options
----------------------

  Short 5 of 5, occupying bytes 8-9 of each thing record, control a
few options, according to which bits are set:

bit 0   the THING is present at skill 1 and 2
bit 1   the THING is present at skill 3 (hurt me plenty)
bit 2   the THING is present at skill 4 and 5 (ultra-violence, nightmare)
bit 3   indicates a deaf guard.
bit 4   means the THING only appears in multiplayer mode.

bits 5-15 have no effect.

  The skill settings are most used with the monsters, of course...the
most common skill level settings are hex 07/0f (on all skills), 06/0e
(on skill 3-4-5), and 04/0c (only on skill 4-5). Unusual skill settings
are perfectly allowable, e.g. hex 05 for a thing which is present on
skill 1, 2, 4, and 5, but not skill 3.
  "deaf guard" only has meaning for monsters, who will not attack until
they see a player if they are deaf. Otherwise, they will activate when
they hear gunshots, etc. (including the punch!). Sound does not travel
through solid walls (walls that are solid at the time of the noise).
Also, lines can be set so that sound does not pass through them (see
[4-3-1] bit 6). This option is also known as the "ambush" option (or
flag, or attribute).


[4-3]: LINEDEFS
===============

  Each linedef represents a line from one of the VERTEXES to another,
and each linedef's record is 14 bytes, containing 7 <short> fields:

(1) from the VERTEX with this number (the first vertex is 0).
(2) to the VERTEX with this number (31 is the 32nd vertex).
(3) flags, see [4-3-1] below.
(4) types, see [4-3-2] below.
(5) is a "tag" or "trigger" number which ties this line's effect type
      to all SECTORS that have the same tag number (in their last
      field).
(6) number of the "right" SIDEDEF for this linedef.
(7) "left" SIDEDEF, if this line adjoins 2 SECTORS. Otherwise, it is
      equal to -1 (FFFF hex).

  "right" and "left" are based on the direction of the linedef as
indicated by the "from" and "to", or "start" and "end", VERTEXES.
This sketch should make it clear:

             left side               right side
    start -----------------> end <----------------- start
             right side              left side

  IMPORTANT: All lines must have a right side. If it is a one-sided
line, then it must go the proper direction, so its single side is
facing the sector it is part of. DOOM will crash on a level that has
a line with no right side.


[4-3-1]: Linedef Flags
----------------------

  The third <short> field of each linedef controls some attributes of
that line. These attributes (aka flags) are indicated by bits. If the
bit is set (equal to 1), the condition is true for that line. If the
bit is not set (equal to 0), the condition is not true. Note that the
"unpegged" flags cannot be independently set for the two SIDEDEFs of
a line. Here's a list of the flags, followed by a discussion of each:

bit     Condition

0       Impassible
1       Block Monsters
2       Two-sided
3       Upper Unpegged
4       Lower Unpegged
5       Secret
6       Block Sound
7       Not on Map
8       Already on Map
9-15    unused

  0 (Impassible) - Players and monsters cannot cross this line. Note that
if there is no sector on the other side, they can't go through the line
anyway, regardless of the flags.

  1 (Block Monsters) - Monsters cannot cross this line.

  2 (Two-sided) - The linedef's two sidedefs can have "-" as a texture,
which in this case means "transparent". If this flag is not set, the
sidedefs can't be transparent: if "-" is viewed, it will result in the
"hall of mirrors" effect. However, a linedef CAN have two non-transparent
sidedefs, even if this flag is not set, as long as it is between two
sectors.
  Another side effect of this flag is that if it is set, then gunfire
(pistol, shotgun, chaingun) can go through it. If this flag is not set,
gunfire cannot go through the line. Projectiles (rockets, plasma etc.)
are not restricted this way. They can go through as long as there's a
sector on the other side (and the sector heights allow it).
  Finally, monsters can see through and attack through two-sided lines,
despite any of the line's other flag settings and textures (once again,
provided sector heights and the REJECT [4-10] allow it).

  3 (Upper unpegged) - The upper texture is pasted onto the wall from
the top down instead of from the bottom up like usual.
  Upper textures normally have the bottom of the wall texture to be
drawn lined up with the bottom of the "upper" space in which it is
to be drawn (sidedef Y offsets then apply [4-4]). This can result
in the upper texture being misaligned with a neighboring "middle"
texture. To help solve this problem, common at "windows", this flag
can be set.
  If the upper texture is unpegged, it is drawn with the wall texture's
top row at the ceiling, just like middle and lower textures are usually
drawn. This can help realign the upper texture with a neighbor.

  The article TEXTURES, cited in appendix [A-4] gives a great deal
more explanation on the "unpegged" flags and how to use them.

  4 (Lower unpegged) - Lower and middle textures are drawn from the
bottom up, instead of from the top down like usual.
  This is also commonly used on lower textures under "windows". It is
also used on doorjambs, because when the door opens, the sector ceiling
is rising, so the "sides" (the doorjambs), which are middle textures,
will be drawn from the ever-changing ceiling height down, and thus will
appear to be "moving". Unpegging them will make them be drawn from the
floor up, and since the floor height doesn't change when a door opens,
then will not move.
  There's one slight difference with lower textures being unpegged -
they are not necessarily drawn with the bottom of the wall texture placed
at the bottom of the wall. The height of the facing sector and the height
of the wall texture are taken into account. So if the sector is 160 high,
and the wall texture is 128 high, then lower unpegged will cause the 32nd
row of the wall texture to be at the floor, NOT the 128th row. This of
course excludes sidedef Y offsets, which are applied AFTER unpegged
flags do their stuff.

  5 (Secret) - On the automap, this line appears in red like a normal
solid wall that has nothing on the other side. This is useful in
protecting secret doors and such. Note that if the sector on the other
side of this "secret" line has its floor height HIGHER than the sector
on the facing side of the secret line, then the map will show the lines
beyond and thus give up the secret.
  Also note that this flag has NOTHING to do with the SECRETS ratio on
inter-level screens. That's done with special sector 9 (see [4-9-1]).

  6 (Block Sound) - For purposes of monsters hearing sounds and thus
becoming alerted. Every time a player fires a weapon, the "sound" of
it travels from sector to sector, alerting all non-deaf monsters in
each new sector. But the sound will die when it hits a second line
with this flag. The sound can cross one such line, but not two. All
possible routes for the sound to take are taken, so it can get to
some out-of-the-way places. Another thing that blocks sound, instantly,
is incompatible sector heights. Sound can go from a sector with 0/72
floor/ceiling heights to one with 64/192, but the sound CANNOT go
from a 0/128 sector to an adjacent 128/256 sector.

  7 (Not on Map) - The line is not shown on the automap, even if the
computer all-map power up is acquired.

  8 (Already on Map) - When the level is begun, this line is already
on the automap, even though it hasn't been seen (in the display) yet.
Normally lines only get mapped once part of the line has been seen in
the display window.

  Automap line colors: Red lines indicate the line is one-sided, that
there is a sector on only one side (or the line is marked secret).
Brown lines are between two sectors with different floor heights but
the same ceiling height. Yellow lines are between two sectors with
different ceiling heights and the same or different floor heights.
Gray lines are as-yet-unseen lines revealed by the computer all-map.
Without the all-map, lines between sectors with identical floor and
ceiling heights don't show up. With it, they are gray.


[4-3-2]: Linedef Types
----------------------

  The <short> in field 4 of 7 of a linedef can control various special
effects like doors opening, floors moving, etc. Some of them must be
activated by "using" them, like switches, and some of them are activated
when they are walked over. There are a huge number of ways to use these
effects, but it's all done by using one of a hundred or so line function
types.
  The most common way they work is this: a player walks across a line
or activates (presses the spacebar or the use key) right in front of
a line. That line has a function type that is non-zero. It also has
a tag number. Then ALL sectors on the level with the same tag number,
that are not already engaged in some action, undergo the effects that
the linedef type number dictates. Note that the tag numbers are NOT the
sector numbers, nor the linedef numbers. A tag number is in a lindef's
5th <short> field, and a sector's last <short> field.

Explanations of all the abbreviations in the table:

Val     The value of the linedef "type" field (#4). If you want them
          in numerical order, use SORT or something.
*       This line function only works in 1.666 and up
Class   The category of the effect
Act     Activation. How the linedef's effect is activated.
n       does NOT require a tag number (see note 5 below)
W       walk-over activation
S       switch ("use" - default config is spacebar)
G       gunfire (pistol, shotgun, chaingun) cross or hit line
1       the line may be activated once only
R       potentially repeatable activation
&       affected sectors "locked out" from further changes. See notes 9/10.
m       Monster actions can activate the line's effect
Sound   The type of noise made by moving sectors
Speed   How quickly a floor moves up/down etc.
Tm      Time - how long it "rests"; doors "rest" when they've gone as 
          high as they're going to go, lifts "rest" at the bottom, etc.
Chg     Change - some of them cause a floor texture change and/or special
          sector change. See note 11 below.
T       Trigger model, see note 11 below.
N       Numeric model, see note 11 below.
X       Floor texture is transferred, and Sector type 0.
P       Special Sector types 4, 5, 7, 9, 11, 16 transfer.
Effect  What happens to the affected sector(s).
open    The ceiling goes (up) to LEC-4.
close   The ceiling goes (down) to the floor level.
up      Will move up at specified speed if the destination is above.
          If the destination is below, it arrives there instantly.
down    Will move down at specified speed if the destination is below.
          If the destination is above, it arrives there instantly.
open/   The door can be activated while moving. If it's open or opening,
  close   it closes. If it's closed or closing, it opens, then pauses,
          then closes.
open,   The door can only be activated if it is in the closed state.
  close   It opens, pauses, then closes.
lift    The floor goes down to LIF, rests, then back up to original height.
L       lowest
H       highest
C       ceiling
F       floor
E       adjacent sectors, excluding the affected sector
I       adjacent sectors, including the affected sector
nh      next-higher, i.e. LEF that is higher than source.

  More notes and longer discussions related to these terms:

1.  "Adjacent" is any sector that shares a LINEDEF with the tagged sector
(sectors are adjacent to themselves).
2.  All S activations and the teleporters only work from the RIGHT side
of the linedef.
3.  For teleporters, if more than 1 sector is tagged the same and each
has a teleport landing THING, then the lowest numbered sector is the
destination.
4.  Floors that raise up an absolute height (up 24, 32) will go up INTO
ceilings, so using the WR and SR types of these in levels is unwise.
5.  A few of the linedef types don't require tag numbers: the end-level
switches, the scrolling wall type 48 (0x30), and the "manual" doors which
operate on the sector facing the left side of the linedef with the manual
door line type.
666.  Here's the terms id uses for different types of activations:
        Manual: nSR and nS1 doors
        Trigger: W1
        Retrigger: WR
        Switch: S1
        Button: SR
        Impact: G
        Effect: line 48 is the only one
7.  The "moving floors" go up to a maximum of HIF and go down to a minimum
of LIF. Why they sometimes go up first and sometimes down is still a
mystery to me.
8.  The "crushing ceilings" go from their original ceiling height down
to (floor + 8), then back up. While crushing a creature, their downward
speed slows considerably. "Fast hurt" does about 120% total damage per
crush, and "slow hurt" grabs you and does somewhere around 1000-2000%
total damage per crush.
9.  The & symbol indicates that a sector cannot be affected any more by
other line types after it has performed this effect, even if it has
finished. These are the floor-texture-changers and... (keep reading)
10. Moving floors and crushing ceilings also "lock out" further changes
to the sectors affected, EXCEPT for restarting the moving floor or
crushing ceiling. If a line triggers a type 6 crushing ceiling in a
sector, then it is stopped, then ANY other line with a "crush" type that
is tagged to the same sector will cause the type 6 crusher to start
again, with its original maximum and minimum ceiling heights.
11. Some line types cause floor textures and/or some special sector types
(see [4-9-1]) to transfer to the tagged sector. The tagged sectors' floor
and/or special sector (SS) type will change to match that of the "model"
sector. The TRIGGER model gets the info from the sector that the
activating line's right side faces. The NUMERIC model gets the info
from the sector on the other side of the lowest numbered two-sided
linedef that has one side in the tagged sector.
  All of these "change" line types transfer the floor texture. Also,
they all can pass a special sector trait of "0" or "nothing", i.e. if
the destination is an acid-floor or "damaging" sector, then any of these
lines can erase the damaging effect. Lines 59, 93, 37, 84, and 9 (see
note 12 for more specifics on line type 9) also have the ability to 
transfer the "secret" trait of SS 9, and the damaging traits of SS 
4, 5, 7, 11, and 16. None of the "blinking light" effects of SSs can be
transferred. SS 4 "blinks" and causes damage, but only the damaging part
can be transferred. SS 11 also turns off god-mode and causes a level END
when health <11%, this characteristic is part of SS 11, and cannot be
isolated via fancy transfers.
12. Line type 9 is a special one. The definitive example is the chainsaw
pillar on E1M2. Take the lowest-numbered linedef that has a sidedef in
the tagged sector. If that linedef is one-sided, nothing happens. If it
is 2-sided, then the tagged sector's floor will move down to match the
2nd sector's floor height (or it will jump instantly up if it was below,
like other floors that are supposed to move "down").
  If this 2nd sector CONTAINS the tagged sector, i.e. all the linedefs
with a sidedef in the tagged sector have their other sidedef in the 2nd
sector, then this 2nd sector is the "donut". This donut's floor will
move "up" to match the floor height of the sector on the other side of
the DONUT's lowest-numbered linedef, excluding those linedefs that are
shared with the "donut hole" central sector. Also, the donut will undergo
a floor texture change and special sector type change to match the
"outside". The donut sector does not have to be completely surrounded
by another sector (i.e. it can have 1-sided linedefs), but if its
lowest-numbered linedef is not 2-sided, a minor glitch results: the donut
and the donut-hole both move to a strange height, and the donut changes
floor texture to TLITE6_6 - the last flat in the directory.
  Note that if the donut hole and the donut are both going to move, the
donut hole is going to move to match the height that the donut is "going
to". In other words, the whole thing will be at a single height when
they're done, and this is the height of the "outside" sector that borders
the donut.
  Whew!
13. Line types 30 and 96, "up ShortestLowerTexture" means that affected
sector(s) floors go up a number of units equal to the height of the
shortest "lower" texture facing out from the sector(s).
14. STAIRS. Any sector tagged to a stair-raiser line will go up 8. Now
find the lowest-numbered 2-sided linedef whose RIGHT side faces this
sector (the first step). The sector on the other side of the lindedef
becomes the next step, and its floor height changes to be 8 above the
previous step (it raises up if it was lower, or it changes instantly if
it was higher). This process continues as long as there are 2-sided
lines with right sides facing each successive step. A couple things
will stop the stairway:
    (a) no 2-sided linedef whose right side faces the current step
    (b) a sector with a different floor texture
    (c) a sector that has already been moved by this stairway (this stops
          ouroboros stairways that circle around to repeat themselves)
    (d) "locked-out" sectors that can't change their floor height anymore
  The component steps of a stairway can have any shape or size.
  The turbo stairs (100, 127) work just like regular stairs except that
each step goes up 16 not 8, and rising steps can crush things between
themselves and the ceiling.
15. Line types 78 and 85 do NOTHING as of version 1.666.



Val   Class Act  Sound Speed Tm Chg Effect

SPECIAL (Continuous effect, doesn't need triggereing)

 48   Spec  n--  -     -     -  -   Scrolling wall

LOCAL DOORS ("MANUAL" DOORS)

  1   mDoor nSRm door  med   4  -   open/close
 26   mDoor nSR  door  med   4  -   open/close BLUE KEY
 28   mDoor nSR  door  med   4  -   open/close RED KEY
 27   mDoor nSR  door  med   4  -   open/close YELLOW KEY
 31   mDoor nS1  door  med   -  -   open
 32   mDoor nS1  door  med   -  -   open BLUE KEY
 33   mDoor nS1  door  med   -  -   open RED KEY
 34   mDoor nS1  door  med   -  -   open YELLOW KEY
 46   mDoor nGR  door  med   -  -   open
117 * mDoor nSR  blaze turbo 4  -   open/close
118 * mDoor nS1  blaze turbo -  -   open

REMOTE DOORS

  4   rDoor  W1  door  med   4  -   open,close
 29   rDoor  S1  door  med   4  -   open,close
 90   rDoor  WR  door  med   4  -   open,close
 63   rDoor  SR  door  med   4  -   open,close
  2   rDoor  W1  door  med   -  -   open
103   rDoor  S1  door  med   -  -   open
 86   rDoor  WR  door  med   -  -   open
 61   rDoor  SR  door  med   -  -   open
  3   rDoor  W1  door  med   -  -   close
 50   rDoor  S1  door  med   -  -   close
 75   rDoor  WR  door  med   -  -   close
 42   rDoor  SR  door  med   -  -   close
 16   rDoor  W1  door  med   30 -   close, then opens
 76   rDoor  WR  door  med   30 -   close, then opens
108 * rDoor  W1  blaze turbo 4  -   open,close
111 * rDoor  WR  blaze turbo 4  -   open,close
105 * rDoor  S1  blaze turbo 4  -   open,close
114 * rDoor  SR  blaze turbo 4  -   open,close
109 * rDoor  W1  blaze turbo -  -   open
112 * rDoor  S1  blaze turbo -  -   open
106 * rDoor  WR  blaze turbo -  -   open
115 * rDoor  SR  blaze turbo -  -   open
110 * rDoor  W1  blaze turbo -  -   close
113 * rDoor  S1  blaze turbo -  -   close
107 * rDoor  WR  blaze turbo -  -   close
116 * rDoor  SR  blaze turbo -  -   close
133 * rDoor  S1  blaze turbo -  -   open BLUE KEY
 99 * rDoor  SR  blaze turbo -  -   open BLUE KEY
135 * rDoor  S1  blaze turbo -  -   open RED KEY
134 * rDoor  SR  blaze turbo -  -   open RED KEY
137 * rDoor  S1  blaze turbo -  -   open YELLOW KEY
136 * rDoor  SR  blaze turbo -  -   open YELLOW KEY

CEILINGS

 40   Ceil   W1  mover slow  -  -   up to HEC
 41   Ceil   S1  mover slow  -  -   down to floor
 43   Ceil   SR  mover slow  -  -   down to floor
 44   Ceil   W1  mover slow  -  -   down to floor + 8
 49   Ceil   S1  mover slow  -  -   down to floor + 8
 72   Ceil   WR  mover slow  -  -   down to floor + 8

LIFTS

 10   Lift   W1  lift  fast  3  -   lift
 21   Lift   S1  lift  fast  3  -   lift
 88   Lift   WRm lift  fast  3  -   lift
 62   Lift   SR  lift  fast  3  -   lift
121 * Lift   W1  lift  turbo 3  -   lift
122 * Lift   S1  lift  turbo 3  -   lift
120 * Lift   WR  lift  turbo 3  -   lift
123 * Lift   SR  lift  turbo 3  -   lift

FLOORS

119 * Floor  W1  mover slow  -  -   up to nhEF
128 * Floor  WR  mover slow  -  -   up to nhEF
 18   Floor  S1  mover slow  -  -   up to nhEF
 69   Floor  SR  mover slow  -  -   up to nhEF
 22   Floor  W1& mover slow  -  TX  up to nhEF
 95   Floor  WR& mover slow  -  TX  up to nhEF
 20   Floor  S1& mover slow  -  TX  up to nhEF
 68   Floor  SR& mover slow  -  TX  up to nhEF
 47   Floor  G1& mover slow  -  TX  up to nhEF
  5   Floor  W1  mover slow  -  -   up to LIC
 91   Floor  WR  mover slow  -  -   up to LIC
101   Floor  S1  mover slow  -  -   up to LIC
 64   Floor  SR  mover slow  -  -   up to LIC
 24   Floor  G1  mover slow  -  -   up to LIC
130 * Floor  W1  mover turbo -  -   up to nhEF
131 * Floor  S1  mover turbo -  -   up to nhEF
129 * Floor  WR  mover turbo -  -   up to nhEF
132 * Floor  SR  mover turbo -  -   up to nhEF
 56   Floor  W1& mover slow  -  -   up to LIC - 8, CRUSH
 94   Floor  WR& mover slow  -  -   up to LIC - 8, CRUSH
 55   Floor  S1  mover slow  -  -   up to LIC - 8, CRUSH
 65   Floor  SR  mover slow  -  -   up to LIC - 8, CRUSH
 58   Floor  W1  mover slow  -  -   up 24
 92   Floor  WR  mover slow  -  -   up 24
 15   Floor  S1& mover slow  -  TX  up 24
 66   Floor  SR& mover slow  -  TX  up 24
 59   Floor  W1& mover slow  -  TXP up 24
 93   Floor  WR& mover slow  -  TXP up 24
 14   Floor  S1& mover slow  -  TX  up 32
 67   Floor  SR& mover slow  -  TX  up 32
140 * Floor  S1  mover med   -  -   up 512
 30   Floor  W1  mover slow  -  -   up ShortestLowerTexture
 96   Floor  WR  mover slow  -  -   up ShortestLowerTexture
 38   Floor  W1  mover slow  -  -   down to LEF
 23   Floor  S1  mover slow  -  -   down to LEF
 82   Floor  WR  mover slow  -  -   down to LEF
 60   Floor  SR  mover slow  -  -   down to LEF
 37   Floor  W1  mover slow  -  NXP down to LEF
 84   Floor  WR  mover slow  -  NXP down to LEF
 19   Floor  W1  mover slow  -  -   down to HEF
102   Floor  S1  mover slow  -  -   down to HEF
 83   Floor  WR  mover slow  -  -   down to HEF
 45   Floor  SR  mover slow  -  -   down to HEF
 36   Floor  W1  mover fast  -  -   down to HEF + 8
 71   Floor  S1  mover fast  -  -   down to HEF + 8
 98   Floor  WR  mover fast  -  -   down to HEF + 8
 70   Floor  SR  mover fast  -  -   down to HEF + 8
  9   Floor  S1  mover slow  -  NXP donut (see note 12 above)

STAIRS

  8   Stair  W1  mover slow  -  -   stairs
  7   Stair  S1  mover slow  -  -   stairs
100 * Stair  W1  mover turbo -  -   stairs (each up 16 not 8) + crush
127 * Stair  S1  mover turbo -  -   stairs (each up 16 not 8) + crush

MOVING FLOORS

 53   MvFlr  W1& lift  slow  3  -   start moving floor
 54   MvFlr  W1& -     -     -  -   stop moving floor
 87   MvFlr  WR& lift  slow  3  -   start moving floor
 89   MvFlr  WR& -     -     -  -   stop moving floor

CRUSHING CEILINGS

  6   Crush  W1& crush med   0  -   start crushing, fast hurt
 25   Crush  W1& crush med   0  -   start crushing, slow hurt
 73   Crush  WR& crush slow  0  -   start crushing, slow hurt
 77   Crush  WR& crush med   0  -   start crushing, fast hurt
 57   Crush  W1& -     -     -  -   stop crush
 74   Crush  WR& -     -     -  -   stop crush
141 * Crush  W1& none? slow  0  -   start crushing, slow hurt "Silent"

EXIT LEVEL

 11   Exit  nS-  clunk -     -  -   End level, go to next level
 51   Exit  nS-  clunk -     -  -   End level, go to secret level
 52   Exit  nW-  clunk -     -  -   End level, go to next level
124 * Exit  nW-  clunk -     -  -   End level, go to secret level

TELEPORT
 
 39   Telpt  W1m tport -     -  -   Teleport
 97   Telpt  WRm tport -     -  -   Teleport
125 * Telpt  W1m tport -     -  -   Teleport monsters only
126 * Telpt  WRm tport -     -  -   Teleport monsters only

LIGHT

 35   Light  W1  -     -     -  -   0
104   Light  W1  -     -     -  -   LE (light level)
 12   Light  W1  -     -     -  -   HE (light level)
 13   Light  W1  -     -     -  -   255
 79   Light  WR  -     -     -  -   0
 80   Light  WR  -     -     -  -   HE (light level)
 81   Light  WR  -     -     -  -   255
 17   Light  W1  -     -     -  -   Light blinks (see [4-9-1] type 3)
138 * Light  SR  clunk -     -  -   255
139 * Light  SR  clunk -     -  -   0


[4-4]: SIDEDEFS
===============

  A sidedef is a definition of what wall texture(s) to draw along a
LINEDEF, and a group of sidedefs outline the space of a SECTOR.
  There will be one sidedef for a line that borders only one sector
(and it must be the RIGHT side, as noted in [4-3]). It is not 
necessary to define what the doom player would see from the other 
side of that line because the doom player can't go there. The doom
player can only go where there is a sector.
  Each sidedef's record is 30 bytes, comprising 2 <short> fields, then
3 <8-byte string> fields, then a final <short> field:

(1) X offset for pasting the appropriate wall texture onto the wall's
        "space": positive offset moves into the texture, so the left
        portion gets cut off (# of columns off left side = offset).
        Negative offset moves texture farther right, in the wall's space.
(2) Y offset: analogous to the X, for vertical.
(3) "upper" texture name: the part above the juncture with a lower
        ceiling of an adjacent sector.
(4) "lower" texture name: the part below a juncture with a higher
        floored adjacent sector.
(5) "middle" texture name: the regular part of the wall. Also known as
        "normal" or "full" texture.
(6) SECTOR that this sidedef faces or helps to surround.

  The texture names are from the TEXTURE1/2 resources. The names of
wall patches in the directory (between P_START and P_END) are not
directly used, they are referenced through the PNAMES lump.
  Simple sidedefs have no upper or lower texture, and so they will have
"-" instead of a texture name. Also, two-sided lines can be transparent,
in which case "-" means transparent (no texture).
  If the wall is wider than the texture to be pasted onto it, then the
texture is tiled horizontally. A 64-wide texture will be pasted at 0,
64, 128, etc., unless an X-offset changes this.
  If the wall is taller than the texture, than the texture is tiled
vertically, with one very important difference: it starts new tiles
ONLY at 128, 256, 384, etc. So if the texture is less than 128 high,
there will be junk filling the undefined areas, and it looks ugly.
This is sometimes called the "Tutti Frutti" effect.

  There are some transparent textures which can be used as middle textures
on 2-sided sidedefs (between sectors). These textures need to be composed
of a single patch (see [8-4]), and note that on a very tall wall, they
will NOT be tiled. Only one will be placed, at the spot determined by
the "lower unpegged" flag being on/off and the sidedef's y offset. And
if a transparent texture is used as an upper or lower texture, then
the good old "Tutti Frutti" effect will have its way.
  Also note that animated wall textures (see [8-4-1]) do NOT animate
if they are the "middle" texture on a 2-sided line. So much for the
lava waterfall with the hidden room at its base...hmm, maybe not...


[4-5]: VERTEXES
===============

  These are the beginning and end points for LINEDEFS and SEGS. Each
vertice's record is 4 bytes in 2 <short> fields:

(1) X coordinate
(2) Y coordinate

  On the automap within the game, with the grid on (press 'G'), the
lines are 128 apart (0x80), two lines = 256 (0x100).
  A note on the coordinates: the coordinate system used for the vertices
and the heights of the sectors corresponds to pixels, for purposes of
texture-mapping. So a sector that's 128 high, or a multiple of 128, is
pretty typical, since many wall textures are 128 pixels high.
  And yes, the correct spelling of the plural of "vertex" is "vertices".


[4-6]: SEGS
===========

  The SEGS are stored in a sequential order determined by the SSECTORS,
which are part of the NODES recursive tree.
  Each seg is 12 bytes in 6 <short> fields:

(1) start of seg is VERTEX with this number
(2) end VERTEX
(3) angle: 0= east, 16384=north, -16384=south, -32768=west.
      In hex, it's 0000=east, 4000=north, 8000=west, c000=south.
      This is also know as BAMS for Binary Angle Measurement.
(4) LINEDEF that this seg goes along
(5) direction: 0 if the seg goes the same direction as the linedef it
      is on, 1 if the seg goes the opposite direction. This is the
      same as (0 if the seg is on the RIGHT side of the linedef) or
      (1 if the seg is on the LEFT side of the linedef).
(6) offset: distance along the linedef to the start of this seg (the
      vertex in field 1). The offset is in the same direction as the
      seg. If field 5 is 0, then the distance is from the "start"
      vertex of the linedef to the "start" vertex of the seg. If field
      5 is 1, then the offset is from the "end" vertex of the linedef
      to the "start" vertex of the seg. So if the seg begins at one of
      the two endpoints of the linedef, this offset will be 0.

  For diagonal segs, the offset distance can be obtained from the
formula DISTANCE = SQR((x2 - x1)^2 + (y2 - y1)^2). The angle can be
calculated from the inverse tangent of the dx and dy in the vertices,
multiplied to convert PI/2 radians (90 degrees) to 16384. And since
most arctan functions return a value between -(pi/2) and (pi/2),
you'll have to do some tweaking based on the sign of (x2-x1), to
account for segs that go "west".


[4-7]: SSECTORS
===============

  SSECTOR stands for sub-sector. These divide up all the SECTORS into
convex polygons. They are then referenced through the NODES resources.
There will be (number of nodes + 1) ssectors.
  Each ssector is 4 bytes in 2 <short> fields:

(1) This many SEGS are in this SSECTOR...
(2) ...starting with this SEG number

  The segs in ssector 0 should be segs 0 through x, then ssector 1
contains segs x+1 through y, ssector 2 containg segs y+1 to z, etc.


[4-8]: NODES
============

  A detailed explanation of the nodes follows this list of a node's
structure in the wad file.
  Each node is 28 bytes in 14 <short> fields:

(1)  X coordinate of partition line's start
(2)  Y coordinate of partition line's start
(3)  DX, change in X to end of partition line
(4)  DY, change in Y to end of partition line

  If (1) to (4) equaled 64, 128, -64, -64, the partition line would
go from (64,128) to (0,64).

(5)  Y upper bound for right bounding-box.\
(6)  Y lower bound                         All SEGS in right child of node
(7)  X lower bound                         must be within this box.
(8)  X upper bound                        /
(9)  Y upper bound for left bounding box. \
(10) Y lower bound                         All SEGS in left child of node
(11) X lower bound                         must be within this box.
(12) X upper bound                        /
(13) a NODE or SSECTOR number for the right child. If bit 15 of this
       <short> is set, then the rest of the number represents the
       child SSECTOR. If not, the child is a recursed node.
(14) a NODE or SSECTOR number for the left child.

  The NODES lump is by far the most difficult to understand of all the
data structures in DOOM. A new level won't display right without a valid
set of precalculated nodes, ssectors, and segs.
  Here I will explain what the nodes are for, and how they can be
generated automatically from the set of linedefs, sidedefs, and
vertices. I am NOT including any code or a pseudo-code algorithm, like
I do for the BLOCKMAP (appendix [A-3]). This is for reasons of space,
and more importantly, the fact that I haven't written any such
algorithm myself. If there's to be some "node code" published here, it
will have to be donated by someone, well-commented, well-organized, in
pseudo-code, and 100% effective! So the odds are long against it.

  The NODES are branches in a binary space partition (BSP) that divides
up the level and is used to determine which walls are in front of others,
a process know as hidden-surface removal. The SSECTORS (sub-sectors) and
SEGS (segments) lumps are necessary parts of the structure.
  A BSP tree is normally used in 3d space, but DOOM uses a simplified
2d version of the scheme. Basically, the idea is to keep dividing the
map into smaller spaces until each of the smallest spaces contains only
wall segments which cannot possibly occlude (block from view) other
walls in its own space. The smallest, undivided spaces will become
SSECTORS. Each wall segment is part or all of a linedef (and thus a
straight line), and becomes a SEG. All of the divisions are kept track
of in a binary tree structure, which is used to greatly speed the
rendering process (drawing what is seen). How does this binary tree
lead to faster rendering? I have no idea.
  Only the SECTORS need to be divided. The parts of the levels that are
"outside" sectors are ignored. Also, only the walls need to be kept
track of. The sides of any created ssectors which are not parts of
linedefs do not become segs.
  Some sectors do not require any dividing. Consider a square sector.
All the walls are orthogonal to the floor (the walls are all straight
up and down), so from any viewpoint inside the square, none of its
four walls can possibly block the view of any of the others. Now
imagine a sector shaped like this drawing:

+--------------.------+   The * is the viewpoint, looking ->, east. The
|               .     |   diagonal wall marked @ @ can't be seen at all,
|               /\    |@  and the vertical wall marked @@@ is partially
|  *->        /   @\  |@  occluded by the other diagonal wall. This sector
|           /       @\|@  needs to be divided. Suppose the diagonal wall
+---------/               is extended, as shown by the two dots (..):

now each of the two resulting sub-sectors are sufficient, because while
in either one, no wall that is part of that sub-sector blocks any other.
  In general, being a convex polygon is the goal of a ssector. Convex
means a line connecting any two points that are inside the polygon will
be completely contained in the polygon. All triangles and rectangles are
convex, but not all quadrilaterals. In doom's simple Euclidean space,
convex also means that all the interior angles of the polygon are less
than or equal to 180 degrees.
  Now, an additional complication arises because of the two-sided
linedef. Its two sides are in different sectors, so they will end up
in different ssectors too. Thus every two-sided linedef becomes two segs
(or more), or you could say that every sidedef becomes a seg. Creating
segs from sidedefs is a good idea, because the seg can then be associated
with a sector. Two segs that aren't part of the same sector cannot
possibly be in the same ssector, so further division is required of any
set of segs that aren't all from the same sector.
  Whenever a division needs to be made, a SEG is picked, somewhat
arbitrarily, which along with its imaginary extensions, forms a "knife"
that divides the remaining space in two (thus binary). This seg is the
partition line of a node, and the remaining spaces on either side of
the partition line become the right and left CHILDREN of the node. All
partition lines have a direction, and the space on the "right" side of
the partition is the right child of the node; the space on the "left"
is the left child (there's a cute sketch in [4-3]: LINEDEFS that shows
how right and left relate to the start and end of a line). Note that if
there does not exist a seg in the remaining space which can serve as a
partition line, then there is no need for a further partition, i.e.
it's a ssector and a "leaf" on the node tree.
  If the "knife" passes through any lines/segs (but not at vertices),
they are split at the intersection, with one part going to each child.
A two-sided linedef, which is two segs, when split results in four segs.
A two sider that lies along an extension of the partition line has each
of its two segs go to opposite sides of the partition line. This is the
eventual fate of ALL segs on two-sided linedefs.
  As the partition lines are picked and the nodes created, a strict
ordering must be maintained. The node tree is created from the "top"
down. After the first division is made, then the left child is divided,
then its left child, and so on, until a node's child is a ssector. The
n you move back up the tree one branch, and divide the right child, then
its left, etc. ALWAYS left first, on the way down.
  Since there will be splits along the way, there is no way to know
ahead of time how many nodes and ssectors there will be at the end.
And the top of the tree, the node that is created first, is given the
highest number. So as nodes and ssectors are created, they are simply
numbered in order from 0 on up, and when it's all done (nothing's left
but ssectors), then ALL the numbers, for nodes and ssectors, are
reversed. If there's 485 nodes, then 485 becomes 0 and 0 becomes 485.
  Here is another fabulous drawing which will explain everything.
+ is a vertex, - and | indicate linedefs, the . . indicates an
extension of a partition line. The <, >, and ^ symbols indicate the
directions of partition lines. All the space within the drawing is
actual level space, i.e. sectors.

      +-----+-------+-------+            0                     (5)
      |     |       |       |         /     \      ==>       /     \
      |  e  |^  f   |^  g   |       1         4           (4)       (1)
      |     |4      |5      |     /   \      / \         /   \      / \
+---- + . . +-------+-------+    2     3    e   5      (3)   (2)   2  (0)
|     |           < 0       |   / \   / \      / \     / \   / \      / \
|  a  |       b             |  a   b c   d    f   g   6   5 4   3    1   0
|     |^                    |
| . . |2. . . . . +---------+ The order in which      How the elements are
|     |           |1 >        the node tree's         numbered when it's
|  c  |^    d     |           elements get made.      finished.
|     |3          |           0 = node                (5) = node
+-----+-----------+           a = ssector             6 = ssector

  1. Make segs from all the linedefs. There are 5 two-sided lines here.
  2. Pick the vertex at 0 and go west (left). This is the first 
       partition line. Note the . . extension line.
  3. Pick the vertex at 1, going east. The backwards extension . . cuts
       the line 3>2>, and the unlabeled left edge line. The left edge
       was one seg, it becomes two. The 3>2> line was two segs, it
       becomes four. New vertices are created at the intersection
       points to do this.
  4. Pick the (newly created) vertex at 2. Now the REMAINING spaces on
       both sides of the partition line are suitable for ssectors. The
       left one is first, it becomes a, the right b. Note that ssector
       a has 3 segs, and ssector b has 5 segs. The . . imaginary lines
       are NOT segs.
  5. Back up the tree, and take 1's right branch. Pick 3. Once again, we
       can make 2 ssectors, c and d, 3 segs each. Back up the tree to 0.
  6. Pick 4. Now the left side is a ssector, it becomes e. But the right
       side is not, it needs one more node. Pick 5, make f and g.
  7. All done, so reverse all the ordination of the nodes and the
       ssectors. Ssector 0's segs become segs 0-2, ssector 1's segs
       become segs 3-7, etc. The segs are written sequentially according
       to the ssector numbering.

  If we want to create an algorithm to do the nodes automatically, it
needs to be able to pick partition lines automatically. From studying
the original maps, it appears that they usually chose a linedef which
divides the child's space roughly in "half". This is restricted by the
availability of a seg in a good location, with a good angle. Also, the
"half" refers to the total number of ssectors in any particular child,
which we have no way of knowing when we start! Optimization methods are
probably used, or maybe brute force, trying every candidate seg until
the "best" one is found.
  What is the best possible choice for a partition line? Well, there
are apparently two goals when creating a BSP tree, which are partially
exclusive. One is to have a balanced tree, i.e. for any node, there are
about the same total number of sub-nodes on either side of it. The other
goal is to minimize the number of "splits" necessary, in this case, the
number of seg splits needed, along with the accompanying new vertices
and extra segs. Only a very primitive and specially constructed set of
linedefs could avoid having any splits, so they are inevitable. It's
just that with some choices of partition lines, there end up being
fewer splits. For example,

+--------------+       If a and b are chosen as partition lines,
|              |       there will be four extra vertices needed,
+---+      +---+ < A   and this shape becomes five ssectors and
    |^    ^|           16 segs. If A and B are chosen, however,
+---+a    b+---+ < B   there are no extra vertices, and only three
|              |       ssectors and 12 segs.
+--------------+       

  I've read that for a "small" number of polygons (less than 1000?),
which is what we're dealing with in a doom level, one should definitely
try to minimize splits, and not worry about balancing the tree. I can't
say for sure, but it does appear that the original levels strive for
this. Their trees are not totally unbalanced, but there are some parts
where many successive nodes each have a node and a ssector as children
(this is unbalanced). And there are a lot of examples to prove that the
number of extra segs and vertices they create is very low compared to
what it could be. I think the algorithm that id Software used tried to
optimize both, but with fewer splits being more important.


[4-9]: SECTORS
==============

  A SECTOR is a horizontal (east-west and north-south) area of the map
where a floor height and ceiling height is defined. It can have any
shape. Any change in floor or ceiling height or texture requires a
new sector (and therefore separating linedefs and sidedefs). If you
didn't already know, this is where you find out that DOOM is in many
respects still a two-dimensional world, because there can only be ONE
floor height in each sector. No buildings with two floors, one above
the other, although fairly convincing illusions are possible.
  Each sector's record is 26 bytes, comprising 2 <short> fields, then
2 <8-byte string> fields, then 3 <short> fields:

(1) Floor is at this height for this sector
(2) Ceiling height
(3) name of the flat used for the floor texture, from the directory.
(4) name of the flat used for the ceiling texture.
      All the flats in the directory between F_START and F_END work
      as either floors or ceilings. 
(5) lightlevel of this sector: 0 = total dark, 255 (0xff) = maximum 
      light. There are actually only 32 brightnesses possible (see 
      COLORMAP [8-2]), so 0-7 are the same, ..., 248-255 are the same.
(6) special sector: see [4-9-1] immediately below.
(7) a "tag" number corresponding to LINEDEF(s) with the same tag
      number. When that linedef is activated, something will usually
      happen to this sector - its floor will rise, the lights will
      go out, etc. See [4-3-2] for the list of linedef effects.


[4-9-1]: Special Sector Types
-----------------------------

  Bytes 22-23 of each Sector record are a <short> which determines
some area-effects called special sectors.
  Light changes are automatic. The brightness level will alternate
between the light value specified for the special sector, and the lowest
value amongst adjacent sectors (two sectors are adjacent if a linedef
has a sidedef facing each sector). If there is no lower light value,
or no adjacent sectors, then the "blink" sectors will instead alternate
between 0 light and their own specified light level. The "oscillate"
special (8) does nothing if there is no lower light level.
  "blink off" means the light is at the specified level most of the time,
and changes to the lower value for just a moment. "blink on" means the
light is usually at the lower value, and changes to the sector's value
for just a moment. Every "synchronized" blinking sector on the level
will change at the same time, whereas the unsynchonized blinking sectors
change independently. "oscillate" means the light level goes smoothly
from the lower to the higher and back; it takes about 2 seconds to go
from maximum to minimum and back (255 down to 0 back up to 255).
  The damaging sector types only affect players, monsters suffer no ill
effects from them whatsoever. Players will only take damage when they
are standing on the floor of the damaging sector. "-10/20%" means that
the player takes 20% damage at the end of every second that they are in
the sector, except at skill 1, they will take 10% damage. If the player
has armor, then the damage is split between health and armor.

Dec Hex Class   Condition or effect

 0  00  -       Normal, no special characteristic.
 1  01  Light   random off
 2  02  Light   blink 0.5 second
 3  03  Light   blink 1.0 second
 4  04  Both    -10/20% health AND light blink 0.5 second
 5  05  Damage  -5/10% health
 7  07  Damage  -2/5% health
 8  08  Light   oscillates
 9  09  Secret  a player must stand in this sector to get credit for
                  finding this secret. This is for the SECRETS ratio
                  on inter-level screens.
10  0a  Door    30 seconds after level start, ceiling closes like a door.
11  0b  End     -10/20% health. If a player's health is lowered to less
                  than 11% while standing here, then the level ends! Play
                  proceeds to the next level. If it is a final level
                  (levels 8 in DOOM 1, level 30 in DOOM 2), the game ends!
12  0c  Light   blink 0.5 second, synchronized
13  0d  Light   blink 1.0 second, synchronized
14  0e  Door    300 seconds after level start, ceiling opens like a door.
16  10  Damage  -10/20% health

  The following value can only be used in versions 1.666 and up, it will
cause an error and exit to DOS in version 1.2 and earlier:

17  11  Light   flickers on and off randomly

  All other values cause an error and exit to DOS. This includes these
two values which were developed and are quoted by id as being available,
but are not actually implemented in DOOM.EXE (as of version 1.666):

 6  06  -       crushing ceiling
15  0f  -       ammo creator

  What a shame! The "ammo creator" sounds especially interesting!


[4-10]: REJECT
==============

  The REJECT lump is used to help speed play on large levels. It can
also be used for some special effects like monsters in plain sight who
CANNOT attack or see players.
  The size of a REJECT in bytes is (number of SECTORS ^ 2) / 8, rounded
up. It is an array of bits, with each bit controlling whether monsters
in a given sector can detect and/or attack players in another sector.
  Make a table of sectors vs. sectors, like this:

         sector that the player is in
              0  1  2  3  4
            +---------------
sector    0 | 0  1  0  0  0
that      1 | 1  0  1  1  0
the       2 | 0  1  0  1  0
monster   3 | 0  1  1  1  0
is in     4 | 0  0  1  0  0

  A 1 means the monster cannot become activated by seeing a player, nor
can it attack the player. A 0 means there is no restriction. All non-
deaf monsters still become activated by weapon sounds that they hear
(including the bare fist!). And activated monsters will still pursue
the player, but they will not attack if their current sector vs. sector
bit is "1". So a REJECT that's set to all 1s gives a bunch of pacifist
monsters who will follow the player around and look menacing, but never
actually attack.
  How the table turns into the REJECT resource:
  Reading left-to-right, then top-to-bottom, like a page, the first bit
in the table becomes bit 0 of byte 0, the 2nd bit is bit 1 of byte 0,
the 9th bit is bit 0 of byte 1, etc. So if the above table represented
a level with only 5 sectors, its REJECT would be 4 bytes:

10100010 00101001 01000111 xxxxxxx0 (hex A2 29 47 00, decimal 162 41 71 0)

  In other words, the REJECT is a long string of bits which are read
from least significant bit to most significant bit, according to the
lo-hi storage scheme used in a certain "x86" family of CPUs.
  Usually, if a monster in sector A can't detect a player in sector B,
then the reverse is true too, thus if sector8/sector5 is set, then
sector5/sector8 will be set also. Same sector prohibitions, e.g. 0/0,
3/3, etc. are only useful for special effects (pacifist monsters), or
for tiny sectors that monsters can't get to anyway.

  The REJECT array was designed to speed the monster-detection process.
If a sector pair is prohibited, the game engine doesn't even bother
checking line-of-sight feasibility for the monster to "see" the player
and consider attacking. When a level has hundreds of monsters and
hundreds of sectors, a good REJECT can prevent the drastic slowdowns
that might otherwise occur (even fast CPUs can fall victim to this
phenomenon).


[4-11]: BLOCKMAP
================

  The BLOCKMAP is a pre-calculated structure that the game engine uses
to simplify collision-detection between moving things and walls. If a
level doesn't have a blockmap, it will display fine, but everybody walks
through walls, and no one can hurt anyone else.
  A concise definition of the BLOCKMAP is in appendix [A-1]. This is
the full explanation of it.
  The whole level is cut into "blocks", each is a 128 (hex 80) wide
square (the grid lines in the automap correspond to these blocks). The
BLOCKMAP is a collection of lists, one list for each block, which say
what LINEDEFS are wholly or partially in that block (i.e. part of the
line passes through the block). When the game engine needs to check
for an object/wall collision (to prevent a player from walking through
a wall or to explode a rocket when it hits a wall, etc.), it just looks
up the blocklist for the block that the object is in. This tells it
which linedefs it needs to check for collisions. Most blocks will have
few if any lines in them, so there will be a substantial savings in
processor time if it only checks a couple linedefs per object instead
of a thousand or so linedefs per object - it would have to check every
single linedef on the level if not for these blocklists.
  The blocks are also used for object/object collisions, but that is
not visible in the WAD format. During play, each block is also given a
dynamic "thing list", which tells what THINGS are currently in that
block. Again, this negates the need to check every moving object vs.
every other object for collisions - only a few need be tested.
  The BLOCKMAP is composed of three parts: the header, the offsets, and
the blocklists.
  The 8-byte header contains 4 short integers:

(1)     X coordinate of block-grid origin
(2)     Y coordinate of block-grid origin
(3)     # of columns (blocks in X direction)
(4)     # of rows (blocks in Y direction)

  The block-grid origin is the bottom-left corner of the bottom-left
(southwest) block. id's blockmap builder this origin point at 8 less
than the minimum values of x and y achieved in any vertex on the level.
  The number of columns and rows needs to be sufficient to contain
every linedef in the level. If there are linedefs outside the blockmap,
it will not be able to prevent monsters or players from crossing those
linedefs, which can cause problems, including the hall of mirrors effect.

  There are N blocks, N = (number of columns * number of rows). Each
block has a blocklist and an offset to that blocklist. Immediately
following the 8-byte header are N unsigned short integers. The first
is the offset in short-ints NOT bytes, from the start of the BLOCKMAP
lump to the start of the first blocklist. The last offset points to
blocklist (N-1), the last blocklist. Note that all these offsets are
UNSIGNED, so they can point to a location 65535 shorts (131070 bytes)
into the BLOCKMAP. If they were signed, they could only go up to 32767.
  The blocks are numbered going east (right) first, then north (up).
Block 0 is at the southwest corner (row 0, column 0). Block 1 is at
row 0, column 1. If there are 37 columns, then block 38 is at row 1,
column 0, etc.

  After the offsets come the blocklists. Each blocklist starts with
a short-int 0 (0x0000) and ends with a short-int -1 (0xffff). In between
are the numbers of every linedef which has any portion whatsoever in the
128 x 128 coordinate area of that block. If the block-grid origin is at
(0,0), then the first column is X = 0 to 127 inclusive, the second column
is X = 128 to 255 inclusive, etc. So a vertical line with X = 128 which
might seem to be on the border of two columns of blocks is actually only
in the easternmost/rightmost column. Likewise for the rows.
  The first linedef in the LINEDEFS lump is linedef number 0, and so on.
An "empty" block's blocklist only has the two shorts 0 and -1. A non-
empty block might have this as its blocklist: 0 330 331 333 -1. This
means that linedefs 330, 331, and 333 have some part of them pass through
this block. A block that has linedef 0 in it will go: 0 0 .. etc .. -1.

  There is an upper limit to how big a BLOCKMAP can be. Even empty
blocklists require at least 3 shorts - the 0, the -1, and the offset to
the blocklist. The offsets are unsigned shorts, which would imply a
maximum value of short #65535 ( = byte 131070) for the start of the last
blocklist. At a little over 6 bytes per blocklist, that would be a maximum
of around 21000 blocks (145 by 145 blocks, 18560 in coordinates). But the
actual limit is less. Experiments suggest that the maximum total size of
all the blocklists, not counting the offsets, is 65535 bytes. This limits
a minimalist level to around 120 blocks square (15360 in coordinates),
or a realistically complex level to around 100 blocks square (12800 in
coordinates).


---------------------
CHAPTER [5]: Graphics
---------------------

  The great majority of the entries in the directory reference lumps
that are in a special picture format. The same format is used for the
sprites (monsters, items), the wall patches, and various miscellaneous
pictures for the status bar, menu text, inter-level map, etc. Every
one of these picture lumps contains exactly one picture. The flats
(floor and ceiling pictures) are NOT in this format, they are raw data;
see chapter [6].
  A great many of these lumps are used in sprites. A "sprite" is the
picture or pictures necessary to display any of the THINGS. Some of
them are simple, a single lump like SUITA0. Most of the monsters have
50 or more lumps.
  The first four letters of these lumps are the sprite's "name". TROO
is for imps, BKEY is for the blue key, and so on. See [4-2-1] for a list
of them all. The fifth letter in the lump is an indication of what "frame"
it is, for animation sequences. The letters correspond to numbers, ASCII
"A" equalling 0, "B" is 1, ... "Z" is 25, etc. The highest needed by a
DOOM 1 sprite is W=22, but some of the DOOM 2 monsters need a few more
frames.
  The "0" in the lump name is for "rotations" or "rot"s. All the
static objects like torches and barrels and dead bodies look the same
from any angle. This is because they have a "rot=0 lump" as DOOM itself
might say. Monsters and projectiles look different from different
angles. This is done with rots 1-8. This diagram shows how rot 1 is for
the front and they go counter-clockwise (looking from above) to 8:

        3
      4 | 2
       \|/
     5--*----> 1   Thing is facing this direction
       /|\
      6 | 8
        7

  Many things have sets of lumps like this: TROOA1, TROOA2A8, TROOA3A7,
TROOA4A6, TROOA5, TROOB1, etc. This means that for frame 0 (A), the
pairs of rots/angles (2 and 8), (3 and 7), and (4 and 6) are mirror-
images. In the long run, this saves space in the wad file, and from the
designer's point of view, it's 37% fewer pictures to have to draw.
  If a sprite's frame has a non-zero rot, it needs to have ALL 8 of
them. Also note that no more than two rots can be squeezed into one
lump's name. Some other two-rot lumps with a different format are
shown in the SPIDA1D1, SPIDA2D2, etc. lumps.

  IMPORTANT: Sprite lumps and flats cannot be added or replaced via pwads
unless they ALL are. That is, ALL sprites' lumps must be located in a
single wad file, and ALL flats' lumps must be in a single wad file. Wall
patches CAN be used in external wads, because the PNAMES lump gives a
number to every pname, and is used as a quick-index list to load in
wall patches.
  Version 1.666 was rumored to be able to include sprites in pwads (in
fact the README says it can), but it can't.


[5-1]: Picture Format
=====================

  Each picture has three sections. First, an 8-byte header composed of
four short-integers. Then a number of long-integer pointers. Then the
picture's pixel/color data. See [A-1] for concise BNF style definitions,
here is a meatier explanation of the format:

(A) The header's four fields are:

  (1) Width. The number of columns of picture data.
  (2) Height. The number of rows.
  (3) Left offset. The number of pixels to the left of the center;
        where the first column gets drawn.
  (4) Top offset. The number of pixels above the origin;
        where the top row is.

  The width and height define a rectangular space or limits for drawing
a picture within. To be "centered", (3) is usually about half of the
total width. If the picture had 30 columns, and (3) was 10, then it
would be off-center to the right, especially when the player is standing
right in front of it, looking at it. If a picture has 30 rows, and (4)
is 60, it will appear to "float" like a blue soul-sphere. If (4) equals
the number of rows, it will appear to rest on the ground. If (4) is less
than that for an object, the bottom part of the picture looks awkward.
  With walls patches, (3) is always (columns/2)-1, and (4) is always
(rows)-5. This is because the walls are drawn consistently within their
own space (There are two integers in each SIDEDEF which can offset the
starting position for drawing a wall's texture within the wall space).

  Finally, if (3) and (4) are NEGATIVE integers, then they are the
absolute coordinates from the top-left corner of the screen, to begin
drawing the picture, assuming the VIEW is full-screen (i.e., the full
320x200). This is only done with the picture of the player's current
weapon - fist, chainsaw, bfg9000, etc. The game engine scales the
picture down appropriatelyif the view is less than full-screen.

(B) After the header, there are N = field (1) = <width> = (# of columns)
4-byte <long> integers. These are pointers to the data for each COLUMN.
The value of the pointer represents the offset in bytes from the first
byte of the picture lump.

(C) Each column is composed of some number of BYTES (NOT integers),
arranged in "posts":

  The first byte is the row to begin drawing this post at. 0 means
whatever height the header (4) upwards-offset describes, larger numbers
move correspondingly down.
  The second byte is how many colored pixels (non-transparent) to draw,
going downwards.
  Then follow (# of pixels) + 2 bytes, which define what color each
pixel is, using the game palette. The first and last bytes AREN'T drawn,
and I don't know why they are there. Probably just leftovers from the
creation process on the NeXT machines. Only the middle (# of pixels in
this post) are drawn, starting at the row specified in the first byte
of the post.
  After the last byte of a post, either the column ends, or there is
another post, which will start as stated above.
  255 (0xFF) ends the column, so a column that starts this way is a null
column, all "transparent". Draw the next column.


-----------------------------------------------
CHAPTER [6]: Flats (Floor and Ceiling Textures)
-----------------------------------------------

  All the lumpnames for flats are in the directory between the F_START
and F_END entries. Calling them flats is a good way to avoid confusion
with wall textures. There is no look-up or meta-structure in flats as
there is in walls textures. Each flat is 4096 raw bytes, making a square
64 by 64 pixels. This is pasted onto a floor or ceiling with the same
orientation as the automap would imply, i.e. the first byte is the color
at the NW corner, the 64th byte (byte 63, 0x3f) is the NE corner, etc.
  The blocks in the automap grid are 128 by 128, so four flats will fit
in each block. Note that there is no way to offset the placement of flats,
as can be done with wall textures. They are pasted according to grid lines
64 apart, reckoned from the coordinate (0,0). This allows flats to flow
smoothly even across jagged boundaries between sectors with the same
floor or ceiling height.

  As discussed in chapter [5], replacement and/or new-name flats don't
work right from pwad files unless they are all in the same wad.
  Theoretically, you can change all the flats want by constructing a
new DOOM.WAD or ALLFLATS.WAD pwad, but you have to make sure no floor
or ceiling uses an entry name which isn't in your F_ section. And you
have to include these four entries for DOOM 1 use, although you can
change their actual contents (pictures): FLOOR4_8, SFLR6_1, MFLR8_4,
and FLOOR7_2. The first three are needed as backgrounds for the episode 
end texts. The last is what is shown "outside" the border of the display
window if the display is not full-screen.


[6-1]: Animated Flats
---------------------

  See Chapter [8-4-1] for a discussion of how the animated walls and
flats work. Unfortunately, the fact that the flats all need to be
lumped together in one wad file means that its not possible to change
the animations via a pwad file, unless it contains ALL the flats, which
amounts to several hundred k. Plus it is illegal to distribute the
original data, so to pass around modifications, either all the flats
must be all-new, or a utility must be used to construct a FLATS.WAD
on an end-user's hard drive, using the original DOOM.WAD plus the
additions. (Note: Bernd Kreimeier, listed in [A-5], has written a
utility that does just this. It is called DMADDS11).


-----------------------------
CHAPTER [7]: Sounds and Music
-----------------------------


[7-1]: PC Speaker Sound Effects
===============================

  DP* entries in the directory refer to lumps that are sound data for
systems using the PC speaker.
  It's a quick and simple format. First is a <short> that's always 0,
then a <short> that's the number of bytes of sound data, then follow
that many bytes worth of sound data. That is, the lump's bytes will be
0, 0, N, 0, then N bytes of data. The DP* lumps range in size from around
10 bytes to around 150 bytes, and the data seem to range from 0 to 96
(0x00 to 0x60). The numbers obviously indicate frequency, but beyond
that I don't know the exact correlation in Hz, nor the time duration
of each byte worth of data. Feel free to figure this out and tell me.


[7-2]: Soundcard Sound Effects
==============================

  DS* entries in the directory refer to lumps that are sound data for
systems using soundcards.
  This data is in a RAW format for 8-bit 11 KHz mono sound - first is
an 8-byte header composed of 4 unsigned short integers: 

(1) 3           (means what?)
(2) 11025       (the sample rate, samples per second)
(3) N           (the number of samples)
(4) 0

  Each sample is a single byte, since they are 8-bit samples. The
maximum number of samples is 65535, so at 11 KHz, a little less than
6 seconds is the longest possible sound effect.


[7-3]: Music
============

  D_* entries is the directory refer to lumps that are music. This
music is in the MUS file format, which goes like this:

offset  type    contents

0       ASCII   "MUS" and CTRL-Z (hex 4d 55 53 1a)
4      <short>  # of bytes of music data
6      <short>  # of bytes of header data (offset to start of music)
8      <short>  number of primary channels
10     <short>  number of secondary channels
12     <short>  number of instrument patches
14     <short>  0
16     <short>s instrument patch numbers
X to end  ?     Music data

  X is the header size (the second short). Drum patch numbers (greater
than 128) are 28 less than the numbers listed in the DMXGUS lump.
  What the exact format of the music data is, I don't know.


[7-4]: GENMIDI
==============

  This has something to do with General MIDI, obviously. This lump
has 3 sections: an 8-byte header (the ASCII text "#OPL_II#"), then
150 36-byte records (1 for each instrument), then 150 32-byte strings
(names of instruments, padded with zeros). Perhaps the 36 bytes contain
waveform information for the General MIDI standard instruments (this
guess is based on exactly one glance at a dump of the byte values,
so don't put too much faith in it).


[7-5]: DMXGUS
=============

  This lump is used to do instrument patch mappings on the Gravis
Ultra-Sound soundcard. It's in a very simple format - ASCII text!
Here's the start and end of the DMXGUS lump from DOOM 1 version 1.2,
which is 200 lines, of which the first 10 are comments:

#Purpose: Different size patch libraries for different memory sizes.
#         The libraries are built in such a way as to leave 8K+32bytes
#         after the patches are loaded for digital audio.
#
#Revision History: 06/22/93 - Fixed problem with 512K patch library
#                  07/26/93 - patch names changed in various releases
#
#
#Explanation of Columns: Patch #  256K  512K  768K  1024K  Patch Name
#
0, 2, 1, 1, 1, acpiano
1, 2, 1, 1, 1, britepno
2, 2, 1, 1, 1, synpiano