home *** CD-ROM | disk | FTP | other *** search
/ The Complete Doom Accessory Pack 4 / TheCompleteDoomAccessoryPackVolumeIvCd.bin / faqs / dmspec16.txt < prev    next >
Text File  |  1995-01-12  |  173KB  |  3,812 lines
  1. From MSFell@aol.com  Thu Dec 15 1994, upload as DMSPEC16.ZIP
  2.  
  3.  
  4. ------------------------------------------------------------------------------
  5.  
  6.                            T H E   U N O F F I C I A L
  7. =================     ===============     ===============   ================
  8. \\ . . . . . . .\\   //. . . . . . .\\   //. . . . . . .\\  \\. . .\\// . .//
  9. ||. . ._____. . .|| ||. . ._____. . .|| ||. . ._____. . .|| || . . .\/ . ..||
  10. || . .||   ||. . || || . .||   ||. . || || . .||   ||. . || ||. . . . . . .||
  11. ||. . ||   || . .|| ||. . ||   || . .|| ||. . ||   || . .|| || . | . . . ..||
  12. || . .||   ||. _-|| ||-_ .||   ||. . || || . .||   ||. _-|| ||-_.|\ . . . .||
  13. ||. . ||   ||-'  || ||  `-||   || . .|| ||. . ||   ||-'  || ||  `|\_ . .|..||
  14. || . _||   ||    || ||    ||   ||_ . || || . _||   ||    || ||   |\ `-_/| .||
  15. ||_-' ||  .|/    || ||    \|.  || `-_|| ||_-' ||  .|/    || ||   | \  / -_.||
  16. ||    ||_-'      || ||      `-_||    || ||    ||_-'      || ||   | \  / | '||
  17. ||    `'         || ||         `'    || ||    `'         || ||   | \  / |  ||
  18. ||            .===' `===.         .==='.`===.         .===' /==. |  \/  |  ||
  19. ||         .=='   \_|-_ `===. .==='   _|_   `===. .===' _-|/   `==  \/  |  ||
  20. ||      .=='    _-'    `-_  `='    _-'   `-_    `='  _-'   `-_  /|  \/  |  ||
  21. ||   .=='    _-'          `-__\._-'         `-_./__-'         `' |. /|  |  ||
  22. ||.=='    _-'                                                     `' | /==.||
  23. =='    _-'         S         P         E         C         S          \/  `==
  24. \   _-'                                                                `-_  /
  25.  `''                                                                      ``'
  26.                        Release v1.666 - December 15th, 1994
  27.                    Written by: Matthew S Fell (msfell@aol.com)
  28.  
  29.           "The poets talk about love, ...but what I talk about is DOOM,
  30.                   because in the end, DOOM is all that counts."
  31.             - Alex Machine/George Stark/Stephen King, _The Dark Half_
  32. ------------------------------------------------------------------------------
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41. ----------
  42. DISCLAIMER
  43. ----------
  44.  
  45.         These specs are to aid in informing the public about the games
  46. DOOM and DOOM 2, by id Software.  In no way should this promote your
  47. killing yourself, killing others, or killing in any other fashion.
  48. Additionally, the author does not claim ANY responsibility
  49. regarding ANY illegal activity concerning this file, or indirectly related
  50. to this file.  The information contained in this file only reflects
  51. id Software indirectly, and questioning id Software regarding any
  52. information in this file is not recommended.
  53.  
  54. ----------------
  55. COPYRIGHT NOTICE
  56. ----------------
  57.  
  58. This article is Copyright 1994 by Matt Fell.  All rights reserved.
  59. You are granted the following rights:
  60.  
  61. I.  To make copies of this work in original form, so long as
  62.       (a) the copies are exact and complete;
  63.       (b) the copies include the copyright notice and these paragraphs
  64.           in their entirety;
  65.       (c) the copies give obvious credit to the author, Matt Fell;
  66.       (d) the copies are in electronic form.
  67. II. To distribute this work, or copies made under the provisions
  68.     above, so long as
  69.       (a) this is the original work and not a derivative form;
  70.       (b) you do not charge a fee for copying or for distribution;
  71.       (c) you ensure that the distributed form includes the copyright
  72.           notice, this paragraph, the disclaimer of warranty in
  73.           their entirety and credit to the author;
  74.       (d) the distributed form is not in an electronic magazine or
  75.           within computer software (prior explicit permission may be
  76.           obtained from the author);
  77.       (e) the distributed form is the NEWEST version of the article to
  78.           the best of the knowledge of the distributor;
  79.       (f) the distributed form is electronic.
  80.  
  81.         You may not distribute this work by any non-electronic media,
  82. including but not limited to books, newsletters, magazines, manuals,
  83. catalogs, and speech.  You may not distribute this work in electronic
  84. magazines or within computer software without prior written explicit
  85. permission.  These rights are temporary and revocable upon written, oral,
  86. or other notice by the author. This copyright notice shall be governed
  87. by the laws of the state of Ohio.
  88.         If you would like additional rights beyond those granted above,
  89. write to the author at "msfell@aol.com" on the Internet.
  90.  
  91.  
  92. --------
  93. CONTENTS
  94. --------
  95.  
  96. [1] Introduction
  97.         [1-1] id Software's Copyright
  98.         [1-2] What's New
  99. [2] The Basics
  100.         [2-1] Pwads
  101.         [2-2] DOOM version information
  102.         [2-3] Terminology conventions
  103. [3] List of DOOM.WAD Directory Entries
  104. [4] The Levels
  105.         [4-1] ExMy or MAPxy
  106.         [4-2] THINGS
  107.                 [4-2-1] Thing Types
  108.                 [4-2-2] Thing Sizes
  109.                 [4-2-3] Thing Options
  110.         [4-3] LINEDEFS
  111.                 [4-3-1] Linedef Flags
  112.                 [4-3-2] Linedef Types
  113.         [4-4] SIDEDEFS
  114.         [4-5] VERTEXES
  115.         [4-6] SEGS
  116.         [4-7] SSECTORS
  117.         [4-8] NODES
  118.         [4-9] SECTORS
  119.                 [4-9-1] Special Sector Types
  120.         [4-10] REJECT
  121.         [4-11] BLOCKMAP
  122. [5] Graphics
  123.         [5-1] Picture Format
  124. [6] Flats (Floor and Ceiling Textures)
  125.         [6-1] Animated Floors, see [8-4-1]
  126. [7] Sounds and Music
  127.         [7-1] PC Speaker Sound Effects
  128.         [7-2] Soundcard Sound Effects
  129.         [7-3] Music
  130.         [7-4] GENMIDI
  131.         [7-5] DMXGUS
  132. [8] Miscellaneous Lumps
  133.         [8-1] PLAYPAL
  134.         [8-2] COLORMAP
  135.         [8-3] ENDOOM
  136.         [8-4] TEXTURE1 and TEXTURE2
  137.                 [8-4-1] Animated Walls
  138.                 [8-4-2] The SKY Textures
  139.         [8-5] PNAMES
  140.         [8-6] DEMOs
  141.                 [8-6-1] Level changes from 1.2 to 1.666 DOOM.WAD
  142. [9] Savegame Files
  143.  
  144. [10] The DOOM.EXE File
  145.         [10-1] Version 1.2 DOOM.EXE Data Segment Overview
  146.         [10-1] Version 1.666 DOOM.EXE Data Segment Overview
  147.         [10-3] Detail on some EXE Data Structures
  148.  
  149. APPENDICES
  150.  
  151. [A-1] Backus-Naur Form definitions of wad elements
  152. [A-2] Engine limits
  153. [A-3] DOOM.WAD changes and errors
  154. [A-3] A BLOCKMAP algorithm
  155. [A-4] Other helpful documents
  156. [A-5] Acknowledgments
  157.  
  158.  
  159. -------------------------
  160. CHAPTER [1]: Introduction
  161. -------------------------
  162.  
  163.   DOOM is simply an all-time great game. A big factor in its success
  164. and durability is the plethora of user-created add-ons. id Software
  165. tacitly encouraged them by including the -FILE parameter, and by having
  166. a data format that is both straightforward and easy to understand.
  167. DOOM is basically two files, DOOM.EXE and DOOM.WAD. DOOM.EXE is the
  168. "engine" which does the display and controls the game, and DOOM.WAD has
  169. ALL of the graphics, sound, and map/level data that the engine uses.
  170. The -FILE parameter allows small or large external "WAD" files to be
  171. incorporated, changing any number of those graphics, sounds, and maps.
  172.   DOOM 2 has many things in common with DOOM. It uses the same EXE file
  173. as version 1.666 of DOOM, and the WAD file format is the same. It's just
  174. the contents of the WAD file that are different; there are more enemies!
  175. more pictures! more weapons! more stuff!!
  176.  
  177.   This document explains in great detail nearly all aspects of the doom
  178. WAD file format. And a new chapter (10) documents the location of data
  179. within DOOM.EXE itself, so that various unusual game-play changes can
  180. be made. This information has been updated to apply to DOOM 2 as well
  181. as DOOM 1.
  182.   The specs were originally conceived as an aid to programmers making
  183. DOOM utilities, especially map-editors. Coincidentally, there might also
  184. be information useful to advanced level designers and players.
  185.   The material herein is somewhat technical and it is not recommended for
  186. beginners, unless they are determined. There are some other very useful
  187. documents in existence; I list the ones I know of in Appendix [A-3].
  188.  
  189.  
  190. [1-1]: id Software's Copyright and the Shareware Version
  191. ========================================================
  192.  
  193.   My comments and statements are by no means official, and the excerpts
  194. below are just the parts that I think are relevant to these specs. Please
  195. read the LICENSE.DOC and README.EXE that came with DOOM.
  196.  
  197.   The LICENSE.DOC says:
  198.  
  199.     "You shall not:  rent, lease, sell, distribute for money or other
  200.     consideration, modify, translate, disassemble, decompile, reverse
  201.     engineer, or create derivative works based upon the Software.
  202.     Notwithstanding the foregoing, you may create a map editor, modify
  203.     maps and make your own maps (collectively referenced as the
  204.     "Permitted Derivative Works") for the Software.  You may not sell
  205.     or distribute any Permitted Derivative Works but you may exchange
  206.     the Permitted Derivative Works at no charge amongst other end-users.
  207.     In order to commercially distribute any such map editor or data
  208.     utility you must first sign ID's Data Utility License and ID
  209.     reserves the right to deny authorization to commercial distribute
  210.     the any such map editor or data utility.  You may request a copy of
  211.     the Data Editor License from ID"
  212.  
  213.     "(except for backup purposes) You may not otherwise reproduce, copy
  214.     or disclose to others, in whole or in any part, the Software."
  215.  
  216.   The README says:
  217.  
  218.     "id Software respectfully requests that you do not modify the levels
  219.     for the shareware version of DOOM.  We feel that the distribution of
  220.     new levels that work with the shareware version of DOOM will lessen a
  221.     potential user's incentive to purchase the registered version.
  222.  
  223.     "If you would like to work with modified levels of DOOM, we encourage
  224.     you to purchase the registered version of the game."
  225.  
  226.   If you are making add-ons, plan on them not working on the shareware
  227. game, and plan on including statements about the trademarks and copyrights
  228. that id Software owns, as well as disclaimers that they won't support your
  229. add-on product, nor will they support DOOM after it has been modified.
  230.  
  231.  
  232. [1-2]: What's New
  233. =================
  234.  
  235.   Each new version of these specs renders the previous version obsolete.
  236.   This document has grown considerably in size, and to fight that trend,
  237. I'll not discuss it any more.
  238.   It has now been five months since the specs were updated. I won't talk
  239. about that either. I'll just apologize for not releasing updates in late
  240. May and July like I should have. Those updates would have been numbered
  241. 1.4 and 1.5, so perhaps that's why this is version 1.666.
  242.   Here's some of the new or revised sections since the 1.3 specs:
  243.  
  244.     - DOOM 2 info, especially in [4-2-1] and [4-3-2]
  245.     - lots of info on the DOOM.EXE file in [10]
  246.     - BNF style definitions in [A-1]
  247.     - DOOM engine limits in [A-2]
  248.     - the DEMO format [8-6]
  249.     - the ENDOOM lump [8-3]
  250.     - comprehensive list of WAD lumps in [3]
  251.  
  252.     - many parts rewritten for clarity
  253.     - changes in terminology to reflect id's where possible, and to be
  254.         more consistent throughout
  255.     - reformatted again, errors and typos corrected
  256.  
  257.  
  258. -------------------
  259. CHAPTER [2]: Basics
  260. -------------------
  261.  
  262.   The starting point is the concept of "WAD". It is not an acronym, it
  263. just means a collection of data. Throughout this document, "WAD" or "wad"
  264. will mean a file with a .WAD extension that contains data for the doom
  265. engine to use.
  266.   A WAD file has three parts:
  267.  
  268.   (1) a twelve-byte header
  269.   (2) one or more "lumps"
  270.   (3) a directory or "info table" that contains the names, offsets, and
  271.         sizes of all the lumps in the WAD
  272.  
  273.   The header consists of three four-byte parts:
  274.  
  275.     (a) an ASCII string which must be either "IWAD" or "PWAD"
  276.     (b) a 4-byte (long) integer which is the number of lumps in the wad
  277.     (c) a long integer which is the file offset to the start of
  278.           the directory
  279.  
  280.   The directory has one 16-byte entry for every lump. Each entry consists
  281. of three parts:
  282.  
  283.     (a) a long integer, the file offset to the start of the lump
  284.     (b) a long integer, the size of the lump in bytes
  285.     (c) an 8-byte ASCII string, the name of the lump, padded with zeros.
  286.           For example, the "DEMO1" entry in hexadecimal would be
  287.           (44 45 4D 4F 31 00 00 00)
  288.  
  289.   A "lump" is just data, in one of several different formats. Some
  290. contain sound data, some contain graphics data, some contain level
  291. structure data, etc. These specs are mostly concerned with delineating
  292. the formats of the various lump types. There are 10 different types of
  293. map/level lump formats, each has a section in chapter [4] (sections 2-11).
  294. There are 13 other types of lump formats, listed below with the section
  295. where the format is explained, and the actual lump names in parentheses.
  296. Also, Appendix [A-1] has definitions of the structures of all these
  297. WAD elements.
  298.  
  299.   [8-1] palettes (PLAYPAL)
  300.   [8-2] colormaps (COLORMAP)
  301.   [8-3] dos exit text (ENDOOM)
  302.   [8-6] demos (DEMO1, DEMO2, and DEMO3)
  303.   [8-4] texture composition list (TEXTURE1 and TEXTURE2)
  304.   [8-5] wall patch "number for name" indexing list (PNAMES)
  305.   [7-4] midi mapping (GENMIDI)
  306.   [7-5] Gravis UltraSound patch mappings (DMXGUS)
  307.   [7-1] PC speaker sound effects (DP*)
  308.   [7-2] Soundcard sound effects (DS*)
  309.   [7-3] songs (D_*)
  310.   [6]   flats (lumpnames between F_START and F_END)
  311.   [5]   all other graphics (all other lumps)
  312.  
  313.   The "marker" and "label" lump names like "S_START" and "E1M1" (or
  314. "MAP01") do not actually refer to lumps - they have zero length. They
  315. merely serve to mark the beginning or end of a set of related lumps.
  316.  
  317.   It is possible to include other directory entries and lumps in a wad
  318. file, e.g. an entry called CLOWNS could point to a lump that includes the
  319. level creator's name, date of completion, and the latitude and longitude
  320. of the Holy Grail. None of these non-standard entries will be used by
  321. DOOM, nor will they cause it problems.
  322.  
  323.  
  324. [2-1]: Pwads
  325. ============
  326.  
  327.   There are two types of wad files. The original DOOM.WAD and DOOM2.WAD
  328. files are "IWAD"s, or "Internal wads", meaning they contain all of the
  329. data necessary to play. The other type is the "PWAD" file, "Patch wad",
  330. an external file which has the same structure, but with far fewer entries
  331. in the directory. The data in a pwad is substituted for the original data
  332. in the DOOM.WAD, thus allowing for much easier distribution of new levels.
  333. Only those resources listed in the pwad's directory are changed,
  334. everything else is loaded from the IWAD. All external wads should have
  335. the "PWAD" indicator, as id has requested.
  336.   A typical pwad might contain new data for a single level, in which
  337. case it would contain the 10 lumps and 11 directory entries necessary
  338. to define the level (as described in chapter [4]).
  339.   A pwad file may contain more than one level or parts of levels, in
  340. addition to replacement graphics, sounds, etc. (as of version 1.666,
  341. sprites and flats do NOT work from pwads - see chapter [5] for more).
  342. In fact, there is apparently no limit to how many entries may be in a
  343. pwad. The original doom levels are pretty complicated, and they are
  344. from 50-200 kilobytes each in size, uncompressed.
  345.   Pwad files need to have the extension .WAD to work. Many of them have
  346. descriptive names, e.g. if J.R.R. Tolkien made a new level, he might call
  347. it GONDOLIN.WAD - to use this level, a player would type
  348.  
  349.   DOOM -FILE GONDOLIN.WAD 
  350.  
  351. at the command line, along with any other parameters. More than one
  352. external file can be added, thus in general:
  353.  
  354.   DOOM -FILE [pwad_filename] [pwad_filename] [pwad_filename] ...
  355.  
  356.   If there are duplicate entries amongst the directories of all the
  357. wads being "added", the pwads listed LAST take precedence.
  358.   When the game loads, a "modified game" message will appear if there
  359. are any pwads involved, reminding the player that id Software will not
  360. give technical support or answer questions regarding modified levels.
  361.   With DOOM version 1.666, there is also the @responsefile option for
  362. listing command line parameters and -file specifications. See the DOOM
  363. README or the latest FAQ for more information. Also, there are numerous
  364. "front-end" utilities that make it easier to play pwads, e.g. load several
  365. external files at once, warp to certain levels, specify options, etc.
  366.  
  367.  
  368. [2-2]: DOOM versions
  369. ====================
  370.  
  371. Version Date    Time    Is
  372.  
  373. 1.0     10dec93 01:00   first release (aka DOOM Operating System 0.99)
  374. 1.1     16dec93 01:10   slightly different from 1.0, newer dos extender
  375. 1.2     17feb94 01:20   modem play added!
  376. 1.3     -       -       unauthorized beta release
  377. 1.4     28jun94 01:04   shareware beta
  378. 1.5     ??jul94 ?       shareware beta
  379. 1.6     03aug94 01:06   shareware beta
  380. 1.666   01sep94 16:42   registered full upgrade!
  381. 1.666   ?       ?       DOOM 2!
  382.  
  383.   The important releases as of this writing are 1.2 and 1.666. Hopefully,
  384. everyone will move up to 1.666 soon; it has many important improvements
  385. over 1.2. The 1.4, 1.5, and 1.6 shareware betas contained increasing
  386. amounts of the stuff that's now in 1.666, but there's no information
  387. here about what exactly those changes were. One, I didn't keep track,
  388. and two, they're not really important.
  389.   See appendix [A-3] for some miscellany about what has changed from
  390. version to version.
  391.  
  392.  
  393. [2-3]: Terminology conventions
  394. ==============================
  395.  
  396.   Throughout this document, I will use the following conventions for
  397. numbers and variable types:
  398.  
  399. (1) Most numbers will be decimal. Hexadecimal numbers will usually be
  400.         labeled thus: 0xffff or $ffff. But sometimes I'll say "hex ...".
  401.         And in tablature form, a column heading "HEX" indicates all the
  402.         numbers in that column are hexadecimal.
  403. (2) "byte" is of course the generic, 8 bits. It will usually mean one
  404.         8-bit component of a larger data type, or an 8-bit ASCII
  405.         character, or some such. As a number, it is an unsigned 8-bit
  406.         integer (0..255).
  407. (3) "short" is a signed 16-bit integer (-32768..32767), stored in
  408.         lo-hi format.
  409. (4) "ushort" or "unsigned short" is an unsigned 16-bit integer (0..65535).
  410. (5) "integer" or "long" is a signed 32-bit integer. If you don't read
  411.         this first, my use of the word "integer" might not be immediately
  412.         apparent.
  413. (6) "string8" or "8-byte string" is an ASCII string with length between
  414.         1 and 8 characters inclusive. If its length is less than 8, the
  415.         remaining bytes are zeros.
  416. (7) The first byte of a file or any data structure, for addressing and
  417.         offset purposes, is byte #0, not byte #1.
  418. (8) Some abbreviations I use: E1, E2, and E3 refer to episodes 1, 2, and
  419.         3 respectively. "The EXE" means the file DOOM.EXE.
  420. (666) Any reference to this number is purely intentional.
  421.  
  422.  
  423. -----------------------------------------------
  424. CHAPTER [3]: List of DOOM.WAD Directory Entries
  425. -----------------------------------------------
  426.  
  427.   There are over 2000 entries in the DOOM.WAD directory. Most of them
  428. can be easily described in groups, and so are not explicitly mentioned
  429. in this list. This includes the sprites (see [4-2-1] for sprite names
  430. and [5] for the sprite lump naming system), the wall patches ([8-4] and
  431. [8-5] have more info), the flats (chapter [6]), the sounds and songs
  432. (chapter [7]), and the map data lumps (chapter [4]). All the others
  433. are listed here.
  434.   There have been several changes from version to version. The "Ver"
  435. column indicates in which doom versions the lump exists:
  436.  
  437. ___     no indication means it is in every version. Most are like this.
  438. 1.1     it was in 1.0 and 1.1, but not in 1.2 and later. It is obsolete.
  439. 1.2     it is not in 1.1 and earlier, only in 1.2 and up.
  440. 1.6     it is not in 1.2 and earlier, only in 1.666 and up.
  441. r       it is only in the registered version, not the shareware.
  442. 1       it is only in DOOM 1, it is not in DOOM 2.
  443. 2       it is only in DOOM 2, it is not in DOOM 1.
  444.  
  445.   In the lump names, x (and y and e) indicates variable ASCII
  446. characters, and * can be replaced by an ASCII string (up to the
  447. 8-byte lumpname limit).
  448.  
  449. LumpName  Ver   Description
  450. --------  ---   -----------
  451. PLAYPAL         fourteen 256 color palettes. See [8-1].
  452. COLORMAP        maps colors in the palette down to darker ones. [8-2].
  453. ENDOOM          text message displayed when you exit to DOS. [8-3].
  454. DEMOx           x=1-3, are the demos. [8-6].
  455. ExMy            subsequent entries define a single level's data. [4].
  456. MAPxy     2     like ExMy, but for DOOM 2.
  457. TEXTURE1        list of wall texture names and their composition data,
  458.                   used in the SIDEDEF portion of each level. [8-4].
  459. TEXTURE2  r     more wall texture compositions.
  460. PNAMES          lists all lump names used as wall patches. [8-5].
  461. GENMIDI         General Midi standard instrument data. [7-3].
  462. DMXGUS          Gravis Ultra Sound instrument patches. [7-4].
  463.  
  464. D_ExMy          music for a doom 1 level. [7-2].
  465. D_INTER         music played on the summary screen between levels.
  466. D_INTRO         music played when the game starts.
  467. D_INTROA  1.2   more introductory music.
  468. D_VICTOR        music played on the victory text-screen after an episode.
  469. D_BUNNY   r     music for while a certain rabbit has his story told...
  470. D_*       2     music for a doom 2 level.
  471.  
  472. DP_*      vary  PC speaker sound effects. [7-1].
  473. DS_*      vary  Soundcard sound effects. [7-1].
  474.  
  475.   All the remaining entries in the directory, except the flats between
  476. F_START and F_END, and the "markers" like S_START, refer to lumps which
  477. are pictures, in the doom/wad graphic format described in chapter [5].
  478. The flats are also pictures, but in a format described in chapter [6].
  479.   The next seven are full screen (320 by 200 pixel) pictures. After
  480. that, ST* are status-bar pictures, WI* are for the screens between
  481. levels, and M_* are for menus.
  482.  
  483. HELP1           Ad-screen says Register!, with some screen shots.
  484. HELP2           Actual help, all the controls explained.
  485. TITLEPIC        Maybe this is the title screen? Gee, I dunno...
  486. CREDIT          People at id Software who created this great game.
  487. VICTORY2  r     Screen shown after a victorious end to episode 2.
  488. PFUB1     r     A nice little rabbit minding his own peas and queues...
  489. PFUB2     r     ...a hint of what's waiting in Doom 2.
  490.  
  491. ENDx      r     x=0-6, big red "THE END" gets shot up.
  492. AMMNUMx         x=0-9. Small grey digits for ammo count (15/200 etc).
  493. STxBARy   1.1   x=M or A, y= L or R. Status bar used to be in pieces.
  494. STCHAT    1.1   Status bar used to have a "chat" box.
  495. STRSNUMx  1.1   x=0-9. Small red digits.
  496. STWEAPx   1.1   x=0-5. COOL little weapon icons. Why'd they drop them?
  497. STFRAGS   1.1   Tiny "FRAG" to be placed on top of part of status bar.
  498. STBAR     1.2   Status Bar as used in deathmatches.
  499. STGNUMx         x=0-9. Small grey digits used on the "Arms" panel.
  500. STTNUMx         x=0-9. Big red digits used for Armor, Health, etc.
  501. STTMINUS  1.6   Big red "-" used for negative frags.
  502. STYSNUMx        x=0-9. Small yellow digits used on the "Arms" panel.
  503. STTPRCNT        Big red % used in Armor and Health.
  504. STKEYSx         x=0-5. Blue/Yellow/Red Keycards and Skullkeys.
  505. STDISK          Disk, used at bottom right corner during disk accesses.
  506. STCDROM   1.6   CD, used during CD-ROM accesses.
  507. STARMS          "Arms" panel which replaces "Frags" in non-deathmatch.
  508. STCFNxxx        xxx=033-095, also 121. Small red ASCII characters.
  509. STFBx           x=0-3. Green/black/brown/red squares, for ST player faces.
  510. STPBx           x=0-3. Squares with bottoms, for inter-level screens.
  511. STFSTxy         x=0-4, y=0-2. Player face. x=0 is 100% health...x=4 is
  512.                   very low health. y=0 is glancing right, y=2 left.
  513. STFTLx0         x=0-4. Face looking left, player hurt from that direction.
  514. STFTRx0         x=0-4. Face looking right.
  515. STFOUCHx        x=0-4. Face looking surprised (hurt bad).
  516. STFEVLx         x=0-4. Face with a grin (when pick up new weapons).
  517. STFKILLx        x=0-4. Face with a grimace (when killing foes).
  518. STFGOD0         Face with yellow eyes (invulnerable).
  519. STFDEAD0        Dead face.
  520. BRDR_*          Tiny pictures used as a border between a less-than-full
  521.                   screen view and the "outside" marbleized zone. TL is
  522.                   top left, BR bottom right, you can guess the rest.
  523. WIBONUS   1.1   Medium sized red text "BONUS"
  524. WISCORE   1.1   "SCORE"
  525. WIMSTPx   1.1   x=0-3. Red text "ONE" to "FOUR".
  526. WIMSTBx   1.1   x=0-3. Grey text "ONE" to "FOUR".
  527. WIMINUS   1.6   Small red "-" used for negative frags.
  528. WIMAPx          x=0-2. 320x200 maps used on inter-level screens for e1,2,3.
  529. WIAe0x0y        patches used to animate inter-level maps.
  530. WIURH0          "YOU ARE HERE" with an arrow pointing left.
  531. WIURH1          "YOU ARE HERE" with an arrow pointing right.
  532. WISPLAT         Splat mark that indicates a completed level.
  533. WIOSTK          "KILLS"
  534. WIOSTI          "ITEMS"
  535. WIF             "FINISHED"
  536. WIMSTT          "TOTAL"
  537. WIOSTS          "SCRT"
  538. WIOSTF          "F."
  539. WITIME          "TIME"
  540. WIPAR           "PAR"
  541. WIMSTAR         "YOU"
  542. WIPCNT          "%"
  543. WINUMx          x=0-9. Medium sized red digits.
  544. WICOLON         ":"
  545. WISUCKS         "SUCKS"
  546. WIFRGS          "FRAGS"
  547. WILVxy          x=0-2, y=0-8. E(x+1)M(y+1) level names in grey/white letters.
  548. WIPx            x=1-4. Red "P1" - "P4", for multiplayer summaries.
  549. WIBPx           x=1-4. Grey "P1" - "P4"
  550. WIKILRS         Small red "KILLERS" going sideways up, for deathmatches.
  551. WIVCTMS         Small red "VICTIMS" for the top of the deathmatch chart.
  552. WISCRT2         "SECRET"
  553. WIENTER         "ENTERING"
  554. M_DOOM          The DOOM logo
  555. M_RDTHIS        Big red "Read This!"
  556. M_OPTION        "Options"
  557. M_QUITG         "Quit Game"
  558. M_NGAME         "New Game"
  559. M_SKULL1        The skull indicator with eyes lit.
  560. M_SKULL2        The skull indicator with eyes unlit.
  561. M_THERMO        The marker on e.g. the Sfx volume "thermometer".
  562. M_THERMR        The right end of the thermometer.
  563. M_THERML        The left end.
  564. M_THERMM        The middle, repeated over and over.
  565. M_ENDGAM        "End Game"
  566. M_PAUSE         "Pause"
  567. M_MESSG         "Messages:"
  568. M_MSGON         "on"
  569. M_MSGOFF        "off"
  570. M_EPISOD        "Which Epsiode?"
  571. M_EPI1          "Knee-Deep In The Dead"
  572. M_EPI2          "The Shores Of Hell"
  573. M_EPI3          "Inferno"
  574. M_HURT          "Hurt me plenty."
  575. M_JKILL         "I'm too young to die."
  576. M_ROUGH         "Hey, not too rough."
  577. M_SKILL         "Choose Skill Level:"
  578. M_NEWG          "NEW GAME" (title of New Game menu)
  579. M_ULTRA         "Ultra-Violence."
  580. M_NMARE   1.2   "Nightmare!"
  581. M_SVOL          "Sound Volume"
  582. M_OPTTTL        "OPTIONS" (title of Options menu)
  583. M_SAVEG         "Save Game"
  584. M_LOADG         "Load Game"
  585. M_DISP          "Display"
  586. M_MSENS         "Mouse sensitivity"
  587. M_GDHIGH        "high"
  588. M_GDLOW         "low"
  589. M_DETAIL        "Graphic Detail:"
  590. M_DISOPT        "DISPLAY OPTIONS"
  591. M_SCRNSZ        "Screen Size"
  592. M_SGTTL         "SAVE GAME"
  593. M_LGTTL         "LOAD GAME"
  594. M_SFXVOL        "Sfx Volume"
  595. M_MUSVOL        "Music Volume"
  596. M_LSLEFT        Load/save box, left part
  597. M_LSCNTR        Load/save box, center part (repeated)
  598. M_LSRGHT        Load/save box, right part
  599.  
  600.   The following entries are markers that do not point to a lump; they
  601. have zero size:
  602.  
  603. S_START         marks the start of the item/monster "sprite" section.
  604.                   See chapter [5] for the naming convention used here.
  605. S_END           is immediately after the last sprite.
  606. P_START         marks the beginning of the wall patches.
  607. P1_START          before the first of the shareware wall patches.
  608. P1_END            after the last of the shareware wall patches.
  609. P2_START  r       registered wall patches.
  610. P2_END    r       registered wall patches.
  611. P_END           marks the end of the wall patches.
  612. F_START         marks the beginning of the flats (floor textures).
  613. F1_START          shareware flats.
  614. F1_END            shareware flats.
  615. F2_START  r       registered flats.
  616. F2_END    r       registered flats.
  617. F_END           marks the end of the flats.
  618.  
  619.  
  620. -----------------------
  621. CHAPTER [4]: The Levels
  622. -----------------------
  623.  
  624.   Each level has eleven directory entries and ten lumps: E[x]M[y] (or
  625. MAPxy in a DOOM 2 wad), THINGS, LINEDEFS, SIDEDEFS, VERTEXES, SEGS,
  626. SSECTORS, NODES, SECTORS, REJECT, and BLOCKMAP.
  627.   In the DOOM.WAD file, all of these entries are present for every level.
  628. In a pwad external file, they don't all need to be present. Whichever
  629. entries are in a pwad will be substituted for the originals. For example,
  630. a pwad with just two entries, E3M6 and THINGS, would use all the walls
  631. and such from the original E3M6, but could have a completely different
  632. set of THINGS.
  633.  
  634.  
  635. [4-1]: ExMy or MAPxy
  636. ====================
  637.  
  638.   DOOM 1 levels have an ExMy label in a wad's directory. x is a single
  639. (ASCII) digit 1-3 for the episode number and y is 1-9 for the mission
  640. number.
  641.   DOOM 2 levels have a MAPxy label in a wad's directory. xy can range
  642. from (ASCII) 01 to 32, for the level number.
  643.   This label just indicates that the lump names following it are part
  644. of the designated level. The label does not actually point to a lump,
  645. and the size field in the directory is 0. The assignment of lumps to
  646. this level stops with either the next ExMy or MAPxy entry, or with a
  647. non-map entry like TEXTURE1.
  648.   Without these labels, there would be no way to differentiate amongst
  649. the many lumps named "THINGS", "LINEDEFS", etc.
  650.  
  651.  
  652. [4-2]: THINGS
  653. =============
  654.  
  655.   "Things" in DOOM are player start positions, monsters, weapons, keys,
  656. barrels, etc. The size of each THINGS lump will be a multiple of ten,
  657. since each thing requires ten bytes to describe it, in five <short>
  658. fields:
  659.  
  660. (1) X position of thing (at level's inception)
  661. (2) Y position of thing
  662. (3) Angle the thing faces. On the automap, 0 is east, 90 is north, 180
  663.       is west, 270 is south. This value is only used for monsters, player
  664.       starts, deathmatch starts, and teleporter landing spots. Other
  665.       things look the same from all directions. Values are rounded to
  666.       the nearest 45 degree angle, so if the value is 80, it will
  667.       actually face 90 - north.
  668. (4) Type of thing, see next subsection, [4-2-1]
  669. (5) Thing options, see [4-2-3]
  670.  
  671.  
  672. [4-2-1]: Thing Types
  673. --------------------
  674.  
  675.   Short 4 of 5, occupying bytes 6-7 of each thing record, specifies its
  676. kind. The table below summarizes the different types. They are listed
  677. in functional groups. You can easily get a numerical-order list by
  678. extracting this table and SORTing it.
  679.  
  680. Dec/Hex The thing's number in decimal and hexadecimal. This is the
  681.           number used in the THINGS lump on a level (ExMy or MAPxx).
  682. V       Version of DOOM needed to use this object:
  683.           no mark indicates all versions have this object
  684. r         requires registered DOOM or DOOM 2
  685. 2         requires DOOM 2
  686. Spr     The sprite name associated with this thing. This is the first
  687.           four letters of the lumps that are pictures of this thing.
  688. seq.    The sequence of frames displayed. "-" means it displays nothing.
  689.           Unanimated things will have just an "a" here, e.g. a backpack's
  690.           only picture can be found in the wad under BPAKA0. Animated
  691.           things will show the order that their frames are displayed
  692.           (they cycle back after the last one). So the blue key
  693.           alternates between BKEYA0 and BKEYB0. The soulsphere uses
  694.           SOULA0-SOULB0-C0-D0-C0-B0 then repeats. Thing 15, a dead
  695.           player, is PLAYN0.
  696. +       Monsters and players and barrels. They can be hurt, and they
  697.           have a more complicated sprite arrangement. See chapter [5].
  698. CAPITAL Monsters, counts toward the KILL ratio at the end of a level.
  699. #       An obstacle, players and monsters can't move through it.
  700. ^       Hangs from the ceiling, or floats (if a monster).
  701. $       A regular item that players may get.
  702. !       An artifact item; counts toward the ITEM ratio at level's end.
  703.           Note that 2025, the radiation suit, was an ITEM in version
  704.           1.2, but it is not an ITEM in version 1.666 on. Also note
  705.           that 2022 and 2024, invulnerability and invisibility, do not
  706.           respawn in -altdeath games.
  707.  
  708. Dec. Hex  V Spr  seq.     Thing is:
  709.  
  710.   -1 ffff   ---- -        (nothing)
  711.    0 0000   ---- -        (nothing)
  712.    1 0001   PLAY +        Player 1 start (Player 1 start needed on ALL
  713. levels)
  714.    2 0002   PLAY +        Player 2 start (Player starts 2-4 are needed in)
  715.    3 0003   PLAY +        Player 3 start (cooperative mode multiplayer games)
  716.    4 0004   PLAY +        Player 4 start
  717.   11 000b   ---- -        Deathmatch start positions. Should have >= 4/level
  718.   14 000e   ---- -        Teleport landing. Where players/monsters land when
  719.   14                        they teleport to the SECTOR containing this thing
  720.  
  721. 3004 0bbc   POSS +      # FORMER HUMAN: regular pistol-shooting zombieman
  722.   84 0054 2 SSWV +      # WOLFENSTEIN SS: guest appearance by Wolf3D blue guy
  723.    9 0009   SPOS +      # FORMER HUMAN SERGEANT: black armor, shotgunners
  724.   65 0041 2 CPOS +      # HEAVY WEAPON DUDE: red armor, chaingunners
  725. 3001 0bb9   TROO +      # IMP: brown, hurl fireballs
  726. 3002 0bba   SARG +      # DEMON: pink, muscular bull-like chewers
  727.   58 003a   SARG +      # SPECTRE: invisible version of the DEMON
  728. 3006 0bbe r SKUL +     ^# LOST SOUL: flying flaming skulls, they really bite
  729. 3005 0bbd r HEAD +     ^# CACODEMON: red one-eyed floating heads. Behold...
  730.   69 0045 2 BOS2 +      # HELL KNIGHT: grey-not-pink BARON, weaker
  731. 3003 0bbb   BOSS +      # BARON OF HELL: cloven hooved minotaur boss
  732.   68 0044 2 BSPI +      # ARACHNOTRON: baby SPIDER, shoots green plasma
  733.   71 0047 2 PAIN +     ^# PAIN ELEMENTAL: shoots LOST SOULS, deserves its
  734. name
  735.   66 0042 2 SKEL +      # REVENANT: Fast skeletal dude shoots homing missles
  736.   67 0043 2 FATT +      # MANCUBUS: Big, slow brown guy shoots barrage of
  737. fire
  738.   64 0040 2 VILE +      # ARCH-VILE: Super-fire attack, ressurects the dead!
  739.    7 0007 r SPID +      # SPIDER MASTERMIND: giant walking brain boss
  740.   16 0010 r CYBR +      # CYBER-DEMON: robo-boss, rocket launcher
  741.  
  742.   88 0058 2 BBRN +      # BOSS BRAIN: Horrifying visage of the ultimate demon
  743.   89 0059 2 -    -        Boss Shooter: Shoots spinning skull-blocks
  744.   87 0057 2 -    -        Spawn Spot: Where Todd McFarlane's guys appear
  745.  
  746. 2005 07d5   CSAW a      $ Chainsaw
  747. 2001 07d1   SHOT a      $ Shotgun
  748.   82 0052 2 SGN2 a      $ Double-barreled shotgun
  749. 2002 07d2   MGUN a      $ Chaingun, gatling gun, mini-gun, whatever
  750. 2003 07d3   LAUN a      $ Rocket launcher
  751. 2004 07d4 r PLAS a      $ Plasma gun
  752. 2006 07d6 r BFUG a      $ Bfg9000
  753. 2007 07d7   CLIP a      $ Ammo clip
  754. 2008 07d8   SHEL a      $ Shotgun shells
  755. 2010 07da   ROCK a      $ A rocket
  756. 2047 07ff r CELL a      $ Cell charge
  757. 2048 0800   AMMO a      $ Box of Ammo
  758. 2049 0801   SBOX a      $ Box of Shells
  759. 2046 07fe   BROK a      $ Box of Rockets
  760.   17 0011 r CELP a      $ Cell charge pack
  761.    8 0008   BPAK a      $ Backpack: doubles maximum ammo capacities
  762.  
  763. 2011 07db   STIM a      $ Stimpak
  764. 2012 07dc   MEDI a      $ Medikit
  765. 2014 07de   BON1 abcdcb ! Health Potion +1% health
  766. 2015 07df   BON2 abcdcb ! Spirit Armor +1% armor
  767. 2018 07e2   ARM1 ab     $ Green armor 100%
  768. 2019 07e3   ARM2 ab     $ Blue armor 200%
  769.   83 0053 2 MEGA abcd   ! Megasphere: 200% health, 200% armor
  770. 2013 07dd   SOUL abcdcb ! Soulsphere, Supercharge, +100% health
  771. 2022 07e6 r PINV abcd   ! Invulnerability
  772. 2023 07e7 r PSTR a      ! Berserk Strength and 100% health
  773. 2024 07e8   PINS abcd   ! Invisibility
  774. 2025 07e9   SUIT a     (!)Radiation suit - see notes on ! above
  775. 2026 07ea   PMAP abcdcb ! Computer map
  776. 2045 07fd   PVIS ab     ! Lite Amplification goggles
  777.  
  778.    5 0005   BKEY ab     $ Blue keycard
  779.   40 0028 r BSKU ab     $ Blue skullkey
  780.   13 000d   RKEY ab     $ Red keycard
  781.   38 0026 r RSKU ab     $ Red skullkey
  782.    6 0006   YKEY ab     $ Yellow keycard
  783.   39 0027 r YSKU ab     $ Yellow skullkey
  784.  
  785. 2035 07f3   BAR1 ab+    # Barrel; not an obstacle after blown up 
  786.                             (BEXP sprite)
  787.   72 0048 2 KEEN a+     # A guest appearance by Billy
  788.  
  789.   48 0030   ELEC a      # Tall, techno pillar
  790.   30 001e r COL1 a      # Tall green pillar
  791.   32 0020 r COL3 a      # Tall red pillar
  792.   31 001f r COL2 a      # Short green pillar
  793.   36 0024 r COL5 ab     # Short green pillar with beating heart
  794.   33 0021 r COL4 a      # Short red pillar
  795.   37 0025 r COL6 a      # Short red pillar with skull
  796.   47 002f r SMIT a      # Stalagmite: small brown pointy stump
  797.   43 002b r TRE1 a      # Burnt tree: gray tree
  798.   54 0036 r TRE2 a      # Large brown tree
  799.  
  800. 2028 07ec   COLU a      # Floor lamp
  801.   85 0055 2 TLMP abcd   # Tall techno floor lamp
  802.   86 0056 2 TLP2 abcd   # Short techno floor lamp
  803.   34 0022   CAND a        Candle
  804.   35 0023   CBRA a      # Candelabra
  805.   44 002c r TBLU abcd   # Tall blue firestick
  806.   45 002d r TGRE abcd   # Tall green firestick
  807.   46 002e   TRED abcd   # Tall red firestick
  808.   55 0037 r SMBT abcd   # Short blue firestick
  809.   56 0038 r SMGT abcd   # Short green firestick
  810.   57 0039 r SMRT abcd   # Short red firestick
  811.   70 0046 2 FCAN abc    # Burning barrel
  812.  
  813.   41 0029 r CEYE abcb   # Evil Eye: floating eye in symbol, over candle
  814.   42 002a r FSKU abc    # Floating Skull: flaming skull-rock
  815.  
  816.   49 0031 r GOR1 abcb  ^# Hanging victim, twitching
  817.   63 003f r GOR1 abcb  ^  Hanging victim, twitching
  818.   50 0032 r GOR2 a     ^# Hanging victim, arms out
  819.   59 003b r GOR2 a     ^  Hanging victim, arms out
  820.   52 0034 r GOR4 a     ^# Hanging pair of legs
  821.   60 003c r GOR4 a     ^  Hanging pair of legs
  822.   51 0033 r GOR3 a     ^# Hanging victim, 1-legged
  823.   61 003d r GOR3 a     ^  Hanging victim, 1-legged
  824.   53 0035 r GOR5 a     ^# Hanging leg
  825.   62 003e r GOR5 a     ^  Hanging leg
  826.   73 0049 2 HDB1 a     ^# Hanging victim, guts removed
  827.   74 004a 2 HDB2 a     ^# Hanging victim, guts and brain removed
  828.   75 004b 2 HDB3 a     ^# Hanging torso, looking down
  829.   76 004c 2 HDB4 a     ^# Hanging torso, open skull
  830.   77 004d 2 HDB5 a     ^# Hanging torso, looking up
  831.   78 004e 2 HDB6 a     ^# Hanging torso, brain removed
  832.  
  833.   25 0019 r POL1 a      # Impaled human
  834.   26 001a r POL6 ab     # Twitching impaled human
  835.   27 001b r POL4 a      # Skull on a pole
  836.   28 001c r POL2 a      # 5 skulls shish kebob
  837.   29 001d r POL3 ab     # Pile of skulls and candles
  838.   10 000a   PLAY w        Bloody mess (an exploded player)
  839.   12 000c   PLAY w        Bloody mess, this thing is exactly the same as 10
  840.   24 0018   POL5 a        Pool of blood and flesh
  841.   79 004f 2 POB1 a        Pool of blood
  842.   80 0050 2 POB2 a        Pool of blood
  843.   81 0051 2 BRS1 a        Pool of brains
  844.   15 000f   PLAY n        Dead player
  845.   18 0012   POSS l        Dead former human
  846.   19 0013   SPOS l        Dead former sergeant
  847.   20 0014   TROO m        Dead imp
  848.   21 0015   SARG n        Dead demon
  849.   22 0016 r HEAD l        Dead cacodemon
  850.   23 0017 r SKUL k        Dead lost soul, invisible
  851.                               (they blow up when killed)
  852.  
  853.  
  854. [4-2-2]: Thing Sizes
  855. --------------------
  856.  
  857.   The list below gives the radius, height, mass, speed, and toughness
  858. of all the monsters in DOOM 1 and 2. Almost all non-monster things only
  859. differ in their "radius", dependent on whether they are obstacles or not.
  860. For collision purposes, things are NOT circular. They occupy a square
  861. whose side equals slightly more than 2 times the radius. This square
  862. does not turn, it is always aligned with the x and y axes of a level.
  863. Consider a simple collision detection in a coordinate plane:
  864.  
  865.     IF (ABS(x1-x2) =< (r1+r2)) AND (ABS(y1-y2) =< (r1+r2)) THEN *collision*
  866.  
  867.   This will result in square objects centered on their (x,y) positions,
  868. and that is the behavior that DOOM objects exhibit.
  869.   I don't know why the horizontal size is "slightly more" than 2 times
  870. the radius, but it is. A player cannot enter a corridor of width 32, but
  871. can enter a corridor of width 33. Experiments have shown that no monster
  872. can enter a corridor that is exactly (2*radius) wide. It must be bigger.
  873. Moving up to the next multiple of 8 is a good idea, if not 16 or 32.
  874.   Monsters CAN enter sectors that are exactly "Height" high. But obstacles
  875. are infinitely high for collision purposes. A player on a very high ledge
  876. might not be able to jump off, because of an obstacle right next to him,
  877. even though it is far below him.
  878.   Height is also used when under a crushing ceiling, and to determine
  879. if an object can move from one sector to another. The space between the
  880. highest floor and the lowest ceiling must be "Height" or greater for the
  881. object to fit.
  882.   Toughness indicates how much punishment a monster can take until it
  883. dies. Bullets do 10 damage, Shotgun shells 70 (7 pellets, each is 10),
  884. Plasma 20, Rockets 100, and the BFG does 1000 for a direct hit. There's
  885. more info on this stuff in the DOOM FAQ.
  886.  
  887. Dec. Hex  Radius Height Mass Tough Speed  Sprite name or class of things:
  888.  
  889. -    -      16     56    100  (100)    -  PLAY
  890. 3004 0bbc   20     56    100    20     8  POSS
  891.   84 0054   20     56    100    50     8  SSWV
  892.    9 0009   20     56    100    30     8  SPOS
  893.   65 0041   20     56    100    70     8  CPOS
  894. 3001 0bb9   20     56    100    60     8  TROO
  895. 3002 0bba   30     56    400   150    10  SARG 
  896.   58 003a   30     56    400   150    10  SARG (Inviso model)
  897. 3006 0bbe   16     56     50   100     8  SKUL
  898. 3005 0bbd   31     56    400   400     8  HEAD
  899.   69 0045   24     64   1000   500     8  BOS2
  900. 3003 0bbb   24     64   1000  1000     8  BOSS
  901.   68 0044   64     64    600   500    12  BSPI
  902.   71 0047   31     56    400   400     8  PAIN
  903.   66 0042   20     56    500   300    10  SKEL
  904.   67 0043   48     64   1000   600     8  FATT
  905.   64 0040   20     56    500   700    15  VILE
  906.    7 0007  128    100   1000  3000    12  SPID
  907.   16 0010   40    110   1000  4000    16  CYBR
  908.   88 0058   16     16   6666   250     0  BBRN
  909.   72 0048   16     72   6666   100     0  KEEN
  910. 2035 07f3   10     42    100    20     0  BAR1
  911.    -    -   20     16      -     -     -  most non-obstacles (e.g. gettables)
  912.    -    -   16     16      -     -     -  most obstacles
  913.   54 0036   32     16      -     -     -  large brown tree
  914.  
  915.  
  916. [4-2-3]: Thing Options
  917. ----------------------
  918.  
  919.   Short 5 of 5, occupying bytes 8-9 of each thing record, control a
  920. few options, according to which bits are set:
  921.  
  922. bit 0   the THING is present at skill 1 and 2
  923. bit 1   the THING is present at skill 3 (hurt me plenty)
  924. bit 2   the THING is present at skill 4 and 5 (ultra-violence, nightmare)
  925. bit 3   indicates a deaf guard.
  926. bit 4   means the THING only appears in multiplayer mode.
  927.  
  928. bits 5-15 have no effect.
  929.  
  930.   The skill settings are most used with the monsters, of course...the
  931. most common skill level settings are hex 07/0f (on all skills), 06/0e
  932. (on skill 3-4-5), and 04/0c (only on skill 4-5). Unusual skill settings
  933. are perfectly allowable, e.g. hex 05 for a thing which is present on
  934. skill 1, 2, 4, and 5, but not skill 3.
  935.   "deaf guard" only has meaning for monsters, who will not attack until
  936. they see a player if they are deaf. Otherwise, they will activate when
  937. they hear gunshots, etc. (including the punch!). Sound does not travel
  938. through solid walls (walls that are solid at the time of the noise).
  939. Also, lines can be set so that sound does not pass through them (see
  940. [4-3-1] bit 6). This option is also known as the "ambush" option (or
  941. flag, or attribute).
  942.  
  943.  
  944. [4-3]: LINEDEFS
  945. ===============
  946.  
  947.   Each linedef represents a line from one of the VERTEXES to another,
  948. and each linedef's record is 14 bytes, containing 7 <short> fields:
  949.  
  950. (1) from the VERTEX with this number (the first vertex is 0).
  951. (2) to the VERTEX with this number (31 is the 32nd vertex).
  952. (3) flags, see [4-3-1] below.
  953. (4) types, see [4-3-2] below.
  954. (5) is a "tag" or "trigger" number which ties this line's effect type
  955.       to all SECTORS that have the same tag number (in their last
  956.       field).
  957. (6) number of the "right" SIDEDEF for this linedef.
  958. (7) "left" SIDEDEF, if this line adjoins 2 SECTORS. Otherwise, it is
  959.       equal to -1 (FFFF hex).
  960.  
  961.   "right" and "left" are based on the direction of the linedef as
  962. indicated by the "from" and "to", or "start" and "end", VERTEXES.
  963. This sketch should make it clear:
  964.  
  965.              left side               right side
  966.     start -----------------> end <----------------- start
  967.              right side              left side
  968.  
  969.   IMPORTANT: All lines must have a right side. If it is a one-sided
  970. line, then it must go the proper direction, so its single side is
  971. facing the sector it is part of. DOOM will crash on a level that has
  972. a line with no right side.
  973.  
  974.  
  975. [4-3-1]: Linedef Flags
  976. ----------------------
  977.  
  978.   The third <short> field of each linedef controls some attributes of
  979. that line. These attributes (aka flags) are indicated by bits. If the
  980. bit is set (equal to 1), the condition is true for that line. If the
  981. bit is not set (equal to 0), the condition is not true. Note that the
  982. "unpegged" flags cannot be independently set for the two SIDEDEFs of
  983. a line. Here's a list of the flags, followed by a discussion of each:
  984.  
  985. bit     Condition
  986.  
  987. 0       Impassible
  988. 1       Block Monsters
  989. 2       Two-sided
  990. 3       Upper Unpegged
  991. 4       Lower Unpegged
  992. 5       Secret
  993. 6       Block Sound
  994. 7       Not on Map
  995. 8       Already on Map
  996. 9-15    unused
  997.  
  998.   0 (Impassible) - Players and monsters cannot cross this line. Note that
  999. if there is no sector on the other side, they can't go through the line
  1000. anyway, regardless of the flags.
  1001.  
  1002.   1 (Block Monsters) - Monsters cannot cross this line.
  1003.  
  1004.   2 (Two-sided) - The linedef's two sidedefs can have "-" as a texture,
  1005. which in this case means "transparent". If this flag is not set, the
  1006. sidedefs can't be transparent: if "-" is viewed, it will result in the
  1007. "hall of mirrors" effect. However, a linedef CAN have two non-transparent
  1008. sidedefs, even if this flag is not set, as long as it is between two
  1009. sectors.
  1010.   Another side effect of this flag is that if it is set, then gunfire
  1011. (pistol, shotgun, chaingun) can go through it. If this flag is not set,
  1012. gunfire cannot go through the line. Projectiles (rockets, plasma etc.)
  1013. are not restricted this way. They can go through as long as there's a
  1014. sector on the other side (and the sector heights allow it).
  1015.   Finally, monsters can see through and attack through two-sided lines,
  1016. despite any of the line's other flag settings and textures (once again,
  1017. provided sector heights and the REJECT [4-10] allow it).
  1018.  
  1019.   3 (Upper unpegged) - The upper texture is pasted onto the wall from
  1020. the top down instead of from the bottom up like usual.
  1021.   Upper textures normally have the bottom of the wall texture to be
  1022. drawn lined up with the bottom of the "upper" space in which it is
  1023. to be drawn (sidedef Y offsets then apply [4-4]). This can result
  1024. in the upper texture being misaligned with a neighboring "middle"
  1025. texture. To help solve this problem, common at "windows", this flag
  1026. can be set.
  1027.   If the upper texture is unpegged, it is drawn with the wall texture's
  1028. top row at the ceiling, just like middle and lower textures are usually
  1029. drawn. This can help realign the upper texture with a neighbor.
  1030.  
  1031.   The article TEXTURES, cited in appendix [A-4] gives a great deal
  1032. more explanation on the "unpegged" flags and how to use them.
  1033.  
  1034.   4 (Lower unpegged) - Lower and middle textures are drawn from the
  1035. bottom up, instead of from the top down like usual.
  1036.   This is also commonly used on lower textures under "windows". It is
  1037. also used on doorjambs, because when the door opens, the sector ceiling
  1038. is rising, so the "sides" (the doorjambs), which are middle textures,
  1039. will be drawn from the ever-changing ceiling height down, and thus will
  1040. appear to be "moving". Unpegging them will make them be drawn from the
  1041. floor up, and since the floor height doesn't change when a door opens,
  1042. then will not move.
  1043.   There's one slight difference with lower textures being unpegged -
  1044. they are not necessarily drawn with the bottom of the wall texture placed
  1045. at the bottom of the wall. The height of the facing sector and the height
  1046. of the wall texture are taken into account. So if the sector is 160 high,
  1047. and the wall texture is 128 high, then lower unpegged will cause the 32nd
  1048. row of the wall texture to be at the floor, NOT the 128th row. This of
  1049. course excludes sidedef Y offsets, which are applied AFTER unpegged
  1050. flags do their stuff.
  1051.  
  1052.   5 (Secret) - On the automap, this line appears in red like a normal
  1053. solid wall that has nothing on the other side. This is useful in
  1054. protecting secret doors and such. Note that if the sector on the other
  1055. side of this "secret" line has its floor height HIGHER than the sector
  1056. on the facing side of the secret line, then the map will show the lines
  1057. beyond and thus give up the secret.
  1058.   Also note that this flag has NOTHING to do with the SECRETS ratio on
  1059. inter-level screens. That's done with special sector 9 (see [4-9-1]).
  1060.  
  1061.   6 (Block Sound) - For purposes of monsters hearing sounds and thus
  1062. becoming alerted. Every time a player fires a weapon, the "sound" of
  1063. it travels from sector to sector, alerting all non-deaf monsters in
  1064. each new sector. But the sound will die when it hits a second line
  1065. with this flag. The sound can cross one such line, but not two. All
  1066. possible routes for the sound to take are taken, so it can get to
  1067. some out-of-the-way places. Another thing that blocks sound, instantly,
  1068. is incompatible sector heights. Sound can go from a sector with 0/72
  1069. floor/ceiling heights to one with 64/192, but the sound CANNOT go
  1070. from a 0/128 sector to an adjacent 128/256 sector.
  1071.  
  1072.   7 (Not on Map) - The line is not shown on the automap, even if the
  1073. computer all-map power up is acquired.
  1074.  
  1075.   8 (Already on Map) - When the level is begun, this line is already
  1076. on the automap, even though it hasn't been seen (in the display) yet.
  1077. Normally lines only get mapped once part of the line has been seen in
  1078. the display window.
  1079.  
  1080.   Automap line colors: Red lines indicate the line is one-sided, that
  1081. there is a sector on only one side (or the line is marked secret).
  1082. Brown lines are between two sectors with different floor heights but
  1083. the same ceiling height. Yellow lines are between two sectors with
  1084. different ceiling heights and the same or different floor heights.
  1085. Gray lines are as-yet-unseen lines revealed by the computer all-map.
  1086. Without the all-map, lines between sectors with identical floor and
  1087. ceiling heights don't show up. With it, they are gray.
  1088.  
  1089.  
  1090. [4-3-2]: Linedef Types
  1091. ----------------------
  1092.  
  1093.   The <short> in field 4 of 7 of a linedef can control various special
  1094. effects like doors opening, floors moving, etc. Some of them must be
  1095. activated by "using" them, like switches, and some of them are activated
  1096. when they are walked over. There are a huge number of ways to use these
  1097. effects, but it's all done by using one of a hundred or so line function
  1098. types.
  1099.   The most common way they work is this: a player walks across a line
  1100. or activates (presses the spacebar or the use key) right in front of
  1101. a line. That line has a function type that is non-zero. It also has
  1102. a tag number. Then ALL sectors on the level with the same tag number,
  1103. that are not already engaged in some action, undergo the effects that
  1104. the linedef type number dictates. Note that the tag numbers are NOT the
  1105. sector numbers, nor the linedef numbers. A tag number is in a lindef's
  1106. 5th <short> field, and a sector's last <short> field.
  1107.  
  1108. Explanations of all the abbreviations in the table:
  1109.  
  1110. Val     The value of the linedef "type" field (#4). If you want them
  1111.           in numerical order, use SORT or something.
  1112. *       This line function only works in 1.666 and up
  1113. Class   The category of the effect
  1114. Act     Activation. How the linedef's effect is activated.
  1115. n       does NOT require a tag number (see note 5 below)
  1116. W       walk-over activation
  1117. S       switch ("use" - default config is spacebar)
  1118. G       gunfire (pistol, shotgun, chaingun) cross or hit line
  1119. 1       the line may be activated once only
  1120. R       potentially repeatable activation
  1121. &       affected sectors "locked out" from further changes. See notes 9/10.
  1122. m       Monster actions can activate the line's effect
  1123. Sound   The type of noise made by moving sectors
  1124. Speed   How quickly a floor moves up/down etc.
  1125. Tm      Time - how long it "rests"; doors "rest" when they've gone as 
  1126.           high as they're going to go, lifts "rest" at the bottom, etc.
  1127. Chg     Change - some of them cause a floor texture change and/or special
  1128.           sector change. See note 11 below.
  1129. T       Trigger model, see note 11 below.
  1130. N       Numeric model, see note 11 below.
  1131. X       Floor texture is transferred, and Sector type 0.
  1132. P       Special Sector types 4, 5, 7, 9, 11, 16 transfer.
  1133. Effect  What happens to the affected sector(s).
  1134. open    The ceiling goes (up) to LEC-4.
  1135. close   The ceiling goes (down) to the floor level.
  1136. up      Will move up at specified speed if the destination is above.
  1137.           If the destination is below, it arrives there instantly.
  1138. down    Will move down at specified speed if the destination is below.
  1139.           If the destination is above, it arrives there instantly.
  1140. open/   The door can be activated while moving. If it's open or opening,
  1141.   close   it closes. If it's closed or closing, it opens, then pauses,
  1142.           then closes.
  1143. open,   The door can only be activated if it is in the closed state.
  1144.   close   It opens, pauses, then closes.
  1145. lift    The floor goes down to LIF, rests, then back up to original height.
  1146. L       lowest
  1147. H       highest
  1148. C       ceiling
  1149. F       floor
  1150. E       adjacent sectors, excluding the affected sector
  1151. I       adjacent sectors, including the affected sector
  1152. nh      next-higher, i.e. LEF that is higher than source.
  1153.  
  1154.   More notes and longer discussions related to these terms:
  1155.  
  1156. 1.  "Adjacent" is any sector that shares a LINEDEF with the tagged sector
  1157. (sectors are adjacent to themselves).
  1158. 2.  All S activations and the teleporters only work from the RIGHT side
  1159. of the linedef.
  1160. 3.  For teleporters, if more than 1 sector is tagged the same and each
  1161. has a teleport landing THING, then the lowest numbered sector is the
  1162. destination.
  1163. 4.  Floors that raise up an absolute height (up 24, 32) will go up INTO
  1164. ceilings, so using the WR and SR types of these in levels is unwise.
  1165. 5.  A few of the linedef types don't require tag numbers: the end-level
  1166. switches, the scrolling wall type 48 (0x30), and the "manual" doors which
  1167. operate on the sector facing the left side of the linedef with the manual
  1168. door line type.
  1169. 666.  Here's the terms id uses for different types of activations:
  1170.         Manual: nSR and nS1 doors
  1171.         Trigger: W1
  1172.         Retrigger: WR
  1173.         Switch: S1
  1174.         Button: SR
  1175.         Impact: G
  1176.         Effect: line 48 is the only one
  1177. 7.  The "moving floors" go up to a maximum of HIF and go down to a minimum
  1178. of LIF. Why they sometimes go up first and sometimes down is still a
  1179. mystery to me.
  1180. 8.  The "crushing ceilings" go from their original ceiling height down
  1181. to (floor + 8), then back up. While crushing a creature, their downward
  1182. speed slows considerably. "Fast hurt" does about 120% total damage per
  1183. crush, and "slow hurt" grabs you and does somewhere around 1000-2000%
  1184. total damage per crush.
  1185. 9.  The & symbol indicates that a sector cannot be affected any more by
  1186. other line types after it has performed this effect, even if it has
  1187. finished. These are the floor-texture-changers and... (keep reading)
  1188. 10. Moving floors and crushing ceilings also "lock out" further changes
  1189. to the sectors affected, EXCEPT for restarting the moving floor or
  1190. crushing ceiling. If a line triggers a type 6 crushing ceiling in a
  1191. sector, then it is stopped, then ANY other line with a "crush" type that
  1192. is tagged to the same sector will cause the type 6 crusher to start
  1193. again, with its original maximum and minimum ceiling heights.
  1194. 11. Some line types cause floor textures and/or some special sector types
  1195. (see [4-9-1]) to transfer to the tagged sector. The tagged sectors' floor
  1196. and/or special sector (SS) type will change to match that of the "model"
  1197. sector. The TRIGGER model gets the info from the sector that the
  1198. activating line's right side faces. The NUMERIC model gets the info
  1199. from the sector on the other side of the lowest numbered two-sided
  1200. linedef that has one side in the tagged sector.
  1201.   All of these "change" line types transfer the floor texture. Also,
  1202. they all can pass a special sector trait of "0" or "nothing", i.e. if
  1203. the destination is an acid-floor or "damaging" sector, then any of these
  1204. lines can erase the damaging effect. Lines 59, 93, 37, 84, and 9 (see
  1205. note 12 for more specifics on line type 9) also have the ability to 
  1206. transfer the "secret" trait of SS 9, and the damaging traits of SS 
  1207. 4, 5, 7, 11, and 16. None of the "blinking light" effects of SSs can be
  1208. transferred. SS 4 "blinks" and causes damage, but only the damaging part
  1209. can be transferred. SS 11 also turns off god-mode and causes a level END
  1210. when health <11%, this characteristic is part of SS 11, and cannot be
  1211. isolated via fancy transfers.
  1212. 12. Line type 9 is a special one. The definitive example is the chainsaw
  1213. pillar on E1M2. Take the lowest-numbered linedef that has a sidedef in
  1214. the tagged sector. If that linedef is one-sided, nothing happens. If it
  1215. is 2-sided, then the tagged sector's floor will move down to match the
  1216. 2nd sector's floor height (or it will jump instantly up if it was below,
  1217. like other floors that are supposed to move "down").
  1218.   If this 2nd sector CONTAINS the tagged sector, i.e. all the linedefs
  1219. with a sidedef in the tagged sector have their other sidedef in the 2nd
  1220. sector, then this 2nd sector is the "donut". This donut's floor will
  1221. move "up" to match the floor height of the sector on the other side of
  1222. the DONUT's lowest-numbered linedef, excluding those linedefs that are
  1223. shared with the "donut hole" central sector. Also, the donut will undergo
  1224. a floor texture change and special sector type change to match the
  1225. "outside". The donut sector does not have to be completely surrounded
  1226. by another sector (i.e. it can have 1-sided linedefs), but if its
  1227. lowest-numbered linedef is not 2-sided, a minor glitch results: the donut
  1228. and the donut-hole both move to a strange height, and the donut changes
  1229. floor texture to TLITE6_6 - the last flat in the directory.
  1230.   Note that if the donut hole and the donut are both going to move, the
  1231. donut hole is going to move to match the height that the donut is "going
  1232. to". In other words, the whole thing will be at a single height when
  1233. they're done, and this is the height of the "outside" sector that borders
  1234. the donut.
  1235.   Whew!
  1236. 13. Line types 30 and 96, "up ShortestLowerTexture" means that affected
  1237. sector(s) floors go up a number of units equal to the height of the
  1238. shortest "lower" texture facing out from the sector(s).
  1239. 14. STAIRS. Any sector tagged to a stair-raiser line will go up 8. Now
  1240. find the lowest-numbered 2-sided linedef whose RIGHT side faces this
  1241. sector (the first step). The sector on the other side of the lindedef
  1242. becomes the next step, and its floor height changes to be 8 above the
  1243. previous step (it raises up if it was lower, or it changes instantly if
  1244. it was higher). This process continues as long as there are 2-sided
  1245. lines with right sides facing each successive step. A couple things
  1246. will stop the stairway:
  1247.     (a) no 2-sided linedef whose right side faces the current step
  1248.     (b) a sector with a different floor texture
  1249.     (c) a sector that has already been moved by this stairway (this stops
  1250.           ouroboros stairways that circle around to repeat themselves)
  1251.     (d) "locked-out" sectors that can't change their floor height anymore
  1252.   The component steps of a stairway can have any shape or size.
  1253.   The turbo stairs (100, 127) work just like regular stairs except that
  1254. each step goes up 16 not 8, and rising steps can crush things between
  1255. themselves and the ceiling.
  1256. 15. Line types 78 and 85 do NOTHING as of version 1.666.
  1257.  
  1258.  
  1259.  
  1260. Val   Class Act  Sound Speed Tm Chg Effect
  1261.  
  1262. SPECIAL (Continuous effect, doesn't need triggereing)
  1263.  
  1264.  48   Spec  n--  -     -     -  -   Scrolling wall
  1265.  
  1266. LOCAL DOORS ("MANUAL" DOORS)
  1267.  
  1268.   1   mDoor nSRm door  med   4  -   open/close
  1269.  26   mDoor nSR  door  med   4  -   open/close BLUE KEY
  1270.  28   mDoor nSR  door  med   4  -   open/close RED KEY
  1271.  27   mDoor nSR  door  med   4  -   open/close YELLOW KEY
  1272.  31   mDoor nS1  door  med   -  -   open
  1273.  32   mDoor nS1  door  med   -  -   open BLUE KEY
  1274.  33   mDoor nS1  door  med   -  -   open RED KEY
  1275.  34   mDoor nS1  door  med   -  -   open YELLOW KEY
  1276.  46   mDoor nGR  door  med   -  -   open
  1277. 117 * mDoor nSR  blaze turbo 4  -   open/close
  1278. 118 * mDoor nS1  blaze turbo -  -   open
  1279.  
  1280. REMOTE DOORS
  1281.  
  1282.   4   rDoor  W1  door  med   4  -   open,close
  1283.  29   rDoor  S1  door  med   4  -   open,close
  1284.  90   rDoor  WR  door  med   4  -   open,close
  1285.  63   rDoor  SR  door  med   4  -   open,close
  1286.   2   rDoor  W1  door  med   -  -   open
  1287. 103   rDoor  S1  door  med   -  -   open
  1288.  86   rDoor  WR  door  med   -  -   open
  1289.  61   rDoor  SR  door  med   -  -   open
  1290.   3   rDoor  W1  door  med   -  -   close
  1291.  50   rDoor  S1  door  med   -  -   close
  1292.  75   rDoor  WR  door  med   -  -   close
  1293.  42   rDoor  SR  door  med   -  -   close
  1294.  16   rDoor  W1  door  med   30 -   close, then opens
  1295.  76   rDoor  WR  door  med   30 -   close, then opens
  1296. 108 * rDoor  W1  blaze turbo 4  -   open,close
  1297. 111 * rDoor  WR  blaze turbo 4  -   open,close
  1298. 105 * rDoor  S1  blaze turbo 4  -   open,close
  1299. 114 * rDoor  SR  blaze turbo 4  -   open,close
  1300. 109 * rDoor  W1  blaze turbo -  -   open
  1301. 112 * rDoor  S1  blaze turbo -  -   open
  1302. 106 * rDoor  WR  blaze turbo -  -   open
  1303. 115 * rDoor  SR  blaze turbo -  -   open
  1304. 110 * rDoor  W1  blaze turbo -  -   close
  1305. 113 * rDoor  S1  blaze turbo -  -   close
  1306. 107 * rDoor  WR  blaze turbo -  -   close
  1307. 116 * rDoor  SR  blaze turbo -  -   close
  1308. 133 * rDoor  S1  blaze turbo -  -   open BLUE KEY
  1309.  99 * rDoor  SR  blaze turbo -  -   open BLUE KEY
  1310. 135 * rDoor  S1  blaze turbo -  -   open RED KEY
  1311. 134 * rDoor  SR  blaze turbo -  -   open RED KEY
  1312. 137 * rDoor  S1  blaze turbo -  -   open YELLOW KEY
  1313. 136 * rDoor  SR  blaze turbo -  -   open YELLOW KEY
  1314.  
  1315. CEILINGS
  1316.  
  1317.  40   Ceil   W1  mover slow  -  -   up to HEC
  1318.  41   Ceil   S1  mover slow  -  -   down to floor
  1319.  43   Ceil   SR  mover slow  -  -   down to floor
  1320.  44   Ceil   W1  mover slow  -  -   down to floor + 8
  1321.  49   Ceil   S1  mover slow  -  -   down to floor + 8
  1322.  72   Ceil   WR  mover slow  -  -   down to floor + 8
  1323.  
  1324. LIFTS
  1325.  
  1326.  10   Lift   W1  lift  fast  3  -   lift
  1327.  21   Lift   S1  lift  fast  3  -   lift
  1328.  88   Lift   WRm lift  fast  3  -   lift
  1329.  62   Lift   SR  lift  fast  3  -   lift
  1330. 121 * Lift   W1  lift  turbo 3  -   lift
  1331. 122 * Lift   S1  lift  turbo 3  -   lift
  1332. 120 * Lift   WR  lift  turbo 3  -   lift
  1333. 123 * Lift   SR  lift  turbo 3  -   lift
  1334.  
  1335. FLOORS
  1336.  
  1337. 119 * Floor  W1  mover slow  -  -   up to nhEF
  1338. 128 * Floor  WR  mover slow  -  -   up to nhEF
  1339.  18   Floor  S1  mover slow  -  -   up to nhEF
  1340.  69   Floor  SR  mover slow  -  -   up to nhEF
  1341.  22   Floor  W1& mover slow  -  TX  up to nhEF
  1342.  95   Floor  WR& mover slow  -  TX  up to nhEF
  1343.  20   Floor  S1& mover slow  -  TX  up to nhEF
  1344.  68   Floor  SR& mover slow  -  TX  up to nhEF
  1345.  47   Floor  G1& mover slow  -  TX  up to nhEF
  1346.   5   Floor  W1  mover slow  -  -   up to LIC
  1347.  91   Floor  WR  mover slow  -  -   up to LIC
  1348. 101   Floor  S1  mover slow  -  -   up to LIC
  1349.  64   Floor  SR  mover slow  -  -   up to LIC
  1350.  24   Floor  G1  mover slow  -  -   up to LIC
  1351. 130 * Floor  W1  mover turbo -  -   up to nhEF
  1352. 131 * Floor  S1  mover turbo -  -   up to nhEF
  1353. 129 * Floor  WR  mover turbo -  -   up to nhEF
  1354. 132 * Floor  SR  mover turbo -  -   up to nhEF
  1355.  56   Floor  W1& mover slow  -  -   up to LIC - 8, CRUSH
  1356.  94   Floor  WR& mover slow  -  -   up to LIC - 8, CRUSH
  1357.  55   Floor  S1  mover slow  -  -   up to LIC - 8, CRUSH
  1358.  65   Floor  SR  mover slow  -  -   up to LIC - 8, CRUSH
  1359.  58   Floor  W1  mover slow  -  -   up 24
  1360.  92   Floor  WR  mover slow  -  -   up 24
  1361.  15   Floor  S1& mover slow  -  TX  up 24
  1362.  66   Floor  SR& mover slow  -  TX  up 24
  1363.  59   Floor  W1& mover slow  -  TXP up 24
  1364.  93   Floor  WR& mover slow  -  TXP up 24
  1365.  14   Floor  S1& mover slow  -  TX  up 32
  1366.  67   Floor  SR& mover slow  -  TX  up 32
  1367. 140 * Floor  S1  mover med   -  -   up 512
  1368.  30   Floor  W1  mover slow  -  -   up ShortestLowerTexture
  1369.  96   Floor  WR  mover slow  -  -   up ShortestLowerTexture
  1370.  38   Floor  W1  mover slow  -  -   down to LEF
  1371.  23   Floor  S1  mover slow  -  -   down to LEF
  1372.  82   Floor  WR  mover slow  -  -   down to LEF
  1373.  60   Floor  SR  mover slow  -  -   down to LEF
  1374.  37   Floor  W1  mover slow  -  NXP down to LEF
  1375.  84   Floor  WR  mover slow  -  NXP down to LEF
  1376.  19   Floor  W1  mover slow  -  -   down to HEF
  1377. 102   Floor  S1  mover slow  -  -   down to HEF
  1378.  83   Floor  WR  mover slow  -  -   down to HEF
  1379.  45   Floor  SR  mover slow  -  -   down to HEF
  1380.  36   Floor  W1  mover fast  -  -   down to HEF + 8
  1381.  71   Floor  S1  mover fast  -  -   down to HEF + 8
  1382.  98   Floor  WR  mover fast  -  -   down to HEF + 8
  1383.  70   Floor  SR  mover fast  -  -   down to HEF + 8
  1384.   9   Floor  S1  mover slow  -  NXP donut (see note 12 above)
  1385.  
  1386. STAIRS
  1387.  
  1388.   8   Stair  W1  mover slow  -  -   stairs
  1389.   7   Stair  S1  mover slow  -  -   stairs
  1390. 100 * Stair  W1  mover turbo -  -   stairs (each up 16 not 8) + crush
  1391. 127 * Stair  S1  mover turbo -  -   stairs (each up 16 not 8) + crush
  1392.  
  1393. MOVING FLOORS
  1394.  
  1395.  53   MvFlr  W1& lift  slow  3  -   start moving floor
  1396.  54   MvFlr  W1& -     -     -  -   stop moving floor
  1397.  87   MvFlr  WR& lift  slow  3  -   start moving floor
  1398.  89   MvFlr  WR& -     -     -  -   stop moving floor
  1399.  
  1400. CRUSHING CEILINGS
  1401.  
  1402.   6   Crush  W1& crush med   0  -   start crushing, fast hurt
  1403.  25   Crush  W1& crush med   0  -   start crushing, slow hurt
  1404.  73   Crush  WR& crush slow  0  -   start crushing, slow hurt
  1405.  77   Crush  WR& crush med   0  -   start crushing, fast hurt
  1406.  57   Crush  W1& -     -     -  -   stop crush
  1407.  74   Crush  WR& -     -     -  -   stop crush
  1408. 141 * Crush  W1& none? slow  0  -   start crushing, slow hurt "Silent"
  1409.  
  1410. EXIT LEVEL
  1411.  
  1412.  11   Exit  nS-  clunk -     -  -   End level, go to next level
  1413.  51   Exit  nS-  clunk -     -  -   End level, go to secret level
  1414.  52   Exit  nW-  clunk -     -  -   End level, go to next level
  1415. 124 * Exit  nW-  clunk -     -  -   End level, go to secret level
  1416.  
  1417. TELEPORT
  1418.  
  1419.  39   Telpt  W1m tport -     -  -   Teleport
  1420.  97   Telpt  WRm tport -     -  -   Teleport
  1421. 125 * Telpt  W1m tport -     -  -   Teleport monsters only
  1422. 126 * Telpt  WRm tport -     -  -   Teleport monsters only
  1423.  
  1424. LIGHT
  1425.  
  1426.  35   Light  W1  -     -     -  -   0
  1427. 104   Light  W1  -     -     -  -   LE (light level)
  1428.  12   Light  W1  -     -     -  -   HE (light level)
  1429.  13   Light  W1  -     -     -  -   255
  1430.  79   Light  WR  -     -     -  -   0
  1431.  80   Light  WR  -     -     -  -   HE (light level)
  1432.  81   Light  WR  -     -     -  -   255
  1433.  17   Light  W1  -     -     -  -   Light blinks (see [4-9-1] type 3)
  1434. 138 * Light  SR  clunk -     -  -   255
  1435. 139 * Light  SR  clunk -     -  -   0
  1436.  
  1437.  
  1438. [4-4]: SIDEDEFS
  1439. ===============
  1440.  
  1441.   A sidedef is a definition of what wall texture(s) to draw along a
  1442. LINEDEF, and a group of sidedefs outline the space of a SECTOR.
  1443.   There will be one sidedef for a line that borders only one sector
  1444. (and it must be the RIGHT side, as noted in [4-3]). It is not 
  1445. necessary to define what the doom player would see from the other 
  1446. side of that line because the doom player can't go there. The doom
  1447. player can only go where there is a sector.
  1448.   Each sidedef's record is 30 bytes, comprising 2 <short> fields, then
  1449. 3 <8-byte string> fields, then a final <short> field:
  1450.  
  1451. (1) X offset for pasting the appropriate wall texture onto the wall's
  1452.         "space": positive offset moves into the texture, so the left
  1453.         portion gets cut off (# of columns off left side = offset).
  1454.         Negative offset moves texture farther right, in the wall's space.
  1455. (2) Y offset: analogous to the X, for vertical.
  1456. (3) "upper" texture name: the part above the juncture with a lower
  1457.         ceiling of an adjacent sector.
  1458. (4) "lower" texture name: the part below a juncture with a higher
  1459.         floored adjacent sector.
  1460. (5) "middle" texture name: the regular part of the wall. Also known as
  1461.         "normal" or "full" texture.
  1462. (6) SECTOR that this sidedef faces or helps to surround.
  1463.  
  1464.   The texture names are from the TEXTURE1/2 resources. The names of
  1465. wall patches in the directory (between P_START and P_END) are not
  1466. directly used, they are referenced through the PNAMES lump.
  1467.   Simple sidedefs have no upper or lower texture, and so they will have
  1468. "-" instead of a texture name. Also, two-sided lines can be transparent,
  1469. in which case "-" means transparent (no texture).
  1470.   If the wall is wider than the texture to be pasted onto it, then the
  1471. texture is tiled horizontally. A 64-wide texture will be pasted at 0,
  1472. 64, 128, etc., unless an X-offset changes this.
  1473.   If the wall is taller than the texture, than the texture is tiled
  1474. vertically, with one very important difference: it starts new tiles
  1475. ONLY at 128, 256, 384, etc. So if the texture is less than 128 high,
  1476. there will be junk filling the undefined areas, and it looks ugly.
  1477. This is sometimes called the "Tutti Frutti" effect.
  1478.  
  1479.   There are some transparent textures which can be used as middle textures
  1480. on 2-sided sidedefs (between sectors). These textures need to be composed
  1481. of a single patch (see [8-4]), and note that on a very tall wall, they
  1482. will NOT be tiled. Only one will be placed, at the spot determined by
  1483. the "lower unpegged" flag being on/off and the sidedef's y offset. And
  1484. if a transparent texture is used as an upper or lower texture, then
  1485. the good old "Tutti Frutti" effect will have its way.
  1486.   Also note that animated wall textures (see [8-4-1]) do NOT animate
  1487. if they are the "middle" texture on a 2-sided line. So much for the
  1488. lava waterfall with the hidden room at its base...hmm, maybe not...
  1489.  
  1490.  
  1491. [4-5]: VERTEXES
  1492. ===============
  1493.  
  1494.   These are the beginning and end points for LINEDEFS and SEGS. Each
  1495. vertice's record is 4 bytes in 2 <short> fields:
  1496.  
  1497. (1) X coordinate
  1498. (2) Y coordinate
  1499.  
  1500.   On the automap within the game, with the grid on (press 'G'), the
  1501. lines are 128 apart (0x80), two lines = 256 (0x100).
  1502.   A note on the coordinates: the coordinate system used for the vertices
  1503. and the heights of the sectors corresponds to pixels, for purposes of
  1504. texture-mapping. So a sector that's 128 high, or a multiple of 128, is
  1505. pretty typical, since many wall textures are 128 pixels high.
  1506.   And yes, the correct spelling of the plural of "vertex" is "vertices".
  1507.  
  1508.  
  1509. [4-6]: SEGS
  1510. ===========
  1511.  
  1512.   The SEGS are stored in a sequential order determined by the SSECTORS,
  1513. which are part of the NODES recursive tree.
  1514.   Each seg is 12 bytes in 6 <short> fields:
  1515.  
  1516. (1) start of seg is VERTEX with this number
  1517. (2) end VERTEX
  1518. (3) angle: 0= east, 16384=north, -16384=south, -32768=west.
  1519.       In hex, it's 0000=east, 4000=north, 8000=west, c000=south.
  1520.       This is also know as BAMS for Binary Angle Measurement.
  1521. (4) LINEDEF that this seg goes along
  1522. (5) direction: 0 if the seg goes the same direction as the linedef it
  1523.       is on, 1 if the seg goes the opposite direction. This is the
  1524.       same as (0 if the seg is on the RIGHT side of the linedef) or
  1525.       (1 if the seg is on the LEFT side of the linedef).
  1526. (6) offset: distance along the linedef to the start of this seg (the
  1527.       vertex in field 1). The offset is in the same direction as the
  1528.       seg. If field 5 is 0, then the distance is from the "start"
  1529.       vertex of the linedef to the "start" vertex of the seg. If field
  1530.       5 is 1, then the offset is from the "end" vertex of the linedef
  1531.       to the "start" vertex of the seg. So if the seg begins at one of
  1532.       the two endpoints of the linedef, this offset will be 0.
  1533.  
  1534.   For diagonal segs, the offset distance can be obtained from the
  1535. formula DISTANCE = SQR((x2 - x1)^2 + (y2 - y1)^2). The angle can be
  1536. calculated from the inverse tangent of the dx and dy in the vertices,
  1537. multiplied to convert PI/2 radians (90 degrees) to 16384. And since
  1538. most arctan functions return a value between -(pi/2) and (pi/2),
  1539. you'll have to do some tweaking based on the sign of (x2-x1), to
  1540. account for segs that go "west".
  1541.  
  1542.  
  1543. [4-7]: SSECTORS
  1544. ===============
  1545.  
  1546.   SSECTOR stands for sub-sector. These divide up all the SECTORS into
  1547. convex polygons. They are then referenced through the NODES resources.
  1548. There will be (number of nodes + 1) ssectors.
  1549.   Each ssector is 4 bytes in 2 <short> fields:
  1550.  
  1551. (1) This many SEGS are in this SSECTOR...
  1552. (2) ...starting with this SEG number
  1553.  
  1554.   The segs in ssector 0 should be segs 0 through x, then ssector 1
  1555. contains segs x+1 through y, ssector 2 containg segs y+1 to z, etc.
  1556.  
  1557.  
  1558. [4-8]: NODES
  1559. ============
  1560.  
  1561.   A detailed explanation of the nodes follows this list of a node's
  1562. structure in the wad file.
  1563.   Each node is 28 bytes in 14 <short> fields:
  1564.  
  1565. (1)  X coordinate of partition line's start
  1566. (2)  Y coordinate of partition line's start
  1567. (3)  DX, change in X to end of partition line
  1568. (4)  DY, change in Y to end of partition line
  1569.  
  1570.   If (1) to (4) equaled 64, 128, -64, -64, the partition line would
  1571. go from (64,128) to (0,64).
  1572.  
  1573. (5)  Y upper bound for right bounding-box.\
  1574. (6)  Y lower bound                         All SEGS in right child of node
  1575. (7)  X lower bound                         must be within this box.
  1576. (8)  X upper bound                        /
  1577. (9)  Y upper bound for left bounding box. \
  1578. (10) Y lower bound                         All SEGS in left child of node
  1579. (11) X lower bound                         must be within this box.
  1580. (12) X upper bound                        /
  1581. (13) a NODE or SSECTOR number for the right child. If bit 15 of this
  1582.        <short> is set, then the rest of the number represents the
  1583.        child SSECTOR. If not, the child is a recursed node.
  1584. (14) a NODE or SSECTOR number for the left child.
  1585.  
  1586.   The NODES lump is by far the most difficult to understand of all the
  1587. data structures in DOOM. A new level won't display right without a valid
  1588. set of precalculated nodes, ssectors, and segs.
  1589.   Here I will explain what the nodes are for, and how they can be
  1590. generated automatically from the set of linedefs, sidedefs, and
  1591. vertices. I am NOT including any code or a pseudo-code algorithm, like
  1592. I do for the BLOCKMAP (appendix [A-3]). This is for reasons of space,
  1593. and more importantly, the fact that I haven't written any such
  1594. algorithm myself. If there's to be some "node code" published here, it
  1595. will have to be donated by someone, well-commented, well-organized, in
  1596. pseudo-code, and 100% effective! So the odds are long against it.
  1597.  
  1598.   The NODES are branches in a binary space partition (BSP) that divides
  1599. up the level and is used to determine which walls are in front of others,
  1600. a process know as hidden-surface removal. The SSECTORS (sub-sectors) and
  1601. SEGS (segments) lumps are necessary parts of the structure.
  1602.   A BSP tree is normally used in 3d space, but DOOM uses a simplified
  1603. 2d version of the scheme. Basically, the idea is to keep dividing the
  1604. map into smaller spaces until each of the smallest spaces contains only
  1605. wall segments which cannot possibly occlude (block from view) other
  1606. walls in its own space. The smallest, undivided spaces will become
  1607. SSECTORS. Each wall segment is part or all of a linedef (and thus a
  1608. straight line), and becomes a SEG. All of the divisions are kept track
  1609. of in a binary tree structure, which is used to greatly speed the
  1610. rendering process (drawing what is seen). How does this binary tree
  1611. lead to faster rendering? I have no idea.
  1612.   Only the SECTORS need to be divided. The parts of the levels that are
  1613. "outside" sectors are ignored. Also, only the walls need to be kept
  1614. track of. The sides of any created ssectors which are not parts of
  1615. linedefs do not become segs.
  1616.   Some sectors do not require any dividing. Consider a square sector.
  1617. All the walls are orthogonal to the floor (the walls are all straight
  1618. up and down), so from any viewpoint inside the square, none of its
  1619. four walls can possibly block the view of any of the others. Now
  1620. imagine a sector shaped like this drawing:
  1621.  
  1622. +--------------.------+   The * is the viewpoint, looking ->, east. The
  1623. |               .     |   diagonal wall marked @ @ can't be seen at all,
  1624. |               /\    |@  and the vertical wall marked @@@ is partially
  1625. |  *->        /   @\  |@  occluded by the other diagonal wall. This sector
  1626. |           /       @\|@  needs to be divided. Suppose the diagonal wall
  1627. +---------/               is extended, as shown by the two dots (..):
  1628.  
  1629. now each of the two resulting sub-sectors are sufficient, because while
  1630. in either one, no wall that is part of that sub-sector blocks any other.
  1631.   In general, being a convex polygon is the goal of a ssector. Convex
  1632. means a line connecting any two points that are inside the polygon will
  1633. be completely contained in the polygon. All triangles and rectangles are
  1634. convex, but not all quadrilaterals. In doom's simple Euclidean space,
  1635. convex also means that all the interior angles of the polygon are less
  1636. than or equal to 180 degrees.
  1637.   Now, an additional complication arises because of the two-sided
  1638. linedef. Its two sides are in different sectors, so they will end up
  1639. in different ssectors too. Thus every two-sided linedef becomes two segs
  1640. (or more), or you could say that every sidedef becomes a seg. Creating
  1641. segs from sidedefs is a good idea, because the seg can then be associated
  1642. with a sector. Two segs that aren't part of the same sector cannot
  1643. possibly be in the same ssector, so further division is required of any
  1644. set of segs that aren't all from the same sector.
  1645.   Whenever a division needs to be made, a SEG is picked, somewhat
  1646. arbitrarily, which along with its imaginary extensions, forms a "knife"
  1647. that divides the remaining space in two (thus binary). This seg is the
  1648. partition line of a node, and the remaining spaces on either side of
  1649. the partition line become the right and left CHILDREN of the node. All
  1650. partition lines have a direction, and the space on the "right" side of
  1651. the partition is the right child of the node; the space on the "left"
  1652. is the left child (there's a cute sketch in [4-3]: LINEDEFS that shows
  1653. how right and left relate to the start and end of a line). Note that if
  1654. there does not exist a seg in the remaining space which can serve as a
  1655. partition line, then there is no need for a further partition, i.e.
  1656. it's a ssector and a "leaf" on the node tree.
  1657.   If the "knife" passes through any lines/segs (but not at vertices),
  1658. they are split at the intersection, with one part going to each child.
  1659. A two-sided linedef, which is two segs, when split results in four segs.
  1660. A two sider that lies along an extension of the partition line has each
  1661. of its two segs go to opposite sides of the partition line. This is the
  1662. eventual fate of ALL segs on two-sided linedefs.
  1663.   As the partition lines are picked and the nodes created, a strict
  1664. ordering must be maintained. The node tree is created from the "top"
  1665. down. After the first division is made, then the left child is divided,
  1666. then its left child, and so on, until a node's child is a ssector. The
  1667. n you move back up the tree one branch, and divide the right child, then
  1668. its left, etc. ALWAYS left first, on the way down.
  1669.   Since there will be splits along the way, there is no way to know
  1670. ahead of time how many nodes and ssectors there will be at the end.
  1671. And the top of the tree, the node that is created first, is given the
  1672. highest number. So as nodes and ssectors are created, they are simply
  1673. numbered in order from 0 on up, and when it's all done (nothing's left
  1674. but ssectors), then ALL the numbers, for nodes and ssectors, are
  1675. reversed. If there's 485 nodes, then 485 becomes 0 and 0 becomes 485.
  1676.   Here is another fabulous drawing which will explain everything.
  1677. + is a vertex, - and | indicate linedefs, the . . indicates an
  1678. extension of a partition line. The <, >, and ^ symbols indicate the
  1679. directions of partition lines. All the space within the drawing is
  1680. actual level space, i.e. sectors.
  1681.  
  1682.       +-----+-------+-------+            0                     (5)
  1683.       |     |       |       |         /     \      ==>       /     \
  1684.       |  e  |^  f   |^  g   |       1         4           (4)       (1)
  1685.       |     |4      |5      |     /   \      / \         /   \      / \
  1686. +---- + . . +-------+-------+    2     3    e   5      (3)   (2)   2  (0)
  1687. |     |           < 0       |   / \   / \      / \     / \   / \      / \
  1688. |  a  |       b             |  a   b c   d    f   g   6   5 4   3    1   0
  1689. |     |^                    |
  1690. | . . |2. . . . . +---------+ The order in which      How the elements are
  1691. |     |           |1 >        the node tree's         numbered when it's
  1692. |  c  |^    d     |           elements get made.      finished.
  1693. |     |3          |           0 = node                (5) = node
  1694. +-----+-----------+           a = ssector             6 = ssector
  1695.  
  1696.   1. Make segs from all the linedefs. There are 5 two-sided lines here.
  1697.   2. Pick the vertex at 0 and go west (left). This is the first 
  1698.        partition line. Note the . . extension line.
  1699.   3. Pick the vertex at 1, going east. The backwards extension . . cuts
  1700.        the line 3>2>, and the unlabeled left edge line. The left edge
  1701.        was one seg, it becomes two. The 3>2> line was two segs, it
  1702.        becomes four. New vertices are created at the intersection
  1703.        points to do this.
  1704.   4. Pick the (newly created) vertex at 2. Now the REMAINING spaces on
  1705.        both sides of the partition line are suitable for ssectors. The
  1706.        left one is first, it becomes a, the right b. Note that ssector
  1707.        a has 3 segs, and ssector b has 5 segs. The . . imaginary lines
  1708.        are NOT segs.
  1709.   5. Back up the tree, and take 1's right branch. Pick 3. Once again, we
  1710.        can make 2 ssectors, c and d, 3 segs each. Back up the tree to 0.
  1711.   6. Pick 4. Now the left side is a ssector, it becomes e. But the right
  1712.        side is not, it needs one more node. Pick 5, make f and g.
  1713.   7. All done, so reverse all the ordination of the nodes and the
  1714.        ssectors. Ssector 0's segs become segs 0-2, ssector 1's segs
  1715.        become segs 3-7, etc. The segs are written sequentially according
  1716.        to the ssector numbering.
  1717.  
  1718.   If we want to create an algorithm to do the nodes automatically, it
  1719. needs to be able to pick partition lines automatically. From studying
  1720. the original maps, it appears that they usually chose a linedef which
  1721. divides the child's space roughly in "half". This is restricted by the
  1722. availability of a seg in a good location, with a good angle. Also, the
  1723. "half" refers to the total number of ssectors in any particular child,
  1724. which we have no way of knowing when we start! Optimization methods are
  1725. probably used, or maybe brute force, trying every candidate seg until
  1726. the "best" one is found.
  1727.   What is the best possible choice for a partition line? Well, there
  1728. are apparently two goals when creating a BSP tree, which are partially
  1729. exclusive. One is to have a balanced tree, i.e. for any node, there are
  1730. about the same total number of sub-nodes on either side of it. The other
  1731. goal is to minimize the number of "splits" necessary, in this case, the
  1732. number of seg splits needed, along with the accompanying new vertices
  1733. and extra segs. Only a very primitive and specially constructed set of
  1734. linedefs could avoid having any splits, so they are inevitable. It's
  1735. just that with some choices of partition lines, there end up being
  1736. fewer splits. For example,
  1737.  
  1738. +--------------+       If a and b are chosen as partition lines,
  1739. |              |       there will be four extra vertices needed,
  1740. +---+      +---+ < A   and this shape becomes five ssectors and
  1741.     |^    ^|           16 segs. If A and B are chosen, however,
  1742. +---+a    b+---+ < B   there are no extra vertices, and only three
  1743. |              |       ssectors and 12 segs.
  1744. +--------------+       
  1745.  
  1746.   I've read that for a "small" number of polygons (less than 1000?),
  1747. which is what we're dealing with in a doom level, one should definitely
  1748. try to minimize splits, and not worry about balancing the tree. I can't
  1749. say for sure, but it does appear that the original levels strive for
  1750. this. Their trees are not totally unbalanced, but there are some parts
  1751. where many successive nodes each have a node and a ssector as children
  1752. (this is unbalanced). And there are a lot of examples to prove that the
  1753. number of extra segs and vertices they create is very low compared to
  1754. what it could be. I think the algorithm that id Software used tried to
  1755. optimize both, but with fewer splits being more important.
  1756.  
  1757.  
  1758. [4-9]: SECTORS
  1759. ==============
  1760.  
  1761.   A SECTOR is a horizontal (east-west and north-south) area of the map
  1762. where a floor height and ceiling height is defined. It can have any
  1763. shape. Any change in floor or ceiling height or texture requires a
  1764. new sector (and therefore separating linedefs and sidedefs). If you
  1765. didn't already know, this is where you find out that DOOM is in many
  1766. respects still a two-dimensional world, because there can only be ONE
  1767. floor height in each sector. No buildings with two floors, one above
  1768. the other, although fairly convincing illusions are possible.
  1769.   Each sector's record is 26 bytes, comprising 2 <short> fields, then
  1770. 2 <8-byte string> fields, then 3 <short> fields:
  1771.  
  1772. (1) Floor is at this height for this sector
  1773. (2) Ceiling height
  1774. (3) name of the flat used for the floor texture, from the directory.
  1775. (4) name of the flat used for the ceiling texture.
  1776.       All the flats in the directory between F_START and F_END work
  1777.       as either floors or ceilings. 
  1778. (5) lightlevel of this sector: 0 = total dark, 255 (0xff) = maximum 
  1779.       light. There are actually only 32 brightnesses possible (see 
  1780.       COLORMAP [8-2]), so 0-7 are the same, ..., 248-255 are the same.
  1781. (6) special sector: see [4-9-1] immediately below.
  1782. (7) a "tag" number corresponding to LINEDEF(s) with the same tag
  1783.       number. When that linedef is activated, something will usually
  1784.       happen to this sector - its floor will rise, the lights will
  1785.       go out, etc. See [4-3-2] for the list of linedef effects.
  1786.  
  1787.  
  1788. [4-9-1]: Special Sector Types
  1789. -----------------------------
  1790.  
  1791.   Bytes 22-23 of each Sector record are a <short> which determines
  1792. some area-effects called special sectors.
  1793.   Light changes are automatic. The brightness level will alternate
  1794. between the light value specified for the special sector, and the lowest
  1795. value amongst adjacent sectors (two sectors are adjacent if a linedef
  1796. has a sidedef facing each sector). If there is no lower light value,
  1797. or no adjacent sectors, then the "blink" sectors will instead alternate
  1798. between 0 light and their own specified light level. The "oscillate"
  1799. special (8) does nothing if there is no lower light level.
  1800.   "blink off" means the light is at the specified level most of the time,
  1801. and changes to the lower value for just a moment. "blink on" means the
  1802. light is usually at the lower value, and changes to the sector's value
  1803. for just a moment. Every "synchronized" blinking sector on the level
  1804. will change at the same time, whereas the unsynchonized blinking sectors
  1805. change independently. "oscillate" means the light level goes smoothly
  1806. from the lower to the higher and back; it takes about 2 seconds to go
  1807. from maximum to minimum and back (255 down to 0 back up to 255).
  1808.   The damaging sector types only affect players, monsters suffer no ill
  1809. effects from them whatsoever. Players will only take damage when they
  1810. are standing on the floor of the damaging sector. "-10/20%" means that
  1811. the player takes 20% damage at the end of every second that they are in
  1812. the sector, except at skill 1, they will take 10% damage. If the player
  1813. has armor, then the damage is split between health and armor.
  1814.  
  1815. Dec Hex Class   Condition or effect
  1816.  
  1817.  0  00  -       Normal, no special characteristic.
  1818.  1  01  Light   random off
  1819.  2  02  Light   blink 0.5 second
  1820.  3  03  Light   blink 1.0 second
  1821.  4  04  Both    -10/20% health AND light blink 0.5 second
  1822.  5  05  Damage  -5/10% health
  1823.  7  07  Damage  -2/5% health
  1824.  8  08  Light   oscillates
  1825.  9  09  Secret  a player must stand in this sector to get credit for
  1826.                   finding this secret. This is for the SECRETS ratio
  1827.                   on inter-level screens.
  1828. 10  0a  Door    30 seconds after level start, ceiling closes like a door.
  1829. 11  0b  End     -10/20% health. If a player's health is lowered to less
  1830.                   than 11% while standing here, then the level ends! Play
  1831.                   proceeds to the next level. If it is a final level
  1832.                   (levels 8 in DOOM 1, level 30 in DOOM 2), the game ends!
  1833. 12  0c  Light   blink 0.5 second, synchronized
  1834. 13  0d  Light   blink 1.0 second, synchronized
  1835. 14  0e  Door    300 seconds after level start, ceiling opens like a door.
  1836. 16  10  Damage  -10/20% health
  1837.  
  1838.   The following value can only be used in versions 1.666 and up, it will
  1839. cause an error and exit to DOS in version 1.2 and earlier:
  1840.  
  1841. 17  11  Light   flickers on and off randomly
  1842.  
  1843.   All other values cause an error and exit to DOS. This includes these
  1844. two values which were developed and are quoted by id as being available,
  1845. but are not actually implemented in DOOM.EXE (as of version 1.666):
  1846.  
  1847.  6  06  -       crushing ceiling
  1848. 15  0f  -       ammo creator
  1849.  
  1850.   What a shame! The "ammo creator" sounds especially interesting!
  1851.  
  1852.  
  1853. [4-10]: REJECT
  1854. ==============
  1855.  
  1856.   The REJECT lump is used to help speed play on large levels. It can
  1857. also be used for some special effects like monsters in plain sight who
  1858. CANNOT attack or see players.
  1859.   The size of a REJECT in bytes is (number of SECTORS ^ 2) / 8, rounded
  1860. up. It is an array of bits, with each bit controlling whether monsters
  1861. in a given sector can detect and/or attack players in another sector.
  1862.   Make a table of sectors vs. sectors, like this:
  1863.  
  1864.          sector that the player is in
  1865.               0  1  2  3  4
  1866.             +---------------
  1867. sector    0 | 0  1  0  0  0
  1868. that      1 | 1  0  1  1  0
  1869. the       2 | 0  1  0  1  0
  1870. monster   3 | 0  1  1  1  0
  1871. is in     4 | 0  0  1  0  0
  1872.  
  1873.   A 1 means the monster cannot become activated by seeing a player, nor
  1874. can it attack the player. A 0 means there is no restriction. All non-
  1875. deaf monsters still become activated by weapon sounds that they hear
  1876. (including the bare fist!). And activated monsters will still pursue
  1877. the player, but they will not attack if their current sector vs. sector
  1878. bit is "1". So a REJECT that's set to all 1s gives a bunch of pacifist
  1879. monsters who will follow the player around and look menacing, but never
  1880. actually attack.
  1881.   How the table turns into the REJECT resource:
  1882.   Reading left-to-right, then top-to-bottom, like a page, the first bit
  1883. in the table becomes bit 0 of byte 0, the 2nd bit is bit 1 of byte 0,
  1884. the 9th bit is bit 0 of byte 1, etc. So if the above table represented
  1885. a level with only 5 sectors, its REJECT would be 4 bytes:
  1886.  
  1887. 10100010 00101001 01000111 xxxxxxx0 (hex A2 29 47 00, decimal 162 41 71 0)
  1888.  
  1889.   In other words, the REJECT is a long string of bits which are read
  1890. from least significant bit to most significant bit, according to the
  1891. lo-hi storage scheme used in a certain "x86" family of CPUs.
  1892.   Usually, if a monster in sector A can't detect a player in sector B,
  1893. then the reverse is true too, thus if sector8/sector5 is set, then
  1894. sector5/sector8 will be set also. Same sector prohibitions, e.g. 0/0,
  1895. 3/3, etc. are only useful for special effects (pacifist monsters), or
  1896. for tiny sectors that monsters can't get to anyway.
  1897.  
  1898.   The REJECT array was designed to speed the monster-detection process.
  1899. If a sector pair is prohibited, the game engine doesn't even bother
  1900. checking line-of-sight feasibility for the monster to "see" the player
  1901. and consider attacking. When a level has hundreds of monsters and
  1902. hundreds of sectors, a good REJECT can prevent the drastic slowdowns
  1903. that might otherwise occur (even fast CPUs can fall victim to this
  1904. phenomenon).
  1905.  
  1906.  
  1907. [4-11]: BLOCKMAP
  1908. ================
  1909.  
  1910.   The BLOCKMAP is a pre-calculated structure that the game engine uses
  1911. to simplify collision-detection between moving things and walls. If a
  1912. level doesn't have a blockmap, it will display fine, but everybody walks
  1913. through walls, and no one can hurt anyone else.
  1914.   A concise definition of the BLOCKMAP is in appendix [A-1]. This is
  1915. the full explanation of it.
  1916.   The whole level is cut into "blocks", each is a 128 (hex 80) wide
  1917. square (the grid lines in the automap correspond to these blocks). The
  1918. BLOCKMAP is a collection of lists, one list for each block, which say
  1919. what LINEDEFS are wholly or partially in that block (i.e. part of the
  1920. line passes through the block). When the game engine needs to check
  1921. for an object/wall collision (to prevent a player from walking through
  1922. a wall or to explode a rocket when it hits a wall, etc.), it just looks
  1923. up the blocklist for the block that the object is in. This tells it
  1924. which linedefs it needs to check for collisions. Most blocks will have
  1925. few if any lines in them, so there will be a substantial savings in
  1926. processor time if it only checks a couple linedefs per object instead
  1927. of a thousand or so linedefs per object - it would have to check every
  1928. single linedef on the level if not for these blocklists.
  1929.   The blocks are also used for object/object collisions, but that is
  1930. not visible in the WAD format. During play, each block is also given a
  1931. dynamic "thing list", which tells what THINGS are currently in that
  1932. block. Again, this negates the need to check every moving object vs.
  1933. every other object for collisions - only a few need be tested.
  1934.   The BLOCKMAP is composed of three parts: the header, the offsets, and
  1935. the blocklists.
  1936.   The 8-byte header contains 4 short integers:
  1937.  
  1938. (1)     X coordinate of block-grid origin
  1939. (2)     Y coordinate of block-grid origin
  1940. (3)     # of columns (blocks in X direction)
  1941. (4)     # of rows (blocks in Y direction)
  1942.  
  1943.   The block-grid origin is the bottom-left corner of the bottom-left
  1944. (southwest) block. id's blockmap builder this origin point at 8 less
  1945. than the minimum values of x and y achieved in any vertex on the level.
  1946.   The number of columns and rows needs to be sufficient to contain
  1947. every linedef in the level. If there are linedefs outside the blockmap,
  1948. it will not be able to prevent monsters or players from crossing those
  1949. linedefs, which can cause problems, including the hall of mirrors effect.
  1950.  
  1951.   There are N blocks, N = (number of columns * number of rows). Each
  1952. block has a blocklist and an offset to that blocklist. Immediately
  1953. following the 8-byte header are N unsigned short integers. The first
  1954. is the offset in short-ints NOT bytes, from the start of the BLOCKMAP
  1955. lump to the start of the first blocklist. The last offset points to
  1956. blocklist (N-1), the last blocklist. Note that all these offsets are
  1957. UNSIGNED, so they can point to a location 65535 shorts (131070 bytes)
  1958. into the BLOCKMAP. If they were signed, they could only go up to 32767.
  1959.   The blocks are numbered going east (right) first, then north (up).
  1960. Block 0 is at the southwest corner (row 0, column 0). Block 1 is at
  1961. row 0, column 1. If there are 37 columns, then block 38 is at row 1,
  1962. column 0, etc.
  1963.  
  1964.   After the offsets come the blocklists. Each blocklist starts with
  1965. a short-int 0 (0x0000) and ends with a short-int -1 (0xffff). In between
  1966. are the numbers of every linedef which has any portion whatsoever in the
  1967. 128 x 128 coordinate area of that block. If the block-grid origin is at
  1968. (0,0), then the first column is X = 0 to 127 inclusive, the second column
  1969. is X = 128 to 255 inclusive, etc. So a vertical line with X = 128 which
  1970. might seem to be on the border of two columns of blocks is actually only
  1971. in the easternmost/rightmost column. Likewise for the rows.
  1972.   The first linedef in the LINEDEFS lump is linedef number 0, and so on.
  1973. An "empty" block's blocklist only has the two shorts 0 and -1. A non-
  1974. empty block might have this as its blocklist: 0 330 331 333 -1. This
  1975. means that linedefs 330, 331, and 333 have some part of them pass through
  1976. this block. A block that has linedef 0 in it will go: 0 0 .. etc .. -1.
  1977.  
  1978.   There is an upper limit to how big a BLOCKMAP can be. Even empty
  1979. blocklists require at least 3 shorts - the 0, the -1, and the offset to
  1980. the blocklist. The offsets are unsigned shorts, which would imply a
  1981. maximum value of short #65535 ( = byte 131070) for the start of the last
  1982. blocklist. At a little over 6 bytes per blocklist, that would be a maximum
  1983. of around 21000 blocks (145 by 145 blocks, 18560 in coordinates). But the
  1984. actual limit is less. Experiments suggest that the maximum total size of
  1985. all the blocklists, not counting the offsets, is 65535 bytes. This limits
  1986. a minimalist level to around 120 blocks square (15360 in coordinates),
  1987. or a realistically complex level to around 100 blocks square (12800 in
  1988. coordinates).
  1989.  
  1990.  
  1991. ---------------------
  1992. CHAPTER [5]: Graphics
  1993. ---------------------
  1994.  
  1995.   The great majority of the entries in the directory reference lumps
  1996. that are in a special picture format. The same format is used for the
  1997. sprites (monsters, items), the wall patches, and various miscellaneous
  1998. pictures for the status bar, menu text, inter-level map, etc. Every
  1999. one of these picture lumps contains exactly one picture. The flats
  2000. (floor and ceiling pictures) are NOT in this format, they are raw data;
  2001. see chapter [6].
  2002.   A great many of these lumps are used in sprites. A "sprite" is the
  2003. picture or pictures necessary to display any of the THINGS. Some of
  2004. them are simple, a single lump like SUITA0. Most of the monsters have
  2005. 50 or more lumps.
  2006.   The first four letters of these lumps are the sprite's "name". TROO
  2007. is for imps, BKEY is for the blue key, and so on. See [4-2-1] for a list
  2008. of them all. The fifth letter in the lump is an indication of what "frame"
  2009. it is, for animation sequences. The letters correspond to numbers, ASCII
  2010. "A" equalling 0, "B" is 1, ... "Z" is 25, etc. The highest needed by a
  2011. DOOM 1 sprite is W=22, but some of the DOOM 2 monsters need a few more
  2012. frames.
  2013.   The "0" in the lump name is for "rotations" or "rot"s. All the
  2014. static objects like torches and barrels and dead bodies look the same
  2015. from any angle. This is because they have a "rot=0 lump" as DOOM itself
  2016. might say. Monsters and projectiles look different from different
  2017. angles. This is done with rots 1-8. This diagram shows how rot 1 is for
  2018. the front and they go counter-clockwise (looking from above) to 8:
  2019.  
  2020.         3
  2021.       4 | 2
  2022.        \|/
  2023.      5--*----> 1   Thing is facing this direction
  2024.        /|\
  2025.       6 | 8
  2026.         7
  2027.  
  2028.   Many things have sets of lumps like this: TROOA1, TROOA2A8, TROOA3A7,
  2029. TROOA4A6, TROOA5, TROOB1, etc. This means that for frame 0 (A), the
  2030. pairs of rots/angles (2 and 8), (3 and 7), and (4 and 6) are mirror-
  2031. images. In the long run, this saves space in the wad file, and from the
  2032. designer's point of view, it's 37% fewer pictures to have to draw.
  2033.   If a sprite's frame has a non-zero rot, it needs to have ALL 8 of
  2034. them. Also note that no more than two rots can be squeezed into one
  2035. lump's name. Some other two-rot lumps with a different format are
  2036. shown in the SPIDA1D1, SPIDA2D2, etc. lumps.
  2037.  
  2038.   IMPORTANT: Sprite lumps and flats cannot be added or replaced via pwads
  2039. unless they ALL are. That is, ALL sprites' lumps must be located in a
  2040. single wad file, and ALL flats' lumps must be in a single wad file. Wall
  2041. patches CAN be used in external wads, because the PNAMES lump gives a
  2042. number to every pname, and is used as a quick-index list to load in
  2043. wall patches.
  2044.   Version 1.666 was rumored to be able to include sprites in pwads (in
  2045. fact the README says it can), but it can't.
  2046.  
  2047.  
  2048. [5-1]: Picture Format
  2049. =====================
  2050.  
  2051.   Each picture has three sections. First, an 8-byte header composed of
  2052. four short-integers. Then a number of long-integer pointers. Then the
  2053. picture's pixel/color data. See [A-1] for concise BNF style definitions,
  2054. here is a meatier explanation of the format:
  2055.  
  2056. (A) The header's four fields are:
  2057.  
  2058.   (1) Width. The number of columns of picture data.
  2059.   (2) Height. The number of rows.
  2060.   (3) Left offset. The number of pixels to the left of the center;
  2061.         where the first column gets drawn.
  2062.   (4) Top offset. The number of pixels above the origin;
  2063.         where the top row is.
  2064.  
  2065.   The width and height define a rectangular space or limits for drawing
  2066. a picture within. To be "centered", (3) is usually about half of the
  2067. total width. If the picture had 30 columns, and (3) was 10, then it
  2068. would be off-center to the right, especially when the player is standing
  2069. right in front of it, looking at it. If a picture has 30 rows, and (4)
  2070. is 60, it will appear to "float" like a blue soul-sphere. If (4) equals
  2071. the number of rows, it will appear to rest on the ground. If (4) is less
  2072. than that for an object, the bottom part of the picture looks awkward.
  2073.   With walls patches, (3) is always (columns/2)-1, and (4) is always
  2074. (rows)-5. This is because the walls are drawn consistently within their
  2075. own space (There are two integers in each SIDEDEF which can offset the
  2076. starting position for drawing a wall's texture within the wall space).
  2077.  
  2078.   Finally, if (3) and (4) are NEGATIVE integers, then they are the
  2079. absolute coordinates from the top-left corner of the screen, to begin
  2080. drawing the picture, assuming the VIEW is full-screen (i.e., the full
  2081. 320x200). This is only done with the picture of the player's current
  2082. weapon - fist, chainsaw, bfg9000, etc. The game engine scales the
  2083. picture down appropriatelyif the view is less than full-screen.
  2084.  
  2085. (B) After the header, there are N = field (1) = <width> = (# of columns)
  2086. 4-byte <long> integers. These are pointers to the data for each COLUMN.
  2087. The value of the pointer represents the offset in bytes from the first
  2088. byte of the picture lump.
  2089.  
  2090. (C) Each column is composed of some number of BYTES (NOT integers),
  2091. arranged in "posts":
  2092.  
  2093.   The first byte is the row to begin drawing this post at. 0 means
  2094. whatever height the header (4) upwards-offset describes, larger numbers
  2095. move correspondingly down.
  2096.   The second byte is how many colored pixels (non-transparent) to draw,
  2097. going downwards.
  2098.   Then follow (# of pixels) + 2 bytes, which define what color each
  2099. pixel is, using the game palette. The first and last bytes AREN'T drawn,
  2100. and I don't know why they are there. Probably just leftovers from the
  2101. creation process on the NeXT machines. Only the middle (# of pixels in
  2102. this post) are drawn, starting at the row specified in the first byte
  2103. of the post.
  2104.   After the last byte of a post, either the column ends, or there is
  2105. another post, which will start as stated above.
  2106.   255 (0xFF) ends the column, so a column that starts this way is a null
  2107. column, all "transparent". Draw the next column.
  2108.  
  2109.  
  2110. -----------------------------------------------
  2111. CHAPTER [6]: Flats (Floor and Ceiling Textures)
  2112. -----------------------------------------------
  2113.  
  2114.   All the lumpnames for flats are in the directory between the F_START
  2115. and F_END entries. Calling them flats is a good way to avoid confusion
  2116. with wall textures. There is no look-up or meta-structure in flats as
  2117. there is in walls textures. Each flat is 4096 raw bytes, making a square
  2118. 64 by 64 pixels. This is pasted onto a floor or ceiling with the same
  2119. orientation as the automap would imply, i.e. the first byte is the color
  2120. at the NW corner, the 64th byte (byte 63, 0x3f) is the NE corner, etc.
  2121.   The blocks in the automap grid are 128 by 128, so four flats will fit
  2122. in each block. Note that there is no way to offset the placement of flats,
  2123. as can be done with wall textures. They are pasted according to grid lines
  2124. 64 apart, reckoned from the coordinate (0,0). This allows flats to flow
  2125. smoothly even across jagged boundaries between sectors with the same
  2126. floor or ceiling height.
  2127.  
  2128.   As discussed in chapter [5], replacement and/or new-name flats don't
  2129. work right from pwad files unless they are all in the same wad.
  2130.   Theoretically, you can change all the flats want by constructing a
  2131. new DOOM.WAD or ALLFLATS.WAD pwad, but you have to make sure no floor
  2132. or ceiling uses an entry name which isn't in your F_ section. And you
  2133. have to include these four entries for DOOM 1 use, although you can
  2134. change their actual contents (pictures): FLOOR4_8, SFLR6_1, MFLR8_4,
  2135. and FLOOR7_2. The first three are needed as backgrounds for the episode 
  2136. end texts. The last is what is shown "outside" the border of the display
  2137. window if the display is not full-screen.
  2138.  
  2139.  
  2140. [6-1]: Animated Flats
  2141. ---------------------
  2142.  
  2143.   See Chapter [8-4-1] for a discussion of how the animated walls and
  2144. flats work. Unfortunately, the fact that the flats all need to be
  2145. lumped together in one wad file means that its not possible to change
  2146. the animations via a pwad file, unless it contains ALL the flats, which
  2147. amounts to several hundred k. Plus it is illegal to distribute the
  2148. original data, so to pass around modifications, either all the flats
  2149. must be all-new, or a utility must be used to construct a FLATS.WAD
  2150. on an end-user's hard drive, using the original DOOM.WAD plus the
  2151. additions. (Note: Bernd Kreimeier, listed in [A-5], has written a
  2152. utility that does just this. It is called DMADDS11).
  2153.  
  2154.  
  2155. -----------------------------
  2156. CHAPTER [7]: Sounds and Music
  2157. -----------------------------
  2158.  
  2159.  
  2160. [7-1]: PC Speaker Sound Effects
  2161. ===============================
  2162.  
  2163.   DP* entries in the directory refer to lumps that are sound data for
  2164. systems using the PC speaker.
  2165.   It's a quick and simple format. First is a <short> that's always 0,
  2166. then a <short> that's the number of bytes of sound data, then follow
  2167. that many bytes worth of sound data. That is, the lump's bytes will be
  2168. 0, 0, N, 0, then N bytes of data. The DP* lumps range in size from around
  2169. 10 bytes to around 150 bytes, and the data seem to range from 0 to 96
  2170. (0x00 to 0x60). The numbers obviously indicate frequency, but beyond
  2171. that I don't know the exact correlation in Hz, nor the time duration
  2172. of each byte worth of data. Feel free to figure this out and tell me.
  2173.  
  2174.  
  2175. [7-2]: Soundcard Sound Effects
  2176. ==============================
  2177.  
  2178.   DS* entries in the directory refer to lumps that are sound data for
  2179. systems using soundcards.
  2180.   This data is in a RAW format for 8-bit 11 KHz mono sound - first is
  2181. an 8-byte header composed of 4 unsigned short integers: 
  2182.  
  2183. (1) 3           (means what?)
  2184. (2) 11025       (the sample rate, samples per second)
  2185. (3) N           (the number of samples)
  2186. (4) 0
  2187.  
  2188.   Each sample is a single byte, since they are 8-bit samples. The
  2189. maximum number of samples is 65535, so at 11 KHz, a little less than
  2190. 6 seconds is the longest possible sound effect.
  2191.  
  2192.  
  2193. [7-3]: Music
  2194. ============
  2195.  
  2196.   D_* entries is the directory refer to lumps that are music. This
  2197. music is in the MUS file format, which goes like this:
  2198.  
  2199. offset  type    contents
  2200.  
  2201. 0       ASCII   "MUS" and CTRL-Z (hex 4d 55 53 1a)
  2202. 4      <short>  # of bytes of music data
  2203. 6      <short>  # of bytes of header data (offset to start of music)
  2204. 8      <short>  number of primary channels
  2205. 10     <short>  number of secondary channels
  2206. 12     <short>  number of instrument patches
  2207. 14     <short>  0
  2208. 16     <short>s instrument patch numbers
  2209. X to end  ?     Music data
  2210.  
  2211.   X is the header size (the second short). Drum patch numbers (greater
  2212. than 128) are 28 less than the numbers listed in the DMXGUS lump.
  2213.   What the exact format of the music data is, I don't know.
  2214.  
  2215.  
  2216. [7-4]: GENMIDI
  2217. ==============
  2218.  
  2219.   This has something to do with General MIDI, obviously. This lump
  2220. has 3 sections: an 8-byte header (the ASCII text "#OPL_II#"), then
  2221. 150 36-byte records (1 for each instrument), then 150 32-byte strings
  2222. (names of instruments, padded with zeros). Perhaps the 36 bytes contain
  2223. waveform information for the General MIDI standard instruments (this
  2224. guess is based on exactly one glance at a dump of the byte values,
  2225. so don't put too much faith in it).
  2226.  
  2227.  
  2228. [7-5]: DMXGUS
  2229. =============
  2230.  
  2231.   This lump is used to do instrument patch mappings on the Gravis
  2232. Ultra-Sound soundcard. It's in a very simple format - ASCII text!
  2233. Here's the start and end of the DMXGUS lump from DOOM 1 version 1.2,
  2234. which is 200 lines, of which the first 10 are comments:
  2235.  
  2236. #Purpose: Different size patch libraries for different memory sizes.
  2237. #         The libraries are built in such a way as to leave 8K+32bytes
  2238. #         after the patches are loaded for digital audio.
  2239. #
  2240. #Revision History: 06/22/93 - Fixed problem with 512K patch library
  2241. #                  07/26/93 - patch names changed in various releases
  2242. #
  2243. #
  2244. #Explanation of Columns: Patch #  256K  512K  768K  1024K  Patch Name
  2245. #
  2246. 0, 2, 1, 1, 1, acpiano
  2247. 1, 2, 1, 1, 1, britepno
  2248. 2, 2, 1, 1, 1, synpiano
  2249. .
  2250. .
  2251. .
  2252. 213, 128, 128, 128, 128, castinet
  2253. 214, 128, 128, 128, 128, surdo1
  2254. 215, 128, 128, 128, 128, surdo2
  2255.  
  2256.  
  2257. --------------------------------
  2258. CHAPTER [8]: Miscellaneous Lumps
  2259. --------------------------------
  2260.  
  2261.  
  2262. [8-1]: PLAYPAL
  2263. ==============
  2264.  
  2265.   There are 14 palettes here, each is 768 bytes = 256 rgb triples.
  2266. That is, the first three bytes of a palette are the red, green, and
  2267. blue portions of color 0. And so on. Note that the values use the
  2268. full range (0..255), while standard VGA digital-analog converters
  2269. use values 0-63.
  2270.   The first palette, palette 0, is used for most situations.
  2271.   Palettes 10-12 are used (briefly) when an item is picked up, the
  2272. more items that are picked up in quick succession, the brighter it
  2273. gets, palette 12 being the brightest.
  2274.   Palette 13 is used while wearing a radiation suit.
  2275.   Palettes 3, 2, then 0 again are used after getting berserk strength.
  2276.   If the player is hurt, then the palette shifts up to number X, then
  2277. comes "down" one every second or so, to palette 2, then palette 0
  2278. (normal) again. What X is depends on how badly the player got hurt:
  2279. Over 100% damage (add health loss and armor loss), X=8. 93%, X=7. 81%,
  2280. X=6. 55%, X=5. 35%, X=4. 16%, X=2. These are just rough estimates
  2281. based on a single test session long ago. Why bother tracking down
  2282. the exact division points?
  2283.  
  2284.   Unknown: what palettes 1 and 9 are for.
  2285.  
  2286.  
  2287. [8-2]: COLORMAP
  2288. ===============
  2289.  
  2290.   This contains 34 sets of 256 bytes, which "map" the colors "down" in
  2291. brightness. Brightness varies from sector to sector. At very low
  2292. brightness, almost all the colors are mapped to black, the darkest gray,
  2293. etc. At the highest brightness levels, most colors are mapped to their
  2294. own values, i.e. they don't change.
  2295.   In each set of 256 bytes, byte 0 will have the number of the palette
  2296. color to which original color 0 gets mapped.
  2297.   The colormaps are numbered 0-33. Colormaps 0-31 are for the different
  2298. brightness levels, 0 being the brightest (light level 248-255), 31 being
  2299. the darkest (light level 0-7). Light level is the fifth field of each
  2300. SECTOR record, see [4-9].
  2301.   Colormap 32 is used for every pixel in the display window (but not
  2302. the status bar), regardless of sector brightness, when the player is
  2303. under the effect of the "Invulnerability" power-up. This colormap is
  2304. all whites and greys.
  2305.   Colormap 33 is all black for some reason.
  2306.   While the light-amplification goggles power-up is in effect, everything
  2307. in the display uses colormap 0, regardless of sector brightness.
  2308.  
  2309.  
  2310. [8-3]: ENDOOM
  2311. =============
  2312.  
  2313.   When you finally have to leave DOOM, you exit to dos, and a colorful
  2314. box of text appears. This is it. It is 4000 bytes, which are simply
  2315. stored in the screen memory area for 80x25 16-color text mode. Thus
  2316. it follows the same format as screen memory does: each character on
  2317. the screen takes up two bytes. The second byte of each pair is from
  2318. the (extended) ASCII character set, while the first byte of each pair
  2319. is the color attribute for that character. The color attribute can
  2320. be explained thus:
  2321.  
  2322.  bit 7    6   5   4   3   2   1   0
  2323.   +-----+---+---+---+---+---+---+---+
  2324.   |     |   .   .   |   .   .   .   |
  2325.   |Blink| Background|  Foreground   |
  2326.   |     |   .   .   |   .   .   .   |
  2327.   +-----+---+---+---+---+---+---+---+
  2328.  
  2329.   So the foreground color can be from 0-15, the background color can
  2330. be from 0-7, and the "blink" attribute is either on or off. All this
  2331. very low-level info can be found in many ancient PC programming books,
  2332. but otherwise it might be hard to locate...
  2333.  
  2334.  
  2335. [8-4]: TEXTURE1 and TEXTURE2
  2336. ============================
  2337.  
  2338.   These are lists of wall texture names used in SIDEDEFS lumps. Each
  2339. wall texture is composed of one or more wall patches, whose names are
  2340. listed in the PNAMES lump. But in a texture, the wall patches are not
  2341. referred to by name, rather by the index number indicating what position
  2342. they occupy in the PNAMES lump.
  2343.   The TEXTURE2 lump is only present in the registered DOOM.WAD. The
  2344. TEXTURE1 lump is identical in DOOM.WAD and the shareware DOOM1.WAD, and
  2345. it only refers to pname numbers up to 163, because the shareware wad
  2346. only has the first 163 wall patches, not all 350.
  2347.  
  2348.   A TEXTURE lump starts with a 4-byte long integer N which is the number
  2349. of textures defined in it. Following it are N long integers which are the
  2350. offsets in bytes from the beginning of the TEXTURE lump to the start of
  2351. each texture's definition.
  2352.   Then there are N texture definitions, which have the following format.
  2353. The first (texture name) field is an 8-byte string (less than 8 byte
  2354. names are padded with zeros), the rest of the fields are 2-byte short
  2355. integers:
  2356.  
  2357. (1) The name of the texture, used in SIDEDEFS, e.g. "FIREWALL".
  2358. (2) always 0.
  2359. (3) always 0.
  2360. (4) total width of texture
  2361. (5) total height of texture
  2362.  
  2363.         The fourth and fifth fields define a "space" (usually 128 by 128
  2364.       or 64 by 72 or etc...) in which individual wall patches are placed
  2365.       to form the overall picture. To tile vertically on a very tall wall
  2366.       without exhibiting the "Tutti Frutti" effect, a texture must have
  2367.       height 128, the maximum. There is no maximum width.
  2368.       
  2369. (6) always 0.
  2370. (7) always 0.
  2371. (8) Number of 5-field (5 <short>) patch descriptors that follow. This
  2372. means that each texture entry has variable length. Many entries have just
  2373. 1 patch, the most used in DOOM in a single texture is 64.
  2374.  
  2375.   Patch descriptor:
  2376.  
  2377.   (a) x offset from top-left corner of texture space defined in fields
  2378.         4 and 5 to start placement of this patch
  2379.   (b) y offset
  2380.   (c) number (0...) of the entry in the PNAMES lump that contains the
  2381.         lump name from the directory, of the wall patch to use...
  2382.   (d) always 1, is for something called "stepdir"...
  2383.   (e) always 0, is for "colormap"...
  2384.  
  2385.   Each texture's entry ends after the last of its patch descriptors.
  2386.   Note that patches can have transparent parts, since they are in the
  2387. same picture format as everything else. Thus there can be (and are)
  2388. transparent wall textures. These should only be used on a border between
  2389. two sectors, to avoid "hall of mirrors" problems.
  2390.   Also, textures intended for use as the "middle" texture of a 2-sided
  2391. SIDEDEF (e.g. transparent textures) should only be composed of a single
  2392. patch. A limitation in the game engine will cause the "medusa" effect
  2393. if there is more than 1 patch in any middle texture that is visible in
  2394. the display window. This effect causes the computer to slow to a crawl
  2395. and make play impossible until the offending wall is out of view.
  2396.  
  2397.  
  2398. [8-4-1]: Animated Walls
  2399. -----------------------
  2400.  
  2401.   Some of the walls and floors are animated. In the case of wall
  2402. textures, it is possible to substantially customize these animations.
  2403. Flats' animations can theoretically also be modified, but since flats
  2404. don't work from pwads, that can make the effort very difficult.
  2405.   The game engine sets up a number of wall animation cycles based on
  2406. what entries it finds in the TEXTURE lumps. It also sets up flat
  2407. animations based on what lumps exist between F_START and F_END.
  2408. Versions before 1.666 can have up to 9 animated walls and 5 animated
  2409. flats. Version 1.666 (DOOM 1 or 2) can have 13 walls and 9 floors
  2410. animate.
  2411.   For wall animations, the entries in the columns "First" and "Last"
  2412. below, and all the entries between them (in the order that they occur
  2413. in the TEXTURE lump) are linked. If one of them is listed as a texture
  2414. on a sidedef, that sidedef will change texture to the next in the cycle
  2415. about 3 times a second, going back to <First> after <Last>. Flats work
  2416. similarly, except the order is dictated by the wad directory. If both
  2417. of the <First> and <Last> texture/flat names are not present, no problem.
  2418. Then that potential cycle is unused. But if <First> is present, and
  2419. <Last> either is not present or is listed BEFORE <First>, then an
  2420. error occurs while the DOOM operating system sets up, and it aborts.
  2421.   Note that much longer sequences are possible! The entries between
  2422. <First> and <Last> can be almost anything; they need not be the same
  2423. in number as in the original, nor do they have to follow the same
  2424. naming pattern. Thus one could set up SLADRIP1, TRON2, TRON3, TRON4,
  2425. ..., TRON67, SLADRIP3 for a 69-frame animated wall!
  2426.   The "Ver" column indicates what version of DOOM is required. "All"
  2427. indicates all versions have it. The "r" signifies that the shareware
  2428. DOOM1.WAD does not contain the necessary picture lumps. The "2" means
  2429. that only DOOM 2 has the necessary picture lumps, but version 1.666 of
  2430. DOOM.EXE for DOOM 1 also has the capability to use these animation-cycle
  2431. names (for pwad designers).
  2432.  
  2433. First       Last         Ver    Normal # of frames
  2434.  
  2435. BLODGR1     BLODGR4       r     4
  2436. BLODRIP1    BLODRIP4      r     4
  2437. FIREBLU1    FIREBLU2      r     2
  2438. FIRELAV3    FIRELAVA      r     2 (3 patches are in DOOM.WAD, 1 is unused)
  2439. FIREMAG1    FIREMAG3      r     3
  2440. FIREWALA    FIREWALL      r     3
  2441. GSTFONT1    GSTFONT3      r     3
  2442. ROCKRED1    ROCKRED3      r     3
  2443. SLADRIP1    SLADRIP3     All    3
  2444.  
  2445. BFALL1      BFALL4        2     4
  2446. SFALL1      SFALL4        2     4
  2447. WFALL1      WFALL4        2     4
  2448. DBRAIN1     DBRAIN4       2     4
  2449.  
  2450. (floor/ceiling animations):
  2451.  
  2452. NUKAGE1     NUKAGE3      All    3
  2453. FWATER1     FWATER4       r     4
  2454. SWATER1     SWATER4       -     4 (SWATER lumps aren't in any DOOM.WAD)
  2455. LAVA1       LAVA4         r     4
  2456. BLOOD1      BLOOD3        r     3
  2457.  
  2458. RROCK05     RROCK08       2     4
  2459. SLIME01     SLIME04       2     4
  2460. SLIME05     SLIME08       2     4
  2461. SLIME09     SLIME12       2     4
  2462.  
  2463.  
  2464. [8-4-2]: The SKY Textures
  2465. -------------------------
  2466.  
  2467.   The SKY1, SKY2, and SKY3 textures are rather special in that they are
  2468. used as sky backgrounds when the player is out in the open. They can
  2469. also be used on regular walls, but they usually aren't, because then
  2470. they just look like a painting. The "background" effect is done by
  2471. the game engine. There is a special flat, F_SKY1, which is used to
  2472. indicate that a floor or ceiling is "transparent" to the SKY beyond.
  2473. The picture data in the F_SKY1 flat is not even used.
  2474.   Upper textures between F_SKY1 ceilinged sectors do not have the
  2475. specified texture (if any) drawn. Instead, they are "sky". Likewise
  2476. with lower textures between F_SKY1 floored sectors, but it doesn't
  2477. work as well, because if the player's viewpoint is below the top of
  2478. a lower-texture-sky (i.e. if any part of it is in the upper half of
  2479. the display), it causes a hall-of-mirrors effect.
  2480.   SKY textures as sky backgrounds are mirror-images of what they look
  2481. like on walls.
  2482.   The SKY textures are always placed with their tops at the top of the
  2483. view window. Since they cannot be more than 128 high, just like any
  2484. other texture, a rather ugly "seam" in the sky is sometimes visible
  2485. if the player can see too far "down".
  2486.   SKY textures do move horizontally, though, to give a realistic
  2487. effect. Doing a complete 360 degree turn will scroll by a 256-wide
  2488. SKY four times. A 1024-wide SKY will exactly circumscribe the horizon.
  2489. The 0 column of the SKY texture will be at due north (as on the automap),
  2490. the 256 column is at west, 512 is south, and 768 is east. So the middle
  2491. part of a 256-wide SKY is visible at NW, SW, SE, and NE.
  2492.  
  2493.   SKY textures can be composed of several patches, just like regular
  2494. textures, but trying to animate the sky doesn't work. DOOM.EXE can be
  2495. changed so that SKY2 is the start of an animation cycle, and indeed
  2496. on a wall it will animate, but the sky background does not. This is
  2497. perhaps related to the way that "middle" textures of sidedefs do not
  2498. animate.
  2499.  
  2500.  
  2501. [8-5]: PNAMES
  2502. =============
  2503.  
  2504.   This is a list of all the names of lumps that are going to be used
  2505. as wall patches. DOOM assigns numbers to these names, in the order
  2506. that they are listed. The numbers are then used in TEXTURE1 and TEXTURE2
  2507. entries to refer to wall patch lumps. In a texture composition entry,
  2508. 0 means the first pname, 1 is the second, ...
  2509.  
  2510.   The first four bytes of the PNAMES lump is a long integer N.
  2511.   Then follow N pnames, each of which occupies 8 bytes. Pnames less than
  2512. 8 bytes long are padded with zeros. These names duplicate an entry in
  2513. the directory (but are not case sensitive - lowercase letters will match
  2514. uppercase letters and vice versa). Unlike sprites and floors, wall
  2515. patches can be loaded from external pwads. Whichever pwad was listed
  2516. last on the command line and contains a lump with the same name as the
  2517. one in the PNAMES lump (which itself could be from a pwad) is the pwad
  2518. that is used to get the picture data for that wall patch.
  2519.  
  2520.  
  2521. [8-6]: DEMOs
  2522. ============
  2523.  
  2524.   If you start DOOM and do nothing, after a few seconds, it automatically
  2525. shows a demo of play on some level. Also, external demos can be recorded
  2526. and played back by using the command line parameters explained in the
  2527. README and/or the DOOM FAQ. All external demos have a .LMP extension
  2528. which the DOOM OS attaches; you only type the [demoname] without the
  2529. .LMP extension.
  2530.   The DOOM.WAD lumps DEMO1, DEMO2, and DEMO3 are in exactly the same
  2531. format as these external .LMP files. Strictly speaking, the "demo"
  2532. format should not be called the "LMP" format, because any external
  2533. file without a wadfile header, i.e. it is just raw data, is a "lump"
  2534. and deserves the .LMP extension.
  2535.  
  2536.   A DOOM demo has three parts:
  2537.  
  2538.   (1) header - 7 or 13 bytes
  2539.   (2) data recording player moves - 4 bytes per player per gametic
  2540.   (3) quit byte - equals 128 (0x80)
  2541.  
  2542. (1) There are two different kinds of header depending on the version of
  2543. DOOM used to record the demo. Versions up to 1.2 use a 7-byte header:
  2544.  
  2545.   byte  range   purpose
  2546.  
  2547. 0       0-4     skill level. 0="I'm too young to die", 4="Nightmare!"
  2548. 1       1-3     episode.
  2549. 2       1-9     mission/map.
  2550. 3       0-1     player 1 is present if this is 1.
  2551. 4       0-1     player 2.
  2552. 5       0-1     player 3.
  2553. 6       0-1     player 4.
  2554.  
  2555.   Versions after 1.2 use a 13-byte header:
  2556.  
  2557. byte    range   purpose
  2558.  
  2559. 0       104-106 version. 104=1.4 beta, 105=1.5 beta, 106=1.6 beta or 1.666
  2560. 1       0-4     skill level. 0="I'm too young to die", 4="Nightmare!"
  2561. 2       1-3     episode. In DOOM 2 this is always 1.
  2562. 3       1-32    mission/map/level. In DOOM 1, it's 1-9. In DOOM 2, it's 1-32.
  2563. 4       0-2     mode. 0=single or cooperative, 1=deathmatch, 2=altdeath
  2564. 5       0-      respawn. 0=no respawn parameter, (any other value)=respawn.
  2565. 6       0-      fast. 0=no fast parameter, (any other value)=fast.
  2566. 7       0-      nomonsters. 0=monsters exist, (any other value)=nomonsters.
  2567. 8       0-3     viewpoint. 0=player 1's status bar, ..., 3=player 4.
  2568. 9       0-1     player 1 is present if this is 1.
  2569. 10 0x0a 0-1     player 2.
  2570. 11 0x0b 0-1     player 3.
  2571. 12 0x0c 0-1     player 4.
  2572.  
  2573. (2) The player-move data is recorded in 4-byte chunks. Every 1/35 of a
  2574. second is a gametic, and for every gametic, there is one 4-byte chunk
  2575. per player. So the time duration of a demo (in seconds) is approximately
  2576. equal to its length in bytes divided by (140 * number_of_players).
  2577.  
  2578.   The four bytes recording each player's actions are:
  2579.  
  2580.   (a) Forward/Backward Movement. 
  2581.   (b) Strafe Right/Left Movement.
  2582.   (c) Turn Left/Right.
  2583.   (d) other actions - use/activate, fire, change weapons.
  2584.  
  2585.   The first three are signed bytes (i.e. of type <char>).
  2586.  
  2587.   (a) Ranges from -127 to 127, negative numbers are backward movement,
  2588.       positive numbers are forward movement. Without the -turbo option
  2589.       above 100, values outside -50..50 cannot be achieved. With a
  2590.       keyboard or joystick, these are the regular values:
  2591.  
  2592.       Move forward:   25 (0x19)   with Speed on:  50 (0x32)
  2593.       Move backward: -25 (0xE7)   with Speed on: -50 (0xCE)
  2594.  
  2595.       Fancy mouse use can achieve any number in the range.
  2596.  
  2597.   (b) Ranges from -127 to 127, negative numbers are left-strafe movement,
  2598.       positive numbers are right-strafe movement. The keyboard values are:
  2599.  
  2600.       Strafe right: 24  (0x18)    with Speed on:  50 (0x32)
  2601.       Strafe left: -24  (0xE8)    with Speed on: -50 (0xCE)
  2602.  
  2603.   (c) Ranges from -127 to 127, negative numbers are right turns, positive
  2604.       numbers are left turns. The keyboard values vary from version to
  2605.       version, but are all in the range -5..5, and that's with Speed on.
  2606.  
  2607.       Using the mouse can achieve much higher numbers here. I doubt if
  2608.       the maximums of 127 and -127 can actually be achieved in play,
  2609.       though.
  2610.  
  2611.   (d) the bits of this byte indicate what actions the player is engaged in:
  2612.  
  2613.       bit 0     Fire current weapon
  2614.       bit 1     Use (a switch, open a door, etc.)
  2615.       bit 2     Change weapon to the one indicated in bits 3-5:
  2616.  
  2617.       bits 5-3 = 000 Fist or Chainsaw
  2618.                  001 Pistol
  2619.                  010 Shotgun
  2620.                  011 Chaingun
  2621.                  100 Rocket Launcher
  2622.                  101 Plasma Rifle
  2623.                  110 BFG 9000
  2624.                  111 Super Shotgun (DOOM 2 only)
  2625.  
  2626.       bit 6     unused
  2627.       bit 7     indicates a special action which alters the meanings
  2628.                   of the other bits:
  2629.  
  2630.                 bits 1-0 = 01 pause or unpause
  2631.                          = 10 save game in slot # recorded in bits 4 to 2
  2632.                                 (slot number can thus be 0 to 7 but
  2633.                                  should NOT be 6 or 7 or else!)
  2634.  
  2635.   There might be other special actions. The save game action happens
  2636. during replay of the demo, so be careful when playing demos if you
  2637. have important savegames! One or more of them could conceivably get
  2638. overwritten.
  2639.  
  2640. (3) The last byte of a demo has the value 128 (0x80)
  2641.  
  2642.  
  2643. [8-6-1]: Level changes from 1.2 to 1.666 DOOM.WAD
  2644. =================================================
  2645.  
  2646.   Many people have experienced the error "Demo from a different game
  2647. version", because DOOM versions will only play back demos that were
  2648. recorded with the same version number. Theoretically, though, ANY
  2649. version can be converted to ANY other version. Versions up to 1.2
  2650. don't even require any modification, and versions 1.4 and up just
  2651. require that their first byte be changed. To change between the two
  2652. families (pre-1.4 and post-1.2) would just require extra header bytes
  2653. be added/shaved.
  2654.   But there are serious complications to converting demos. There have
  2655. been some minor changes and bug-fixes to the levels from version to
  2656. version. Since the demos only record player actions, they have NOTHING
  2657. about the level in them, so they depend on the level used for playback
  2658. to be the same as the level used for recording. Some kinds of differences
  2659. in the playback level can cause the demo to become "unsynchronized"
  2660. with the level, and players will seem to have gone crazy. For example,
  2661. if a deathmatch start-position is at a different location, when a
  2662. demo-player is spawned there, they will try to open doors that don't
  2663. exist at the new location, shoot at people who aren't there, etc.
  2664. The entire playback is ruined from that point on. Some examples of
  2665. changes that don't matter are different floor and wall textures, light
  2666. levels, and linedef "unpegged" flags. But most changes DO matter.
  2667.   Note that changes like (nomonsters) vs. (monsters), (respawn) vs.
  2668. (regular), (altdeath) vs. (regular deathmatch) will very quickly lead
  2669. to unsynchronized goofball players.
  2670.  
  2671.  
  2672.  
  2673. ---------------------------
  2674. CHAPTER [9]: Savegame Files
  2675. ---------------------------
  2676.  
  2677.  
  2678. -------------------------------
  2679. CHAPTER [10]: The DOOM.EXE File
  2680. -------------------------------
  2681.  
  2682.   Via pwads, a great many characteristics of the DOOM environment can
  2683. be changed: maps, pictures, sounds, etc. But there are also a lot of
  2684. neat things that can be done by patching the DOOM.EXE file itself.
  2685. There is a large collection of data at the end of the EXE file, and by
  2686. patching some bytes, we can turn literal values into variables. For
  2687. example, the player has a 16-unit "radius" which prevents him from
  2688. entering very small passageways. The player's radius can be made 1 and
  2689. his "height" 1, so he can enter mouse-sized crawlspaces. There are a
  2690. lot more exciting examples, such as invisible monsters, cyber-demons
  2691. that look like players, super-fast shotguns, and a hundred others, but
  2692. I won't describe all of that here. See appendix [A-4] for some EXE
  2693. utilities and documents. Here I will simply give the data that has
  2694. been figured out to date.
  2695.   I freely mix hex and decimal numbers below. Hopefully you can tell from
  2696. the context. All of the stuff below applies to registered version 1.2,
  2697. and some of it applies to version 1.666 also. This chapter has not yet
  2698. been completely updated for 1.666, but it soon will be.
  2699.  
  2700. [10-1]: Version 1.2 DOOM.EXE Data Segment Overview  
  2701. ==================================================  
  2702.  
  2703.   The data begins at 0x6f414 (455700) and continues to the end of the
  2704. file, 0x8db27 (580391). Here's an overview of the sections:
  2705.  
  2706. start length what
  2707.  
  2708. 6f414  3d30  TEXT STRINGS
  2709. 73412  1a34  various unknowns, probably to do with I/O, sound, mouse, etc.
  2710. 74bf8 10000  looks like hard-coded math tables, for speed?
  2711. 84bf8   148  misc.
  2712. 84d40    82  gamma correction messages
  2713. 84dc2   280  "are you sure you want to quit" messages
  2714. 85042   3a2  MENUS (new game, load game, etc.)
  2715. 853e4   140  ?
  2716. 85524   36c  configuration options and defaults, like in DEFAULT.CFG
  2717. 85890   174  ?
  2718. 85a04    60  ?
  2719. 85a64    54  ?
  2720. 85ab8    c4  ?
  2721. 85b7c    20  max ammo at start, and ammo per thing
  2722. 85b9c    c0  ammo type and frame #s for the weapons
  2723. 85c5c   188  ANIMATED WALLS and FLOORS
  2724. 85de4   258  SWITCH-WALLS
  2725. 8603c    c0  ?
  2726. 860fc    d4  ?
  2727. 861d0   500  5 colormaps for use with the gamma correction setting 0-4
  2728. 866e4    fc  ?
  2729. 867e0    40  pointers to chatmacros, "Green:", etc.
  2730. 86820    88  pointers to level names, used on Automap
  2731. 868a8    d8  splat mark coordinates for end-level screen
  2732. 86980   5a8  wimap patch animations for end-level screen
  2733. 86f28   224  SONG NAMES list of pointers
  2734. 8714c   8b8  SOUND TABLE
  2735. 87a04   1a4  SPRITE NAMES list of pointers
  2736. 87ba8  3800  STATE TABLE
  2737. 8b3a8    20  ?
  2738. 8b3c8  2368  THING TABLE
  2739. 8d730   3fd  ?
  2740.  
  2741. [10-2]: Version 1.666 DOOM.EXE Data Segment Overview
  2742. ====================================================
  2743.  
  2744.  
  2745. [10-3]: Detail on some EXE Data Structures
  2746. ==========================================
  2747.  
  2748.   More detail on some of the data follows. The "names" of each section
  2749. are the hexadecimal offsets to the start of that data, in the registered
  2750. versions 1.2 and 1.666 of DOOM.EXE. 1.2 offsets are to the left of the
  2751. asterisk, 1.666 to the right. "Integer" means a 4-byte <long> integer
  2752. in hi-lo format, unless otherwise noted (e.g. "2-byte short integer").
  2753.  
  2754. 6f414 *** 82a14 
  2755.  
  2756.   START OF DATA. Several times I'll refer to "pointers". All of these
  2757. pointers are integers. Add the values of these pointers to $6f414 or
  2758. $82a14 depending on the version, and you'll get the location of what's
  2759. being pointed to.
  2760.   Note: there's also at least one other kind of pointer in here, with
  2761. larger values, that point to a location in the code, NOT the data. I call
  2762. these "code-pointers" for now. I know it's a lame term.
  2763.  
  2764. 6f414 *** a2228 
  2765.  
  2766.   TEXT STRINGS. They all start on 4-byte boundaries, i.e. at xxxx0/4/8/c.
  2767. $00 ends the string. Then the next one starts at the next boundary, so a 4
  2768. byte string is followed by $00, then 3 bytes of random junk, then the next
  2769. string.
  2770.  
  2771. 73140
  2772.  
  2773.   I think this is the last string, "TZ"
  2774.  
  2775. 73144
  2776.   
  2777.   Misc. stuff I haven't investigated. Some of it has to do with sound card
  2778. stuff and mice and joysticks, because at 7384c is "DMXGUS.INI" and at 74ba8
  2779. are pointers which point to the strings "None", "PC_Speaker", "Adlib", etc.
  2780.  
  2781. 74bf8
  2782.  
  2783.   64k of precisely ordered numbers, which leads me to believe they are
  2784. pre-calculated math tables, to speed up some floating point operations
  2785. used in the screen draw routine. Any other guesses?
  2786.  
  2787. 84bfc
  2788.  
  2789.   3 pointers to the episode 1/2/3 end texts, "Once you beat...", "You've
  2790. done it...", and "The loathsome Spiderdemon is dead..."
  2791.  
  2792. 84c24
  2793.  
  2794.   pointer to the string "doom.wad"
  2795.  
  2796. 84c74
  2797.  
  2798.   pointer to the string "default.cfg"
  2799.  
  2800. 84c78
  2801.  
  2802.   8 integers: 1, 25, 50, 24, 40, 640, 1280, 320
  2803.  
  2804. 84c98
  2805.  
  2806.   2 code-pointers
  2807.  
  2808. 84ccc
  2809.  
  2810.   29 integers, with values like 90 and 135 and 180. Angles?
  2811.  
  2812. 84d40
  2813.  
  2814.   "Gamma correction OFF", 00s, "Gamma correction level 1", ... 4. Each
  2815. occupies $1a bytes.
  2816.  
  2817. 84dc2
  2818.  
  2819.   8 text messages used to confirm quitting, each uses $50 bytes
  2820.  
  2821. 85042
  2822.  
  2823.   MENUS. I know this controls to some extent which menu pictures are used
  2824. for which menu, but I haven't figured it all out yet.
  2825.  
  2826. 853e4
  2827.  
  2828.   14 ints: 42, 22, 23, 24, 28, 29, 31, 40, zeros
  2829.  
  2830. 8541c
  2831.  
  2832.   256 bytes, values from 00-ff, no two the same, "random" order.
  2833.  
  2834. 85524
  2835.  
  2836.   The configuration options. Each is 5 integers: a pointer to a string,
  2837. like "mouse_sensitivity", a code-pointer, the default value for that
  2838. option, a 0 or 1 (1 for all the "key_" options), and a 0. It would be
  2839. pretty dense to do anything with this, I think.
  2840.  
  2841. 85890
  2842.  
  2843.   About 117 integers, with a definite structure, but I can't figure it
  2844. out, and changing/experimenting seems to do nothing.
  2845.  
  2846. 85a64
  2847.  
  2848.   21 sets of 4 bytes: 0, 0, 1, 0, 320, 168, "33", 0, 1, $(b2 26 26 2e),
  2849. $(ff 63 fd ff), a pointer that points to the $(b2...), 0, 1, "ema", 0, 0,
  2850. 1, 0, 1, "xma". All these are unchanged from version 0.99 through 1.2,
  2851. except the pointer obviously.
  2852.  
  2853. 85ab8
  2854.  
  2855.   Ints: 0, -1, -1, 0, 0, 0, 0, 4, 7, 10, 12, 14, 15, 15, 0, 0, 112, 96, 64,
  2856. 176, then 16 that are members of this set {-65536, -47000, 0, 47000, 65536},
  2857. then 4, 5, 6, 7, 0, 1, 2, 3, 8, 3, 1, 5, 7
  2858.  
  2859. 85b7c *** 95714
  2860.  
  2861.   AMMO AMOUNTS. 8 integers: 200, 50, 300, 50, 10, 4, 20, 1. The first four
  2862. are the maximum initial capacity for ammo, shells, cells, and rockets. The
  2863. backpack doubles these amounts. The second four are how many ammo in a
  2864. clip, shells, rockets/rocket, and cells/cell item. Boxes have 5x as much.
  2865.  
  2866. 859bc *** 95734
  2867.  
  2868.   AMMO TABLE. 8 sets of 6 integers (9 sets in 1.666):
  2869.  
  2870.   version 1.2                             version 1.666
  2871.  
  2872. Punch     5  4  3  2  5  0              Punch     5  4  3  2  5  0
  2873. Pistol    0 12 11 10 13 17              Pistol    0 12 11 10 13 17
  2874. Shotgun   1 20 19 18 21 30              Shotgun   1 20 19 18 21 30
  2875. Chaingun  0 34 33 32 35 38              Chaingun  0 51 50 49 52 55
  2876. Laucher   3 42 41 40 43 46              Laucher   3 59 58 57 60 63
  2877. Plasma    2 59 58 57 60 62              Plasma    2 76 75 74 77 79
  2878. BFG       2 66 65 64 67 71              BFG       2 83 82 81 84 88
  2879. Chainsaw  5 53 52 50 54  0              Chainsaw  5 70 69 67 71  0
  2880.                                   Super-Shotgun   1 34 33 32 35 47
  2881.  
  2882.   The first number of each set is the ammo type. Type 5 never runs out.
  2883. The next three numbers are 3 state #s (see the STATE TABLE below) for the
  2884. pictures displayed when moving while holding that weapon. You know, the
  2885. "bobbing weapon" effect? Fifth is the first state of the "shoot" sequence
  2886. for that weapon, and last is the first state of the "firing" sequence. The
  2887. "firing" pictures are the ones that are lit up, fire coming out, etc.
  2888.  
  2889. 85c5c *** 9580c
  2890.  
  2891.   ANIMATED WALLS and FLOORS. Each is 26 bytes: an integer, a 8-byte string,
  2892. $00, a 8-byte string, $00, and a final integer.
  2893.  
  2894. 0 NUKAGE3  NUKAGE1  8
  2895. 0 FWATER4  FWATER1  8
  2896. 0 SWATER4  SWATER1  8
  2897. 0 LAVA4    LAVA1    8
  2898. 0 BLOOD4   BLOOD1   8
  2899.                        <---- v1.666 has four more:  0 RROCK08  RROCK05  8
  2900. 1 BLODGR4  BLODGR1  8                               0 SLIME04  SLIME01  8
  2901. 1 SLADRIP4 SLADRIP1 8                               0 SLIME08  SLIME05  8
  2902. 1 BLODRIP4 BLODRIP1 8                               0 SLIME12  SLIME09  8
  2903. 1 FIREWALL FIREWALA 8
  2904. 1 GSTFONT3 GSTFONT1 8
  2905. 1 FIRELAVA FIRELAV3 8
  2906. 1 FIREBLU2 FIREBLU1 8
  2907. 1 ROCKRED3 ROCKRED1 8
  2908.                        <---- V1.666 has four more:  1 BFALL4   BFALL1   8
  2909.                                                     1 SFALL4   SFALL1   8
  2910.                                                     1 WFALL4   WFALL1   8
  2911.                                                     1 DBRAIN4  DBRAIN1  8
  2912.  
  2913.   Obviously the 0/1 means floor or wall. The first string is the name of
  2914. the animation cycle's LAST listed texture, the second string is the FIRST
  2915. listed texture. The cycle includes them and all entries between them in
  2916. whichever wad file is in effect (It doesn't have to be DOOM.WAD, a pwad
  2917. with new TEXTURE1 and 2 resources works quite nicely). The final 8 
  2918. doesn't seem to mean much.
  2919.  
  2920. 85dc8
  2921.  
  2922.   A -1 then a bunch of zeros, maybe space for another animation cycle?
  2923.  
  2924. 85de4 *** 95a64
  2925.  
  2926.   SWITCH WALL NAMES. Each is 20 bytes: an 8-byte string, 00, another
  2927. string, 00, and a 2-byte short integer. There are 28 switch names here
  2928. in v1.2 and 39 switch names in v1.666. When a switch is pulled, the game
  2929. checks to see if the wall texture is on this list. If it is, it changes
  2930. the wall texture to the corresponding alternate texture. The <short>
  2931. is 1, 2, or 3. 1 means it's in all versions, 2 means only registered
  2932. DOOM 1 and DOOM 2, 3 means DOOM 2 only.
  2933.  
  2934. 86028
  2935.  
  2936.   20 zeros, again, room for one more?
  2937.  
  2938. 8603c ***
  2939.  
  2940.   48 integers: 3 0 2 1 3 0 2 0 3 1 2 0 0 0 0 0
  2941.                2 0 2 1 0 0 0 0 3 1 3 0 0 0 0 0
  2942.                2 0 3 1 2 1 3 1 2 1 3 0 0 0 0 0
  2943.  
  2944. 860fc ***
  2945.  
  2946.   50 integers, all are either 50 or -50.
  2947.  
  2948. 861d0 ***
  2949.  
  2950.   5 sets of 256 bytes, each is a COLORMAP, for the gamma correction
  2951. settings OFF, 1, 2, 3, 4.
  2952.  
  2953. 866d0 ***
  2954.  
  2955.   5 integers: 1, 0, -1, 0, 0
  2956.  
  2957. 866e4 ***
  2958.  
  2959.   13 sets of 5 - 10 bytes, each set terminated by a $FF
  2960.  
  2961. 8675e ***
  2962.  
  2963.   $74 $20
  2964.  
  2965. 86760 ***
  2966.  
  2967.   13 pointers to the stuff at 866e4. An integer '0' between each pointer.
  2968.  
  2969. 867c8 ***
  2970.  
  2971.   6 integers: -1, -1, 0, -1, 0, 1
  2972.  
  2973. 867e0 ***
  2974.  
  2975.   10 pointers to the 10 default chatmacros, then 4 pointers, to "Green:",
  2976. "Indigo:", "Brown:", "Red:"
  2977.  
  2978. 86820 ***
  2979.  
  2980.   AUTOMAP LEVEL NAMES. 27 pointers to the level names used on the automap.
  2981.  
  2982. 8689c ***
  2983.  
  2984.   The ascii letters "gibr" - the keys for sending messages in multiplayer.
  2985.  
  2986. 868a8 ***
  2987.  
  2988.   SPLAT MARK COORDINATES. At what screen coordinates to place the WISPLAT
  2989. picture on the end-level screen, for th 27 levels. 54 integers, 27 pairs.
  2990. e1m1 x, e1m1 y, ..., e3m9 y.
  2991.  
  2992. 86980, 86bb0, 86da8 ***
  2993.  
  2994.   END-LEVEL MAP ANIMATIONS. Each is 14 integers. The first one is (0, 11,
  2995. 3, 224, 104, 0, 0, 0, 0, 0, 0, 0, 0, 0). The first number is 0 for all the
  2996. ones on maps 0 and 2 (episodes 1 and 3), and it's 2 for map 1. The 11 is
  2997. always 11 except the last one of map 2 is 8. The 3 means 3 pictures are
  2998. involved in the animation, e.g WIA00100, WIA00101, and WIA00102. 224 and 104
  2999. are the x and y coordinates. The sixth number is not 0 for map 1 - it's
  3000. from 1 to 8. This controls the way the Tower of Mystery "appears". All the
  3001. other numbers are always 0.
  3002.  
  3003. 86ef8 ***
  3004.  
  3005.   Three integers, how many animations for WIMAP0, 1, 2 respectively.
  3006.  
  3007. 86f04 ***
  3008.  
  3009.   Three pointers, to the starts of the animations for WIMAP0, 1, 2
  3010. respectively.
  3011.  
  3012. 8714c ***
  3013.  
  3014.   SOUND TABLE. 61 and 1/2 sounds are listed here. Each is 9 integers: a
  3015. pointer to the string which is the sound's "name", then a 0 or 1, then
  3016. a value ranging from 32 to 128, then 0, -1, -1, 0, 0, 0. The names are
  3017. "pistol", "shotgn", ... "hoof", "metal", "chgun". Prefix DS or DP and you
  3018. get the entries in DOOM.WAD for the sound data. The "chgun" is the 1/2 -
  3019. there's no "DSCHGUN" in doom.wad, and the entry in this table is incomplete
  3020. anyway, lacking the all-important 0, -1, -1, 0, 0, 0 ending :-). There seem
  3021. to be a few glitches in the way the sounds were fit into the whole scheme,
  3022. this is just one of them. 
  3023.  
  3024. 879ec ***
  3025.  
  3026.   pointer to start of SOUND TABLE.
  3027.  
  3028. 879f0 ***
  3029.  
  3030.   Integer = 150. 150 whats?
  3031.  
  3032. 87a04 ***
  3033.  
  3034.   SPRITE NAME POINTERS. 105 pointers to the strings "TROO", "SHTG", ...,
  3035. "SMRT".
  3036.  
  3037. 87ba8 *** 9834c
  3038.  
  3039.   STATE TABLE. 512 entries in v1.2, 967 entries in v1.666. Each entry
  3040. is 28 bytes in 7 integers:
  3041.  
  3042. (1)     sprite number 0-..., lookup in sprite name pointers list.
  3043. (2)     sprite frame, 0="A" in a sprite lump, 1="B", etc.
  3044. (3)     duration, how many gametics this state is displayed until
  3045.           it looks for the next. -1 (0xffffffff) is forever.
  3046. (4)     a "code pointer" which indicates what action(s) accompany
  3047.           the displaying of this state.
  3048. (5)     next state in sequence. 0 means no next state, sequence is done.
  3049. (6)     always 0, has no effect.
  3050. (7)     always 0, has no effect.
  3051.  
  3052.  
  3053. 8b3a8 ***
  3054.  
  3055.   Two integers: 1, 0, then 6 code-pointers.
  3056.  
  3057. 8b3c8 *** 9ed10
  3058.  
  3059.   THING TABLE. 103 entries in v1.2 which are each 88 bytes = 22 integers.
  3060. 136 entries in v1.666, which are each 92 bytes = 23 integers.
  3061.  
  3062. (1)     Thing number, as used in maps. See [4-2-1]. Some of them are
  3063.           equal to -1, e.g. the players' entry, and all projectiles.
  3064. (2)     "Spawn" state. State number (from STATE TABLE) for when this
  3065.           thing first appears.
  3066. (3)     Health. Inanimates can't be killed, so it doesn't apply to them.
  3067. (4)     "Moving" state. First state # of monsters pursuing, etc.
  3068. (5)     "See player" sound. For monsters who become activated. Also for
  3069.           projectiles' first sound. Note that sounds are 1-..., not 0-...
  3070.           0 indicates no sound.
  3071. (6)     Reaction Time. Lower is faster.
  3072. (7)     "Attack" sound.
  3073. (8)     "Pain" state.
  3074. (9)     Painchance. The chance out of 256 that a monster will be disrupted
  3075.           when it gets hurt. Otherwise, they keep attacking.
  3076. (10)    "Pain" sound.
  3077. (11)    "Close attack" state.
  3078. (12)    "Distance attack" state.
  3079. (13)    "Death" state, or "explode" for projectiles.
  3080. (14)    "Explosive death" state, only some monsters can be "mushed".
  3081. (15)    "Death" sound, or "explode" for projectiles.
  3082. (16)    Speed of movement. Projectiles' speed are * 65536.
  3083. (17)    Horizontal size (radius) * 65536
  3084. (18)    Height * 65536
  3085. (19)    Mass
  3086. (20)    Missile damage. Also, the Lost Soul has a 3 here, for it's attack.
  3087. (21)    "Act" sound, for wandering monsters.
  3088. (22)    Flags, see below
  3089. (23)    "Respawn" state, for monsters being ressurected. VERSION 1.666 ONLY
  3090.  
  3091.   Flags. 0 = condition is false. 1 = condition is true.
  3092.  
  3093.   bit   flagname        effect on thing
  3094.  
  3095.   0     Special         it is a gettable thing (ammo, health, etc.)
  3096.   1     Solid           creatures can't pass through (but projectiles can)
  3097.   2     Shootable       can be hurt (note barrels have this set)
  3098.   3     NoSector        totally invisible
  3099.   4     NoBlockmap      
  3100.   5
  3101.   6     (InPain)        ?
  3102.   7
  3103.   8     SpawnCeiling    hung from ceiling
  3104.   9     NoGravity       floating monsters and not-on-ground things
  3105.   10    Dropoff         doesn't automatically hug floor if "jump" off ledge
  3106.   11    Pickup          can pick up gettable items
  3107.   12    (NoClip)        walks through walls
  3108.   13
  3109.   14    Float           floating monsters
  3110.   15    (Semi-NoClip)   climb tall steps
  3111.   16    Missile         projectiles
  3112.   17    (Disappearing   ?
  3113.          Weapon)        
  3114.   18    Shadow          semi-invisible like Spectres
  3115.   19    NoBlood         uses PUFF instead of BLUD when hurt (e.g. barrels)
  3116.   20    (SlideHelpless) ?
  3117.   21
  3118.   22    CountKill       Monster: counts toward KILLS ratio on inter-level
  3119.   23    CountItem       Artifact: counts toward ITEMS on inter-level screen
  3120.   24    (Running)       ?
  3121.   25    NotDMatch       this thing doesn't get spawned in deathmatch modes
  3122.   26    Color0          \ 00 = green stays green  01 = change to dark greys
  3123.   27    Color1          / 10 = change to browns   11 = change to dark reds
  3124.   28-                   unused
  3125.  
  3126. 8d730 *** n/a
  3127.  
  3128.   Misc junk I can't figure out.
  3129.  
  3130. 8db27 *** a7b99
  3131.  
  3132.   End of DOOM.EXE
  3133.  
  3134.  
  3135. ------------------------------------------------------------
  3136. APPENDIX [A-1]: Backus-Naur Form definitions of WAD elements
  3137. ------------------------------------------------------------
  3138.  
  3139.   The descriptions below use a modified Backus-Naur Form (BNF) notation.
  3140. Each entry looks like
  3141.  
  3142. <keyword>       := description          ;type or comment (optional)
  3143.                    description cont'd.  ;type or comment (optional)
  3144.  
  3145.   Descriptions composed of more than one sequential keyword or element
  3146. are usually listed with one element per line. This is for clarity and also
  3147. allows each succesive element to be assigned different types without extra
  3148. lines.
  3149.  
  3150. <keyword>       := <whatever>           ;<type>
  3151.  
  3152.   is a shorthand for
  3153.  
  3154. <keyword>       := <whatever>
  3155. <whatever>      := <type>
  3156.  
  3157.   The description is one or more of the following predefined types,
  3158. and/or previously or subsequently defined keywords.
  3159.  
  3160. <byte>          is an unsigned 8-bit integer (0 to 255).
  3161. <char>          is a signed 8-bit integer (-128 to 127).
  3162. <ushort>        is an unsigned 16-bit integer in lo-hi format (0 to 65535)
  3163. <short>         is a signed 16-bit integer (-32768 to 32767).
  3164. <long>          is a signed 32-bit integer (-2147483648 to 2147483647).
  3165. <string8>       is an ASCII string of from 1 to 8 bytes. If its length is
  3166.                   less than 8 bytes, the remainder are zeros (hex 00).
  3167.  
  3168.   Any of these may be followed by a range: <byte:1..99> means a byte
  3169. restricted to the range 1 to 99 inclusive. A single number means that
  3170. value is literally included: <byte:192> inserts that 8-bit value.
  3171.  
  3172.   { } are used to enclose a group of elements.
  3173.  
  3174.   | is used to separate choices - exactly one of the choices applies.
  3175.  
  3176.   [ ] are used following an element or group of elements to indicate
  3177. an array. Usually a literal value or a keyword will be used to denote
  3178. how many members the array has. <rook> [666] means that the element
  3179. <rook> is repeated 666 times in sequence. {<Scylla> <Charybdis>} [zeus]
  3180. means that whatever the value of <zeus> is, there are that many pairs
  3181. of <Scylla> and <Charybdis>. [1..16] indicates the value may be from
  3182. 1 to 16 inclusive, and [...] indicates an indefinite number.
  3183.  
  3184.   A literal string "ABCD" may appear, in which case those ASCII characters
  3185. are directly inserted.
  3186.  
  3187. ------
  3188.  
  3189. <WAD file>      := "PWAD"|"IWAD" 
  3190.                    <numlumps> 
  3191.                    <infotableofs> 
  3192.                    <lumps> 
  3193.                    <directory>
  3194.  
  3195. <numlumps>      := <long>               ;number of lumps in WAD file
  3196. <infotableofs>  := <long>               ;file offset to directory start
  3197.  
  3198. <lumps>         := <lump> [numlumps]
  3199. <lump>          :=                      ;see different kinds below
  3200.  
  3201. <directory>     := {<lumpinfo> | <otherinfo>} [numlumps]
  3202. <lumpinfo>      := <filepos>            ;<long>
  3203.                    <size>               ;<long>
  3204.                    <name>               ;<string8>
  3205.  
  3206. <otherinfo>     := <marker> | <label>
  3207. <marker>        := <dummynumber>        ;<long> with any value
  3208.                    <long:0>
  3209.                    <"S_START" | etc>    ;<string8>
  3210.  
  3211. <label>         := {<"E"> <episode> <"M"> <mission>} | {<"MAP"> <level>}
  3212. <episode>       := "1"|"2"|"3"
  3213. <mission>       := "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
  3214. <level>         := "01"|"02"|"03"|"04"|"05"|"06"|"07"|"08"|"09"|"10"
  3215.                    |"11"|"12"|"13"|"14"|"15"|"16"|"17"|"18"|"19"|"20"
  3216.                    |"21"|"22"|"23"|"24"|"25"|"26"|"27"|"28"|"29"|"30"
  3217.                    |"31"|"32"
  3218.  
  3219. ------
  3220. different kinds of lumps:
  3221. ------
  3222.  
  3223. <PLAYPAL>       := <palette> [14]
  3224. <palette>       := {<red> <green> <blue>} [256]
  3225. <red>           := <byte>
  3226. <green>         := <byte>
  3227. <blue>          := <byte>
  3228.  
  3229. ------
  3230.  
  3231. <COLORMAP>      := <color_map> [34]
  3232. <color_map>     := <mapping> [256]
  3233. <mapping>       := <byte>
  3234.  
  3235. ------
  3236.  
  3237. <ENDOOM>        := <character_cell> [1000]
  3238. <character_cell>:= <color_attributes>           ;<byte>
  3239.                    <character>                  ;<byte>
  3240.  
  3241. ------
  3242.  
  3243. <demo>          := <header>
  3244.                    <gametic_data>
  3245.                    <byte:128>
  3246. <header>        := {<header_12> | <header_16>}  ;different versions
  3247. <header_12>     := <skill>
  3248.                    <episode>
  3249.                    <map>
  3250.                    <player> [4]
  3251. <header_16>     := <version>
  3252.                    <skill>
  3253.                    <episode>
  3254.                    <map> 
  3255.                    <mode>
  3256.                    <respawn>
  3257.                    <fast>
  3258.                    <nomonsters>
  3259.                    <viewpoint>
  3260.                    <player> [4]
  3261. <skill>         := <byte:0..4>
  3262. <episode>       := {<byte:1..3> | <byte:1>}     ;DOOM 1 or DOOM 2
  3263. <map>           := {<byte:1..9> | <byte:1..32>} ;DOOM 1 or DOOM 2
  3264. <player>        := <byte:0..1>          ;0 means not present, 1 means present
  3265. <version>       := <byte:104..106>      ;versions 1.4, 1.5, 1.6 (also 1.666)
  3266. <mode>          := <byte:0..2}          ;cooperative|deathmatch|altdeath
  3267. <respawn>       := <byte>               ;0 is off, non-zero is on
  3268. <fast>          := <byte>               ;0 is off, non-zero is on
  3269. <nomonsters>    := <byte>               ;0 is off, non-zero is on
  3270. <viewpoint>     := <byte:0..3>          ;shown from this player's view
  3271.  
  3272. <gametic_data>  := <gametic> [...]
  3273. <gametic>       := <player_move> [1..4] ;1-4 is # of players present in demo
  3274. <player_move>   := <forward>            ;<char>
  3275.                    <strafe>             ;<char>
  3276.                    <turn>               ;<char>
  3277.                    <use>                ;<byte>
  3278.  
  3279. ------
  3280.  
  3281. <GENMIDI>       := "#OPL_II#"
  3282.                    <instr_data> [150]
  3283.                    <instr_name> [150]
  3284. <instr_data>    := <byte> [36]          ;format unknown to me
  3285. <instr_name>    := <byte> [32]          ;padded with 0s
  3286.  
  3287. ------
  3288.  
  3289. <DMXGUS>        := pointless to describe here, see section [7-5]
  3290.  
  3291. ------
  3292.  
  3293. <song>          := "MUS"
  3294.                    <byte:26>
  3295.                    <music_length>       ;<ushort>
  3296.                    <music_start>        ;<ushort>
  3297.                    <primary_channels>   ;<ushort>
  3298.                    <secondary_channels> ;<ushort>
  3299.                    <num_instr_patches>  ;<ushort>
  3300.                    <ushort:0>
  3301.                    <instr_patches>
  3302.                    <music data>
  3303. <instr_patches> := <instr_patch> [num_instr_patches]
  3304. <instr_patch>   := <ushort>             ;Drum patch #s 28 less than in DMXGUS
  3305.  
  3306. <music data>    := ???
  3307.  
  3308. ------
  3309.  
  3310. <soundeffect>   := <ushort:3>
  3311.                    <ushort:11025>       ;sampling rate
  3312.                    <num_samples>        ;<ushort>
  3313.                    <ushort:0>
  3314.                    <samples>
  3315. <samples>       := <sample> [num_samples]       ;<byte>
  3316.  
  3317. ------
  3318.  
  3319. <PC_sound>      := <ushort:0>
  3320.                    <num_PC_samples>     ;<ushort>
  3321.                    <PC_samples>
  3322. <PC_samples>    := <PC_sample> [num_PC_samples]
  3323. <PC_sample>     := <byte>               ;seem to range [0..96]
  3324.  
  3325. ------
  3326.  
  3327. <TEXTURE1>      := <num_textures>       ;<long>
  3328.                    <tex_offsets>
  3329.                    <tex_entries>
  3330. <tex_offsets>   := <tex_offset> [num_textures]
  3331. <tex_offset>    := <long>
  3332. <tex_entries>   := <tex_entry> [num_textures]
  3333. <tex_entry>     := <tex_name>           ;<string8>
  3334.                    <short:0>
  3335.                    <short:0>
  3336.                    <tex_width>          ;<short>
  3337.                    <tex_height>         ;<short>
  3338.                    <short:0>
  3339.                    <short:0>
  3340.                    <num_patches>        ;<short>
  3341.                    <patches>            
  3342. <patches>       := <patch> [num_patches]
  3343. <patch>         := <x_offset>           ;all are <short>
  3344.                    <y_offset>
  3345.                    <pname_number>       ;lookup in <PNAMES> for picture
  3346.                    <short:1>            ;supposedly <stepdir>
  3347.                    <short:0>            ;supposedly <color_map>
  3348.  
  3349. ------
  3350.  
  3351. <PNAMES>        := <num_pnames>         ;<long>
  3352.                    <pnames>
  3353. <pnames>        := <pname> [num_pnames]
  3354. <pname>         := <string8>]           ;match the <name> from the
  3355.                                         ;<lumpinfo> of a <picture>
  3356.  
  3357. ------
  3358.  
  3359. <picture>       := <header>
  3360.                    <pointers>           ;offsets to <column> starts
  3361.                    <pixel_data>
  3362. <header>        := <width>              ;all are <short>
  3363.                    <height>
  3364.                    <left_offset>
  3365.                    <top_offset>
  3366. <pointers>      := <pointer> [width]    ;<long>
  3367. <pixel_data>    := <column> [width]
  3368. <column>        := <post> [...] 
  3369.                    <byte:255>           ;255 (0xff) ends the column
  3370. <post>          := <rowstart>           ;<byte>
  3371.                    <num_pixels>         ;<byte>
  3372.                    <unused>             ;<byte>
  3373.                    <pixels>
  3374.                    <unused>             ;<byte>
  3375. <pixels>        := <pixel> [num_pixels] ;<byte>
  3376.  
  3377. ------
  3378.  
  3379. <flat>          := <colorbyte> [4096]   ;<byte>
  3380.  
  3381. ------
  3382.  
  3383. <maplevel>      := <THINGS> 
  3384.                    <LINDEDEFS> 
  3385.                    <SIDEDEFS> 
  3386.                    <VERTEXES> 
  3387.                    <SEGS> 
  3388.                    <SSECTORS> 
  3389.                    <NODES> 
  3390.                    <SECTORS> 
  3391.                    <REJECT> 
  3392.                    <BLOCKMAP>
  3393.  
  3394. <THINGS>        := <thing> [...]
  3395. <thing>         := <x_position>         ;all are <short>
  3396.                    <y_position>
  3397.                    <angle>
  3398.                    <type>
  3399.                    <options>
  3400.  
  3401. <LINEDEFS>      := <linedef> [...]
  3402. <linedef>       := <vertex_start>       ;all are <short>
  3403.                    <vertex_end>
  3404.                    <flags>
  3405.                    <function>
  3406.                    <tag>
  3407.                    <sidedef_right>
  3408.                    <sidedef_left>       ;if <short: -1> there's no left side
  3409.  
  3410. <SIDEDEFS>      := <sidedef> [...]
  3411. <sidedef>       := <xoffset>            ;<short>
  3412.                    <yoffset>            ;<short>
  3413.                    <uppertexture>       ;<string8>
  3414.                    <lowertexture>       ;<string8>
  3415.                    <middletexture>      ;<string8>
  3416.                    <sector_ref>         ;<short>
  3417.  
  3418. <VERTEXES>      := <vertex> [...]
  3419. <vertex>        := <X_coord>            ;both are <short>
  3420.                    <Y_coord>    
  3421.  
  3422. <SEGS>          := <seg> [...]          ;<segs> stored by <subsector> order
  3423. <seg>           := <vertex_start>       ;all are <short>
  3424.                    <vertex_end>
  3425.                    <bams>
  3426.                    <line_num>
  3427.                    <segside>
  3428.                    <segoffset>
  3429.  
  3430. <SSECTORS>      := <subsector> [...]
  3431. <subsector>     := <numsegs>            ;both are <short>
  3432.                    <start_seg>
  3433.  
  3434. <NODES>         := <node> [...]
  3435. <node>          := <x>                  ;first four are <short>
  3436.                    <y>
  3437.                    <dx>
  3438.                    <dy>
  3439.                    <bbox> [2]
  3440.                    <child> [2]
  3441. <bbox>          := <boxtop>             ;all are <short>
  3442.                    <boxbottom>
  3443.                    <boxleft>
  3444.                    <boxright>
  3445. <child>         := <ushort>             ;if 0x8000 it's a subsector
  3446.  
  3447. <SECTORS>       := <sector> [...]
  3448. <sector>        := <floorheight>        ;<short>
  3449.                    <ceilingheight>      ;<short>
  3450.                    <floorpic>           ;<string8>
  3451.                    <ceilingpic>         ;<string8>
  3452.                    <lightlevel>         ;<short>
  3453.                    <special_sector>     ;<short>
  3454.                    <tag>                ;<short>
  3455.  
  3456. <REJECT>        := <bitarray>           ;see [4-10] for this one
  3457.  
  3458. <BLOCKMAP>      := <xorigin>            ;<short>
  3459.                    <yorigin>            ;<short>
  3460.                    <xblocks>            ;<short>
  3461.                    <yblocks>            ;<short>
  3462.                    <listoffsets>
  3463.                    <blocklists>
  3464. <listoffsets>   := <listoffset> [numofblocks]
  3465. <listoffset>    := <ushort>
  3466. <numofblocks>   := <short>              ;note it equals <xblocks> * <yblocks>
  3467. <blocklists>    := <blocklist> [numofblocks]
  3468. <blocklist>     := <short: 0>           ;for dynamic thinglist pointer
  3469.                    <lines_in_block>
  3470.                    <short: -1>
  3471. <lines_in_block>:= <linedef_num> [...]  ;the numbers of all the <linedef>s
  3472.                                         ;that are in the block
  3473. <linedef_num>   := <short>
  3474.  
  3475.  
  3476. ----------------------------------
  3477. APPENDIX [A-2]: DOOM engine limits
  3478. ----------------------------------
  3479.  
  3480. Maximum width of a TEXTURE = NONE?
  3481. Maximum height of a TEXTURE = 128
  3482. Maximum edges in display that can have their sides rendered = 128 in 1.2
  3483.                                                               256 in 1.6+
  3484. Maximum blocks in a BLOCKMAP = about 13000, or 113 * 113
  3485. Maximum THINGS in view at once = 64, extras are not drawn
  3486. Maximum patches on a texture used on a
  3487.   2Sided "middle" texture before "medusa" effect = 1
  3488. Maximum # of "plats" = 30 (up/down moving floors, and lifts)
  3489.  
  3490. Maximum # of "scrolling" walls per level (line type 48) = 64
  3491.  
  3492.  
  3493. -------------------------------------------
  3494. APPENDIX [A-3]: DOOM.WAD changes and errors
  3495. -------------------------------------------
  3496.  
  3497.   There are some imperfections in the DOOM.WAD file. All versions up
  3498. to 1.666 have the SW18_7 lump included twice. Versions before 1.666
  3499. have the COMP03_8 lump twice. And with version 1.666 somebody really
  3500. messed up, because every single DP* and DS* and D_* lump that's in
  3501. the shareware DOOM1.WAD is in the registered DOOM.WAD twice. The error
  3502. doesn't adversely affect play in any way, but it does take up an
  3503. unnecessary 800k on the hard drive.
  3504.   
  3505.   Some of the lumps in the sprite section are unused. Versions before
  3506. 1.666 had PBULx0 and PSHEx0, x=A-B, which were pictures of bullet and
  3507. shell casings being ejected after the player fired a weapon (this
  3508. feature was obviously removed). Also there were four more "fireball"
  3509. sprite-lump sets: BAL3x0, BAL4x0, x=A-E, and BAL5x0 and BAL6x0, x=A-B.
  3510. The only unused lump left in 1.666 is SMT2A0, which is a small grey
  3511. stalagmite, similar to the SMIT sprite which is THING #47. There are
  3512. some new sprite lumps in version 1.666 of DOOM 1 which are "semi-unused"
  3513. because they aren't used in DOOM 1, but they ARE used in DOOM 2. They
  3514. are all projectile sprites, so it's probably just a little leftover
  3515. from compiling the WAD.
  3516.   
  3517.   So, in case it might help with converting demos, or for any other
  3518. reason, here is a list, entirely by Paul Falstad, of all the changes
  3519. to the levels between DOOM 1.2 and DOOM 1.666. The 1.4 and 1.5 beta's
  3520. levels are in most if not all respects identical to 1.666's - I haven't
  3521. checked.
  3522.  
  3523. E1M2
  3524. - Linedef #530 changed from a door that closes to one that stays open.
  3525.   This is the south side of the door out of the maze.  This allows
  3526.   deathmatch players who started in there to get out from the inside.
  3527.  
  3528. E1M4
  3529. - The swastika got changed to a different shape.  A bunch of things in
  3530.   the swastika room got moved around to accomodate the new layout.
  3531. - Thing #185 (a deathmatch start position) got moved from (768, 1952) to
  3532.   (736, 1824).  This is in the room with the ledge NW of the player 1
  3533.   starting room; the deathmatch start got moved off the ledge onto the
  3534.   main floor.
  3535.  
  3536. E1M5
  3537. - Thing #216 (a deathmatch start) got moved from (-2112, 512) to 
  3538.   (-800, 1200); that is, it got moved from the west courtyard (the one
  3539.   with the supercharger) to the hidden hallway just south of the pentagram.
  3540. - Sector #105's floor was lowered from 88 to 80.  In other words, the
  3541.   window west of the yellow keycard was enlarged a bit.  Also, the
  3542.   associated linedefs are no longer marked impassable.
  3543.  
  3544. E1M6
  3545. - Thing #116 (the sargeant in the middle of void space in the southeast
  3546.   corner of the map) got removed.
  3547. - Sectors #139 and #142 got their floor changed from FLOOR0_6 to FLOOR4_8
  3548.   for consistency with the surrounding sectors.  (These are the floors
  3549.   underneath the yellow doors on the northwest and northeast corners
  3550.   of one of the rooms.)
  3551.  
  3552. E1M7
  3553. - Linedef #782 was type 0; now it's type 31 (door that stays open).
  3554.   This is south side of the last door before the exit door; it can now
  3555.   be opened from the inside, so a deathmatch player that started in the
  3556.   exit room can get out.
  3557.  
  3558. E1M8
  3559. - The computer map in the pentagram got changed to a shotgun.
  3560. - Linedefs 35, 136, and 140 no longer have their upper textures unpegged.
  3561.   This is the secret door to the supercharger; it now looks like a real
  3562.   door when it opens.
  3563. - A secret door was added in the east baron's alcove. When you push on
  3564.   the east wall, a secret chamber opens with a switch.  That switch
  3565.   lowers the lift to the south, so that you can get back into the complex.
  3566.   (Though you could anyway, by jumping through the window on the west or
  3567.   east side of the hallway south of the lift...)
  3568.   Actually, it lowers the lift to the lowest adjacent floor, which
  3569.   (after the two barons are dead) is lower than the hallway floor
  3570.   height.  Probably not the intended effect.
  3571. - Vertex #223 got moved ever so slightly NW for some reason.
  3572.  
  3573. E2M4
  3574. - Northwest of the big green "O", there is a secret room with partial
  3575.   invisibility.  The door to the room closes when you walk north through
  3576.   a hallway just southwest of it; you're supposed to shoot the door to
  3577.   open it.  However, if you run north quickly over the trigger line and
  3578.   then run east through the door, you can just make it before the door
  3579.   closes, but in 1.2 you'd be trapped inside, since the door would not
  3580.   open from the east side.  In 1.666, the linedef type of the east edge
  3581.   of the door has been changed so that you can open the door from inside
  3582.   the secret room.
  3583.  
  3584. E3M1
  3585. - Sector 8's trigger number is now 0.  Previously, it was 6, which is the
  3586.   same number as one of the lines you walk over when getting the shotgun.
  3587.   This line would cause the floor to be lowered.  However, sector 8's floor
  3588.   is already lower than that of any adjacent sectors, so nothing happened.
  3589.  
  3590. E3M4
  3591. - Sidedefs 1327 and 1332 had their texture offsets fixed.  These are
  3592.   the sidedefs on either side of the window between the room with the
  3593.   beserker and the room with two spectres and a teleporter, east of
  3594.   the player one starting point.  Now, the window looks better than it
  3595.   did before, but still not perfect.
  3596.  
  3597. E3M6
  3598. - There is now a BFG9000 sitting in the northwest window in the building
  3599.   which you're facing at the start of the level.  It only appears in
  3600.   multiplayer mode.
  3601. - The structure which has the switch leading to the secret level had its
  3602.   north wall thickened, so that you can't trigger the switch from outside
  3603.   of the structure.
  3604.  
  3605.  
  3606. ------------------------------------
  3607. APPENDIX [A-3]: A BLOCKMAP algorithm
  3608. ------------------------------------
  3609.  
  3610. this section is being removed
  3611.  
  3612. ---------------------------------------
  3613. APPENDIX [A-4]: Other helpful documents
  3614. ---------------------------------------
  3615.  
  3616.   There are several other excellent sources of information about
  3617. DOOM, editing DOOM levels, changing the DOOM.EXE, and pwads.
  3618. Some of the following items get widely distributed (BBS, Usenet,
  3619. online services, FTP) and some don't. Three prominent FTP sites
  3620. with huge quantities of doom-related material are:
  3621.  
  3622.     infant2.sphs.indiana.edu    /pub/doom and subdirectories
  3623.                                   (../wad_edit/text has most documents)
  3624.     wuarchive.wustl.edu         /pub/msdos_uploads/games/doomstuff
  3625.     ftp.uwp.edu                 /pub/incoming/id
  3626.                                 /pub/msdos/games/id/home-brew/doom
  3627.  
  3628.   The infant2 site also has a number of mirrors.
  3629.   As time passes, newer versions of these documents may be released,
  3630. and/or the file names will change:
  3631.  
  3632. DESIGN12.ZIP    Level Design FAQ, edited by Tom Neff
  3633.                   Truly has lots of good questions, and good answers,
  3634.                   to common questions related to level design. Covers
  3635.                   the simple stuff, and some of the most advanced
  3636.                   topics too. Also, it is editor-nuetral, i.e. it
  3637.                   does not restrict itself to any single level editor.
  3638.                   Highly recommended.
  3639.  
  3640. DMFAQ666.ZIP    The Official DOOM FAQ 6.666 by Hank Leukart.
  3641.                   A huge collection of information about the history
  3642.                   of DOOM, notes on game play, and lists of add-on
  3643.                   utilities available to enhance play. 
  3644.  
  3645. DOOMBSP.ZIP     The source code from id's bsp routines, which build
  3646.                   the NODES structure and the REJECT and BLOCKMAP too.
  3647.                   If you want to see C, here it is.
  3648.  
  3649. METRICS.ZIP     "DOOM Metrics", by Scott Amspoker. Has some more info
  3650.                   and more explanations related to [4-2-2]: Thing Sizes,
  3651.                   and how monsters prefer stairs that aren't too steep.
  3652.  
  3653. TEXPATCH.ZIP    Textures To Patches, by Gregory Lewis. Shows the
  3654.                   patch composition of every texture in registered
  3655.                   DOOM.
  3656.               
  3657. TEXTURES.ZIP    "Managing Textures and the Unpegged Attribute", by
  3658.                   Scott Amspoker. Explains in great depth how textures
  3659.                   are drawn on walls, how the unpegged flag works, and
  3660.                   how texture offsets apply.
  3661.  
  3662. DH200.ZIP       DOOM.EXE Hack Editor, by Greg Lewis. This program
  3663.                   allows changes to be made to the DOOM.EXE file and
  3664.                   they can be saved/loaded via patch files. The thing
  3665.                   and frame tables (discussed in chapter [10]) are the
  3666.                   main emphasis of this excellent utility.
  3667.  
  3668. ???             "Fun with Dehacked", edited by Dan Lottero. Has a lot
  3669.                   of tips and tricks for using the DOOM.EXE Hack Editor
  3670.                   (dehacked).
  3671.  
  3672. ???             "Blackadder's DeHackEd Patch Reviews", by Michael Adcock.
  3673.                   Last updated 24Jul94?
  3674.  
  3675. ???             "DOOM Deathmatch Wad Ranking", by James Dicke and Jim
  3676.                   Urbas. Is a good system for rating how good and how
  3677.                   fun deathmatch play is on pwads. If you want to find
  3678.                   the best deathmatch levels, this is a good place to
  3679.                   start.
  3680.  
  3681. ???             pwad review documents and lists.
  3682.  
  3683. ???             "The unofficial LMP format description 1.0", by
  3684.                   Uwe Girlich
  3685.  
  3686. -------------------------------
  3687. APPENDIX [A-5]: Acknowledgments
  3688. -------------------------------
  3689.  
  3690.   The following people either brought mistakes to my attention, or
  3691. provided additional information that I've incorporated into these 
  3692. specs. Thanks for all the help! Sorry if I left anyone out. 
  3693.   If you have any comments or questions, have spotted any errors, 
  3694. or have any possible additions, please send me e-mail. If you've 
  3695. contacted me before, please note my new address (msfell@aol.com).
  3696.  
  3697. id Software
  3698.         Created DOOM, added the -file parameter, used a simple format
  3699.         for the WAD, and occasionaly released specifications and
  3700.         technical information about DOOM and DOOM 2 :-)
  3701.  
  3702. All PWAD designers and doom-utility programmers everywhere!
  3703.  
  3704. Coleman Reed Ammerman (cammer@cs.tamu.edu) and John Wolsh
  3705.         They were the first to document the DEMO format.
  3706.  
  3707. Scott Amspoker (scott@bbx.basis.com)
  3708.         Wrote the METRICS and TEXTURES articles.
  3709.  
  3710. Jeff Bird (jeff@wench.ece.jcu.edu.au)
  3711.         Good ideas about the NODES, and a blockmap algorithm.
  3712.  
  3713. Alistair Brown (A.D.Brown@bradford.ac.uk)
  3714.         Helped me understand the NODES and explained REJECT.
  3715.  
  3716. Frans P. de Vries (fpdevries@hgl.signaal.nl)
  3717.         The cool ASCII DOOM logo used for the header. Also, gave a
  3718.         comprehensive list of typos and mistakes in the 1.3 specs.
  3719.  
  3720. Paul Falstad (pjf@crash.cts.com)
  3721.         I got ALL of the [8-6-1] information from his messages. 
  3722.  
  3723. Robert Fenske (rfenske@swri.edu)
  3724.         Passed along a great linedef flag list. Also helped with linedef
  3725.         types, blockmap, special sectors, and general suggestions.
  3726.  
  3727. Nelson Fernandez Jr. (nelson@netcom.com)
  3728.         Distributed information about savegame files.
  3729.  
  3730. Uwe Girlich (girlich@aix520.informatik.uni-leipzig.de)
  3731.         Wrote "The unofficial LMP format description 1.0"
  3732.  
  3733. Stuart Herbert (ac3slh@sunc.sheffield.ac.uk)
  3734.         Clarifying how pegged/unpegged flags work.
  3735.  
  3736. Herre de Jonge (herre@morra.et.tudelft.nl) 
  3737.         First pointed out the stairs mistake in the 1.3 specs.
  3738.  
  3739. Tom Klok (a344@mindlink.bc.ca)
  3740.         DMXGUS and MUS file format info.
  3741.  
  3742. Bernd Kreimeier (bernd@nero.uni-bonn.de)
  3743.         Wrote DMADDS11. Sprites, savegames, sounds, and lots of other help.
  3744.  
  3745. Steve Larsen (larsen@sunset.cs.utah.edu)
  3746.         Several patches for the DOOM.EXE file
  3747.  
  3748. Hank Leukart (ap641@cleveland.freenet.edu)
  3749.         Edits the DOOM FAQ and distributes these specs!
  3750.  
  3751. Greg Lewis (gregl@umich.edu)
  3752.         Wrote DeHackEd, and gave lots of info on EXE variables.
  3753.  
  3754. Joel Lucsy (jjlucsy@mtu.edu)
  3755.         Info on COLORMAP and PLAYPAL.
  3756.  
  3757. Sean Malloy (malloy@nprdc.navy.mil)
  3758.         Step-by-step proof of exactly how stairs work.
  3759.  
  3760. John A. Matzen (jamatzen@cs.twsu.edu)
  3761.         Instrument names in GENMIDI.
  3762.  
  3763. Steve McCrea (sm@eng.cam.ac.uk)
  3764.         Animated textures and textures larger than 256 wide.
  3765.  
  3766. Brian McKimens (samneric@connected.com)
  3767.         Comprehensive work on linedefs' function types.
  3768.  
  3769. Tom Neff (tneff@panix.com)
  3770.         Edits (writes) the DESIGNxx.FAQ. Suggested BNF and wrote the
  3771.         intro to [A-1]. Created the WIF text standard. General advice.
  3772.  
  3773. Tom Nettleship (mastn@midge.bath.ac.uk)
  3774.         Explained BSP trees in comp.graphics.algorithms messages.
  3775.  
  3776. Elias Papavassilopoulos (ep104@cus.cam.ac.uk)
  3777.         Tons of technical info on EXE files in general and DOOM.EXE.
  3778.  
  3779. Robert D. Potter (potter@bronze.lcs.mit.edu)
  3780.         Theory about what BLOCKMAP is for and how the engine uses it.
  3781.  
  3782. Raphael Quinet (eedraq@chapelle.ericsson.se)
  3783.         Lots of rigorous contributions on linedef types and special 
  3784.         sectors. Not to mention DEU!
  3785.  
  3786. Colin Reed (dyl@cix.compulink.co.uk)
  3787.         I had the x upper and lower bounds for node bounding boxes 
  3788.         backwards a few versions ago.
  3789.  
  3790. Joost Schuur (jschuur@studserv.zdv.uni-tuebingen.de)
  3791.         Runs the doom-editing mailing list.
  3792.  
  3793. Steve Simpson (ssimpson@world.std.com)
  3794.         Corrected an error in the PNAMES section
  3795.  
  3796. S. Sproston (S.Sproston-SE2@cs.bham.ac.uk)
  3797.         Excellent work on linedef types.
  3798.  
  3799. Matt Tagliaferri (matt.tagliaferri@pcohio.com)
  3800.         Pointed out omission of TEXTURE1/2 pointer table in the 1.1
  3801.         specs. Also provided a good BLOCKMAP algorithm.
  3802.  
  3803. Ted Vessenes (tedv@geom.umn.ed)
  3804.         I had the THING angles wrong in the original specs.
  3805.  
  3806. You! Thanks for reading the "Unofficial" DOOM Specs!
  3807.  
  3808.  
  3809.  
  3810.  
  3811.  
  3812.