Supergames 2/SupergamesVolume2.bin/faqs/dspec1.2

Text File | 1994-03-07 | 60KB | 1,368 lines

-----------------------------------------------------------------------------
       T H E   U N O F F I C I A L   *-D-*-*-O-*-*-O-*-*-M-*   S P E C S
                       Release v1.2 - March 6, 1994 EST
                  Written by: Matt Fell ([e-mail])
              Released by: Hank Leukart ([e-mail])
          "DOOM: Where hackers gnaw the bones left from the banquet
                 of data prepared by the mighty wizards of id."
           "The poets talk about love, but what I talk about is DOOM,
                 because in the end, DOOM is all that counts."
           - Alex Machine/George Stark/Stephen King, _The Dark Half_
-----------------------------------------------------------------------------

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

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

---------
COPYRIGHT
---------

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

------------
INTRODUCTION
------------

        Here are the long awaited unofficial specs for DOOM.  These specs
should be used for creating add-on software for the game. I would like to
request that these specs be used in making utilities that ONLY work on the
registered version of DOOM.
        I do not understand much of what is contained in this file, so if
you have any questions about the information, write to Matt Fell at
"[e-mail]" on the Internet.  If you would like to request a
copy of this file, or have any questions about its distribution, write to me,
Hank Leukart, at "[e-mail]" on the Internet.

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

[1] Author's Notes
        [1-1] Acknowledgements
[2] Basics
[3] Directory Overview
[4] The Maps, The Levels
        [4-1] ExMy
        [4-2] THINGS
                [4-2-1] Thing Types
        [4-3] LINEDEFS
                [4-3-1] Linedef Attributes
                [4-3-2] Linedef Types
        [4-4] SIDEDEFS
        [4-5] VERTEXES
        [4-6] SEGS
        [4-7] SSECTORS
        [4-8] NODES
        [4-9] SECTORS
        [4-10] REJECT
        [4-11] BLOCKMAP
[5] Pictures' Format
        [5-1] Headers
        [5-2] Pointers
        [5-3] Pixel Data
[6] Floor and Ceiling Textures
        [6-1] Animated floors
[7] Songs and Sounds
        [7-1] Songs
        [7-2] Sounds
[8] Miscellaneous Non-Picture Resources
        [8-1] PLAYPAL
        [8-2] COLORMAP
        [8-3] DEMOs
        [8-4] TEXTURE1 and TEXTURE2
                [8-4-1] Animated walls
        [8-5] PNAMES

---------------------------
CHAPTER [1]: Author's Notes
---------------------------

I didn't want to release another incomplete version of the specs, but
the NODES structure is so much more difficult than all of the other stuff,
I'm not sure how much longer it will be until either I or someone
helping me can figure it out. Since I have almost complete information
on everything else, I felt I should go ahead and release this now.

Without knowing how to do the NODES, we still can't create levels from
scratch. So these specs will have to undergo another revision. I've heard
rumors of the hint book, with the official specs, being released "soon";
if anyone knows more about this, or if they get the book, please contact me.

I haven't kept track of all the minor revisions that have been made since
1.1, sorry. You can get rid of the 1.1 specs, as this has everything it
had except the errors :-)

id SOFTWARE'S COPYRIGHT AND THE SHAREWARE VERSION:

I'm moving the location of the soapbox I had in the 1.1 Specs to here. I'm
certainly not an official spokesman for id. I have made some inquiries to
them regarding specific questions on third-party additions. Until they
respond, though, I'll just make a couple excerpts from the official
documents we have at this time:


The LICENSE.DOC says

       "You may not:  rent, lease, modify, translate, disassemble,
        decompile, reverse engineer, or create derivative works based
        upon the Software. Notwithstanding the foregoing, you may create
        a map editor, modify maps and make your own maps (collectively
        referenced as the "Permitted Derivative Works") for the Software.
        You may not sell or distribute any Permitted Derivative Works but
        you may exchange the Permitted Derivative Works at no charge
        amongst other end-users."

It also says

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

I think this is clear. You may not distribute a WAD file that contains
any of the original entries from DOOM.WAD.

Then how can you just make a new set of THINGS for a level? Simple. Have
a pwad file that has only two entries - E3M1 for example, and THINGS.

The README.EXE says

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

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

I feel that this is also pretty clear: if you distribute levels, they should
not work with the shareware version. This is easily accomplished: do
not distribute ANY episode one maps! The shareware version cannot work
with episode 2 or 3 pwads, but it can work with episode 1 pwads (they
should have disabled the -file feature in the shareware).

If you are writing a utility that will operate on DOOM, have it first check
the WAD file for the existence of an "E3M1" entry in the directory (explained
below), or some other entry that will only be in the registered version.
If it's not there, the program should quit. You should not be making
programs that will work on the shareware version.

The point is that the regular shareware players shouldn't be able to exceed
their rights. They are getting a complete game as it is!

[1-1]: Acknowledgements
=======================

I have received much assistance lately from the following people. They
either brought mistakes to my attention, or provided additional information
that I've incorporated into these specs:

Ted ([e-mail]) - I had the THING angles wrong. Unforgivable.
Matt Tagliaferri ([e-mail]) - I forgot to describe the
        TEXTURE1/2 pointer table. Also, gave lots of help with linedef types.
Raphael Quinet ([e-mail]) - The author of the NEWDEU
        editor; new info on linedef types and attributes, special sectors.
Robert Fenske ([e-mail]) - part of the VERDA team, gave lots of help
        on linedef attributes and types, blockmap list, special sectors,
        and other stuff
John A. Matzen ([e-mail]) - instrument names in GENMIDI.
Jeff Bird ([e-mail]) - good ideas and suggestions about
        the nodes.

Sorry if I left anyone out. Thanks for all the help!

If you have any comments, have spotted any errors, or have any possible
additions, please send me e-mail. Questions will be gladly answered also,
no matter how trivial, unless I get too many, which I doubt. Please note,
however, that if it's not in here, I'm either working on it or I just don't
know it. If YOU know "it", tell me!

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

Don't make episode 1 maps! Don't make utilities that work on the shareware
version!  For more information on this, see Chapter [1].

There are two types of WAD files. The original DOOM.WAD file is an "IWAD",
meaning it contains all of the data necessary to play. The other type is the
"PWAD" file, an external file which has the same structure, but with far
fewer entries in the directory (explained below). The data in a PWAD is
substituted for the original data in the DOOM.WAD, thus allowing for much
easier distribution of new levels. Only what the PWAD wants to change is
changed, everything else stays the same. Most PWADs will contain the 11
entries necessary to define a single level. For example, if Bill Clinton
were to create a new level 7 for episode 3, he might call it BILLC-37.WAD

To use this level instead of the original E3M7 level, a player would type

DOOM -FILE BILLC-37.WAD

at the command line, along with any other parameters. More than one can be
done at the same time, thus in general

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

When the game loads, a "modified game" message will appear if there are any
PWADs involved, reminding the player that id Software will not give technical
support or answer questions regarding modified levels.

Note that PWAD files must have the .WAD extension to work - I've tried
extensions like .PWD and .37 and they don't work.

The original doom levels are pretty complicated, and they are from 50-200
kilobytes in size, uncompressed. My simple prototype levels are just a
few kbytes. I'm estimating that my first epsiode 2 with 9 complete levels
plus a few other things, will be about 1 megabyte uncompressed, about 300k
in a ZIP file.

The first twelve bytes of a WAD file are as follows:

Bytes 0 to 3 - must contain the ASCII letters "IWAD" or "PWAD"

Bytes 4 to 7 - contain a long integer which is the number of entries in the
               "directory"

Bytes 8 to 11 - contain a pointer to the first byte of the "directory"

(Bytes 12 to the start of the directory contain resource data)

The directory referred to is a list, located at the end of the WAD file,
which contains the pointers, lengths, and names of all the resources in the
WAD file. The resources in the wad include item pictures, monster's pictures
for animation, wall patches, floor and ceiling textures, songs, sound
effects, map data, and many others.

Specifically, the first 12 bytes of the DOOM.WAD file in version 1.2, which
I am working with, are (in hexadecimal):

49 57 41 44 fd 07 00 00 84 2e 9e 00

This is "IWAD", then 7fd hex (=2045 decimal) for the number of directory
entries, then 9e2e84 (=10366596 decimal) for the first byte of the directory.

Each directory entry is 16 bytes long, arranged this way:

First four bytes:       pointer to start of resource (a long integer)
Next four bytes:        length of resource (another long integer)
Last eight bytes:       name of resource, in ASCII letters, ending with
                        00s if less than eight bytes.

-------------------------------
CHAPTER [3]: Directory Overview
-------------------------------

This is a list of most of the directory entries.

PLAYPAL   contains fourteen 256 color palettes, used while playing Doom.
COLORMAP  maps colors in the palette down to darker ones, for areas of less
          than maximum brightness (quite a few of these places, huh?).
ENDOOM    is the text message displayed when you exit to DOS.
DEMOx     x=1-3, are the demos which will play if you just sit and watch.

E1M1      etc, to E3M9, along with its 10 subsequent entries, defines the
          map data for a single level or mission.

TEXTURE1  is a list of wall type names used in the SIDEDEF portion of each
          level's data, and their composition data, i.e. what wall patches
          make up each "meta-wall".
TEXTURE2  contains the walls that are only in the registered version.
PNAMES    is the list of wall patches, which are referenced by number in
          the TEXTURE1/2 resources.

GENMIDI   has the names of every General Midi standard instrument in order
          from 0-127. Anyone know more...?
DMXGUS    obviously has to do with Gravis Ultra Sound...

D_ExMy    is the music for episode x level y.
D_INTER   is the music played on the summary screen between levels.
D_INTRO   is the the 4 second music played when the game starts.
D_INTROA  is also intoductory music.
D_VICTOR  is the music played on the victory text-screen after an episode.
D_BUNNY   is music for while a certain rabbit has his story told...

DP_xxxxx  DP and DS come in pairs and are the sound effects.
DS_xxxxx     DP_ are the PC speaker sounds, DS_ are the sound card sounds.

all the remaining entries in the directory, except the floor textures at the
end, and the "separators" like S_START, refer to resources which are pictures
in the doom/wad picture format described in chapter [4].

The next seven are full screen (320 by 200 pixel) pictures:

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

ENDx      x=0-6, "THE END" text, with (x) bullet holes.

AMMNUMx   x=0-9, are the grey digits used in the status bar for ammo count.
STxxxxxx  are small pictures and text used on the status bar.
M_xxxxxx  are text messages (yes, in picture format) used in the menus.
BRDR_xxx  are tiny two pixel wide pictures use to frame the viewing window
          when it is not full screen.
WIxxxxxx  are pictures and messages used on the summary screen after
          the completion of a level.
WIMAPx    x=0-2, are the summary-screen maps used by each episode.

S_START   has 0 length and is right before the item/enemy section
S_END     is immediately after the last "sprite"
P_START   marks the beginning of the wall patches
P1_START      before the first of the shareware wall patches
P1_END        after the last of the shareware wall patches
P2_START      before the first of the registered wall patches
P2_END        before the first of the registered wall patches
P_END     marks the end of the wall patches
F_START   marks the beginnning of the floors
F1_START      before the first shareware floor texture
F1_END        after the last shareware floor texture
F2_START      before the first registered floor texture
F2_END        after the last registered floor texture
F_END     marks the end of the floors

And that's the end of the directory. Detailed info on specific resources
follows...

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

Each level needs eleven resources/directory entries: E[x]M[y] (where x is a
single digit 1-3 for the episode number and y is 1-9 for the mission/level
#), THINGS, LINEDEFS, SIDEDEFS, VERTEXES, SEGS, SSECTORS, NODES, SECTORS,
REJECT, BLOCKMAP.

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

This is just the name resource for a (single) level, and has zero length.
In the DOOM.WAD file, each is followed by all ten of the component resources
for that level. In a pwad external file, they don't all need to be present.
Whichever entries are in a pwad will be substituted for the originals.
For example, a pwad with just two entries, E3M1 and THINGS, would use all
the walls and such from the original E3M1, but could have a completely
different set of THINGS on it.

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

Each thing is ten bytes, consisting of five (integer) fields:

(1) X coordinate of thing
(2) Y coordinate of thing

Each level has a different "range" to its coordinates. On E1M1, X ranges
from (c.) -288 to +3440, and Y ranges from (c.) -4832 to -2144.
On the automap within the game, with the grid on (press 'G'), the lines are
hex 80 (decimal 128) apart, two lines = hex 100, dec 256.

(3) Angle the thing faces. On the automap, 0 is east, 90 is north, 180 is
    west, 270 is south.

This value is only used for enemies, player starts, deathmatch random starts,
and teleporter incoming spots. Other things look the same from all
directions. Values are rounded to the nearest 45 degree angle, so if the
value is 80, it will actually face 90 - north.

(4) Type of thing, see next subsection
(5) Attributes of thing, which are set by bits:

bit 0   is set if the THING is present at skill 1 and 2
bit 1   is set if the THING is on skill 3 (hurt me plenty)
bit 2   is set if the THING is on skill 4 and 5 (ultra-violence, nightmare)

        The skill settings are most used with the ENEMIES, of course...the
        most common skill level settings are hex 07/0f (on all skills),
        06/0e (on skill 3-4-5), and 04/0c (only on skill 4-5).

bit 3   is set to indicate a deaf guard. This only has meaning for enemies,

        who will not attack until they see a player if they are "deaf".
        Otherwise, they will activate when they hear gunshots, etc. Sound
        does not travel through solid walls (walls that are solid at the
        time of the noise). Also, lines can be set so that sound does not
        pass through them (see [3-3-1] bit 6). This attribute is also
        known as the "ambush" attribute.

bit 4   makes the THING only appear in multiplayer mode.

bits 5-15 have no effect.

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

Bytes 6-7 of each thing are an integer which specifies what kind it is.

Symbol  means

CAPITAL It's a monster; counts towards KILL ratio at end of level.
$       A regular item that you can get.

!       An artifact item whose acquisition counts towards the ITEM ratio
        at the end of a level
*       An obstacle, something that players and monsters can't move through.
2,3,4   Indicates number of different frames for animated things, except
        monsters

Decimal Hex     Thing is:

0       0000    (nothing?)
1       0001    Player 1 start
2       0002    Player 2 start for cooperative mode multiplayer games.
3       0003    Player 3 start          "                "
4       0004    Player 4 start          "                "
5       0005 2$ Blue keycard
6       0006 2$ Yellow keycard
7       0007  * SPIDER DEMON: giant walking brain boss (SPID)
8       0008 2$ Backpack
9       0009  * FORMER HUMAN SERGEANT: black armor shotgunners (SPOS)
10      000a    Bloody mess (an exploded player)
11      000b    Deathmatch start positions. Must be at least 4 per level.
12      000c    Bloody mess, exactly the same as 10
13      000d 2$ Red Keycard
14      000e    Marks the spot where a player (or enemy) lands when
                they teleport to the SECTOR that contains this thing.
15      000f    Dead player
16      0010  * CYBER-DEMON: robo-boss, rocket launcher (CYBR)
17      0011  $ Cell charge pack
18      0012    Dead former human
19      0013    Dead former sargeant
20      0014    Dead imp
21      0015    Dead demon
22      0016    Dead cacodemon
23      0017    Dead lost soul, invisible since they blow up when killed
24      0018    Pool of blood
25      0019  * Impaled human
26      001a 2* Twitching impaled human
27      001b  * Skull on a pole
28      001c  * 5 skulls shishkebob
29      001d 2* Pile of skulls and candles
30      001e  * Tall green pillar
31      001f  * Short green pillar
32      0020  * Tall red pillar
33      0021  * Short red pillar
34      0022    Candle
35      0023  * Candelabra
36      0024 2* Short green pillar with beating heart
37      0025  * Short red pillar with skull
38      0026 2$ Red skullkey
39      0027 2$ Yellow skullkey
40      0028 2$ Blue skullkey
41      0029 3* Eye in symbol
42      002a 3* Flaming skull-rock
43      002b  * Grey tree
44      002c 4* Tall blue firestick
45      002d 4* Tall green firestick
46      002e 4* Tall red firestick
47      002f  * Small brown scrub
48      0030  * Tall, techno column
49      0031 3* Hanging victim, swaying, legs gone
50      0032  * Hanging victim, arms out
51      0033  * Hanging victim, 1-legged
52      0034  * Hanging victim, upside-down, upper body gone
53      0035  * Hanging severed leg
54      0036  * Large brown tree
55      0037 4* Short blue firestick
56      0038 4* Short green firestick
57      0039 4* Short red firestick
58      003a  * SPECTRE: invisible version of the DEMON (SARG)
59      003b    Hanging victim, arms out
60      003c    Hanging victim, upside-down, upper body gone
61      003d    Hanging victim, 1-legged
62      003e    Hanging severed leg
63      003f 3  Hanging victim, swaying, legs gone

2001    07d1  $ Shotgun
2002    07d2  $ Chaingun, gatling gun, mini-gun, whatever
2003    07d3  $ Rocket launcher
2004    07d4  $ Plasma gun
2005    07d5  $ Chainsaw

2006    07d6  $ BFG9000
2007    07d7  $ Ammo clip
2008    07d8  $ 4 shotgun shells
2010    07da  $ 1 rocket
2011    07db  $ Stimpak
2012    07dc  $ Medikit
2013    07dd 4! Soulsphere, Supercharge, +100% health
2014    07de 4! Health bonus
2015    07df 4! Armor bonus
2018    07e2 2$ Green armor 100%
2019    07e3 2$ Blue armor 200%
2022    07e6 4! Invulnerability
2023    07e7  ! Berserk Strength
2024    07e8 4! Invisibility
2025    07e9  ! Radiation suit
2026    07ea 4! Computer map
2028    07ec  * Floor lamp
2035    07f3 2* Barrel - if blown up, doesn't block way anymore.
2045    07fd 2! Lite goggles
2046    07fe  $ Box of Rockets
2047    07ff  $ Cell charge
2048    0800  $ Box of Ammo
2049    0801  $ Box of Shells

3001    0bb9  * IMP: brown fireball hurlers (TROO)
3002    0bba  * DEMON: pink bull-like chewers (SARG)
3003    0bbb  * BARON OF HELL: cloven hooved boss (BOSS)
3004    0bbc  * FORMER HUMAN: regular pistol shooting slimy human (POSS)
3005    0bbd  * CACODEMON: red one-eyed floating heads. Behold... (HEAD)
3006    0bbe  * LOST SOUL: flying flaming skulls, like to bite (SKUL)

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

Each linedef represents a line from one of the VERTEXES to another, and each
is 14 bytes, containing 7 (integer) fields:

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

"right" and "left" are based on the direction of the linedef as indicated
by the "from" and "to" VERTEXES. This attempt at a sketch should make it
clear what I mean:

        "left" side            "right" side
 FROM -----------------> TO <----------------- FROM
        "right" side           "left" side

In the original episodes, a line with a single side ALWAYS has that side
as the "right" side. So it would probably be best to follow the convention.

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

The third field of each linedef is an integer which controls that line's
attributes with bits, as follows:

bit #   condition if it is set (=1)

bit 0   Impassibile. Players and monsters cannot cross this line, and
        projectiles explode or "end" if they hit this line. Note, however,
        that if there is no sector on the other side, beings can't go through
        this line anyway. Important: if bit 2 is also set, projectiles CAN go
        through the line, and if there is no sector on the other side, they
        can go "forever", usually causing a CRASH.

bit 1   Monster-blocker. Monsters cannot cross this line.

bit 2   Two-sided. If this bit is set, then the linedef's two sidedefs can
        have "-" as a texture, which means "transparent". If this bit is not
        set, the sidedefs can't be transparent: if "-" is viewed, it will
        result in the same hyper-junk that you see when you use the walk-
        thru-walls cheat to go outside into nowhere. However, the linedef CAN
        have two non-transparent sidedefs, even if this bit is not set, if it
        is between two sectors.

        Another side effect of this bit is that if it is set, then
        projectiles can go through it no matter what, and gunfire (pistol,
        etc.) can go through it if there is a sector on the other side.

bit 3   Upper texture is "unpegged". This is usually done at windows.
        "Pegged" textures move up and down when the neighbor sector moves up
        or down. For example, if a ceiling comes down, then a pegged texture
        on its side will move down with it so that it looks right. If the
        side isn't pegged, it just sits there, the new material is
        spontaneously created. The best way to get an idea of this is to
        change a linedef on an elevator or door, which are always pegged,
        and observe the result.

bit 4   Lower texture is unpegged.

bit 5   Secret. The automap will draw this line like a normal solid line that
        doesn't have anything on the other side, thus protecting the secret
        until it is opened. This bit is NOT what determines the SECRET ratio
        at the end of a level, that is done by special sectors (#9).

bit 6   Blocks sound. Sound cannot cross a line that has this bit set.

        Sound normally travels from sector to sector, so long as the floor
        and ceiling heights allow it (e.g. sound wouldn't go from a sector
        with 0/64 floor/ceiling height to one with 72/128, but sound WOULD
        go from a sector with 0/64 to one with 56/128).

bit 7   Not on map. The line is not shown on the regular automap, not even if
        the computer all-map power up is gained. All lines show up on the
        cheater's map, however (Booooo! I wish there were no cheat codes!)

bit 8   Already on map. When the level is begun, this line is already on the
        automap, even if it hasn't been "seen" yet.

bits 9-15 are unused, EXCEPT for a large section of e2m7, where every wall
        on the border of the section has bits 9-15 set, so they have values
        like 1111111000000000 (-511) and 1111111000010000 (-495). This area
        of e2m7 is also the only place in all 27 levels where there is a
        linedef 4 value of -1. But the linedef isn't a switch. These unique
        values either do nothing, or something that is as yet unknown. The
        currently prevailing opinion is that they do nothing.

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

The integers in field 4 of a linedef control various special characteristics,
mostly to do with what happens to a "triggered" SECTOR when the line is
crossed or activated by a player.

Except for "Doors", the end-level switches, and the special type 48 (hex 30),
all these effects need "trigger" or "tag" numbers. Then any and all sectors
whose last field contains the same trigger number are affected when the
linedef's function is activated.

What the letters in the ACT column mean:

W means the function happens when a player WALKS across the linedef. S means
a player must push SPACEBAR near the linedef to activate it (doors and
switches). G means a player must shoot the linedef (GUN).

1 means it works once only. R means it is a repeatable function. This is
tentative, because some functions that appear to work only once might
actually work again if the conditions were reset. E.g. a sector ceiling
rises, opening a little room with baddies in it. Usually, that's it. But
perhaps if some other linedef triggered that sector ceiling to come down
again, then the original trigger could make it go up, etc...

Dec/Hex   ACT   EFFECT

-1 ffff   ? ?   None? Only once in whole game, on e2m7, (960,768)-(928,768)
0    00   - -   nothing
1    01   S R   Door. Sector on the other "side" of this line has its
                ceiling rise c. 96 in altitude, then comes back down
                after c. 5 seconds.
2    02   W 1   ceiling rises like door
3    03   W 1   ceiling lowers
5    05   W 1   floor rises to match neighbor sector floor height.
7    07   S 1   staircase rises up from floor in appropriate sectors.
8    08   W 1   stairs

Note: The stairs function requires special handling. In the original
episodes,
an even number of steps get raised up; the first step and every other one
thereafter are sectors which have the "trigger" number that the control
linedef has, OR they (the sectors/steps) will have 999 or 99 as their
trigger number. I can't figure out why the game uses the 999 thing, since
just using the original trigger number works fine. Also, I don't know yet
if all the steps must be the same size/shape, as they always are in real-map
examples.

9    09   S 1   floor lowers; neighbor sector's floor rises and changes
                TEXTURE to match yet another neighbor, and sector special
                type changes to 0.
10   0a   W 1   floor lowers, wait 3 seconds, rises
11   0b   S -   End level. Go to next level.
13   0d   W 1   brightness goes to 255
14   0e   S 1   floor rises to c. 64 above neighbor sector's floor
16   10   W 1   ceiling closes, opens after c. 30 seconds.
18   12   S 1   floor rises to equal first neighbor "on the way up"
19   13   W 1   floor lowers to equal the highest of the neighboring
                sector's floors
20   14   S 1   floor rises, TEXTURE change also.
21   15   S 1   floor lowers to equal, for c. 3 seconds, then rises back
                up to stop 8 below neighbor's ceiling height
22   16   W 1   floor rises, TEXTURE change also
23   17   S 1   floor lowers to match LOWEST neighbor sector?
26   1a   S R   Door. Need blue key to open. Closes after 5 seconds.
27   1b   S R   Door. Yellow key.
28   1c   S R   Door. Red key.
29   1d   S 1   ceiling rises, closes after c. 6 seconds?
30   1e   W 1   floor rises to c. 100-128 above neighbor's floor?
31   1f   S 1   Door. Stays open.
32   20   S 1   Door. Blue key. Stays open.
33   21   S 1   Door. Yellow key. Stays open.
34   22   S 1   Door. Red key. Stays open.
35   23   W ?   brightness goes to 0.
36   24   W ?   lower floor to 8 above neighbor.

37   25   W 1   floor lowers, change floor to acid (special sector 7).
38   26   W 1   floor lowers
39   27   W 1   teleport to sector. make sure only one sector has the same
                trigger number as a line with this effect!
40   28   W 1   ceiling raises, like 2?
41   29   S 1   ceiling lowers to floor
42   2a   S R   ceiling closes like door
44   2c   W 1?  ceiling lowers to 8 above floor
46   2e   G 1   Shoot this line, then sector ceiling rises like a door
48   30   - -   Animated, horizontally scrolling wall.
51   33   S -   End level. Go to secret level 9.
52   34   W -   End level. Go to next level
56   38   W ?   crushing floor rises to 8 below ceiling
58   3a   W 1   floor rises c. 24-48
59   3b   W 1   floor rises 8, TEXTURE change to neighbor also
61   3d   S R   ceiling rises like door
62   3e   S R   floor lowers, rises after c. 3 seconds
63   3f   S R?  ceiling rises, lowers after c. 3 seconds
70   46   S R   sector floor drops quickly to 8 above neighbor
73   49   W R   start crushing ceiling, slow crush but fast damage
74   4a   W R   stops crushing ceiling
75   4b   W R   ceiling closes, and ?
76   4c   W ?   ceiling closes like door, opens after c. 10 seconds
77   4d   W R   start crushing ceiling, fast crush but slow damage
80   50   W 1?  brightness to 255
82   52   W R   floor lowers to equal neighbor
86   56   W R   ceiling rises, closes after c. 5 seconds
87   57   W R?  floor rises and lowers every 5 seconds
88   58   W R   floor lowers quickly, rises back up after c. 3 seconds
89   59   W R?  stops the up/down syndrome started by #87
90   5a   W R   ceiling rises, wait 5 seconds, comes down
91   5b   W R   floor rises to (neighbor ceiling - 8)
97   61   W R   teleport to sector. make sure only one sector has the same
                trigger number as a line with this effect!
98   62   W R   floor lowers to 8 above neighbor
102  66   S ?   floor lowers to equal neighbor
103  67   S 1?  ceiling rises like door, stays open
104  68   S 1   light drops to lowest light level amongst neighbor sectors

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

A sidedef is a definition of what wall meta-textures to draw along a LINEDEF,
and a group of sidedefs define a SECTOR.

There will be one sidedef for a line that borders only one sector, since it
is not necessary to define what the doom player would see from the "other"
side of that line because the doom player can't go there. The doom player
can only "go" where there is a sector (unless you use the no clipping cheat,
which will cause the screen to freak out if you go "outside" to a non-sector
area).

Each SIDEDEF is 30 bytes, comprising 2 (integer) fields, then 3 (8-byte
string) fields, then a final (integer) field:

(1) X offset for pasting the appropriate wall texture onto the wall's
    "space": positive offset moves "into" the texture, so the left portion
    gets cut off (# of columns off left side = offset). Negative offset moves
texture
    farther right, in the wall's "space"
(2) Y offset: analogous to the X, for vertical.

(3) "upper" texture name: the part "above" the juncture with a lower ceiling
    of an adjacent SECTOR.
(4) "lower" texture name: the part "below" a juncture with a higher floored
    adjacent SECTOR.
(5) "full" texture name: the regular part of the wall

    The texture names are from the TEXTURE1/2 resources. The names of wall
    patches in the DIRECTORY are not directly used, they are referenced
    through PNAMES.

    Simple sidedefs have no upper or lower texture, and so they will have
    "-" instead of a texture name. Also, two-sided lines can be transparent,
    in which case "-" means transparent (no texture)

    00s fill the space after a wall name that is less than 8 characters.

(6) SECTOR that this sidedef "helps to surround" or "faces"

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

These are the beginnings and ends for LINEDEFS and SEGS, each is 4 bytes,
2 (integer) fields:

(1) X coordinate
(2) Y coordinate

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

The SEGS are in a sequential order determined by the SSECTORS, which are
part of the NODES recursive tree.

Each SEG is 12 bytes, having 6 (integer) fields:

(1) from VERTEX with this number
(2) to VERTEX

(3) angle: 0= east, 16384=north, -16384=south, -32768=west.
    In hex, it's 0000=east, 4000=north, 8000=west, c000=south.

(4) LINEDEF that this seg goes along
(5) 0 = this seg is on the front "side" of the linedef.
    1 = this seg is on the back "side" of the linedef.

    This could also be thought of as direction: 0 if the seg goes the same
    direction as the linedef it's on, 1 if it goes the opposite direction.

(6) Is the distance along the linedef that the seg begins. If the seg begins
    at one of the two endpoints of the linedef, this will be 0. If the seg
    and linedef are a "diagonal" line, the length will be according to the
    distance in the coordinate plane of the vertexes, i.e.

    SQR((X2 - X1)^2 + (Y2 - Y1)^2).

    Actually, it seems to be off by 1 or 2 from what it should be, like they
    are using ABS(X2 - X1) values that are 1 less than the "real" value
    should be.

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

Each SSECTOR is 4 bytes, having 2 (integer) fields

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

Ssector stands for sub-sector. These divide up all the SECTORS into
non-convex polygons. They are then referenced through the NODES resources.

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

This is what we need to figure out!

The nodes are branches in a binary space partition that divides up the level
and is used to determine which walls and floors are in front of others, thus
"clipping" the walls behind from the virtual view. The nodes/ssectors/segs
resources are used exclusively for these display purposes, and seem to be
precalculated to ease the burden on the game engine.

There are ((number of SSECTORS) - 1) NODES. Each NODE has 14 (integer)
fields:

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

     thus 64, 128, -64, -64 would be a partition line from (64,128) to (0,64)

(5)  Y upper bound for the first bounding-box
(6)  Y lower bound
(7)  X upper bound
(8)  X lower bound

(9)  Y upper bound for the second bounding box
(10) Y lower bound
(11) X upper bound
(12) X lower bound

     Each node has two "children", each of which is either a node or a
     ssector. The bounding box is just big enough to contain whatever is
     in the "child", e.g. if the child is a ssector with 1 seg, then the
     bounding box will be just big enough to contain the extents of the
     seg (and thus a bounding "box" can have zero width, for a horizontal
     or verical seg)

     If the child is a node, the bounding box will be just big enough to
     hold both of its children.

(13) a NODE or SSECTOR number for the first bounding box. If bit 15 is set,
     then the rest of the number represents the child SSECTOR. If not, the
     child is a recursed node.
(14) a NODE or SSECTOR number for the second bounding box.

So there is a heavy iterative aspect to this structure. The final NODE is
always the size of the entire level.

I am optimistic that a valid set of nodes/ssectors/segs can be generated
from a set of vertices and lines by some automatic algorithm, but so far it
isn't happening. Once this problem is solved, we will be able to create
levels from scratch!

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

A SECTOR is a horiontal (east-west and north-south) area of the map where a
floor height and ceiling height is defined, so a doom player may go there.
Any change in floor or ceiling "altitude" or texture requires a new SECTOR
(and therefore separating LINEDEF(s) and SIDEDEF(s)).

Each is 26 bytes, comprising 2 (integer) fields, then 2 (8-byte string)
fields, then 3 (integer) fields:

(1) Floor is at this "altitude" for this sector
(2) Ceiling altitude

    The altitudes can probably range from about -500 to 500. A difference
    of 30 between the floor heights of two adjacent sectors is passable
    (upwards), but a difference of 32 is "too high". The player may fall
    any amount.

(3) name of floor texture, from the DIRECTORY
(4) name of ceiling texture, from DIRECTORY

    All the "floor" pictures in the DIRECTORY work as either floors or
    ceilings. F_SKY1 is used as a ceiling to indicate that it is transparent
    to the sky above/behind.

(5) brightness of this sector: 0 = total dark, 255 (ff) = maximum light

(6) special sector:

0   00  is normal, no special characteristic.
1   01  light level goes to 0 for a fraction of a second, at random times.
2   02  light pulsates abruptly for 0.5 second
3   03  light pulsates abruptly for 1.0 second
4   04  -10/20% health AND lights on/off every 0.5 seconds
5   05  -5/10% health (-5% at skill 1, -10% at higher skills)
7   07  -2/5% health, this is the usual NUKAGE acid-floor.
8   08  light oscillates from 255 (this sector's brightness) to whatever
        light level is lowest amongst all the adjacent sectors.
9   09  SECRET (a player must walk into this sector to get credit for
        discovering this "secret")
10  0a  Still undetermined: This is a strange one. 30 seconds after a level
        is begun, the ceiling of any sector with this number will come down
        to the floor. If it hits a player's head, it stops (without crushing).
        Also the ceiling seems to be blocked by a barrel, but is not blocked
        by many other objects. And sometimes the ceiling will take off UP,
        never stopping. Definately a mystery, this one.
11  0b  -10/20% health; when player's HEALTH <= 10%, then the level ends.
        If it is a level 8, then the episode ends.
12  0c  light smoothly oscillates between value in (5) and 0.
13  0d  light on/off every 0.25 seconds
14  0e  ?
16  10  -10/20% health

All other values cause an "UNKOWN SPECIAL SECTOR" error - exit to DOS.

(7) is a "trigger" number corresponding to a certain LINEDEF with the same
    "trigger" number. When that LINEDEF is crossed, something happens to this
    SECTOR - it goes up or down, etc...

    There are a few unusual trigger numbers. 99 and 999 can be used in
    staircases, see [3-3-2] under linedef types 7 and 8. 666 is used on e1m8,
    any sector with that trigger number has it's floor go all the way down
    to equal the height of the lowest neighbor floor. This happens when
    the last Baron of Hell on the level is killed. The function does not
    work on any other level, including e2m8 and e3m8, and it only applies
    to the Barons, not the other bosses. Are there any other special
    trigger events?

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

Reject is an array of bits. It's size in bytes is

(number of SECTORS ^ 2) / 8, rounded up.

"It is used for optimization and all the bits may be set to 0" -
this is a quote from John Carmack at id software.

In fact, the length of the object may be made 0 (same as making it all 0s),
and I can't detect any difference.

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

The BLOCKMAP is a pre-calculated structure that the game engine uses to
simplify collision-detection between moving things and walls. It is possible
to make an algorithm that generates the BLOCKMAP, given the locations of all
the LINEDEFS. For reasons of space, and the fact that I haven't made one,
the algorithm is not included here.

If you don't have a BLOCKMAP, the level displays fine, but everybody walks
through walls, and no one can hurt anyone else with their gunfire.

All of BLOCKMAP's fields are integers.

The whole level is cut into "blocks", each is a 128 (hex 80) wide square (the
grid lines in the automap correspond to these blocks).

The first two integers are XORIGIN and YORIGIN, which specify the coordinates
of the bottom-left corner of the bottom-left (southwest) block.

Then come XBLOCKS and YBLOCKS, which specify how many "blocks" there are in
the X and Y directions. XBLOCKS is the number of COLUMNS, YBLOCKS is the
number of ROWS.

Then come (ROWS * COLUMNS) integers which are pointers to the offset within
the BLOCKMAP resource for that "block". These "offsets" refer to the INTEGER
number, NOT the byte number, where to find the block's list. The blocks go
right (east) and up (north). The first block is at row 0, column 0; the next
at row 0, column 1; if there are 34 columns like on e1m1, the 35th block is
row 1, column 0, etc.

After all the pointers, come the block lists. Each blocklist describes the
numbers of all the LINEDEFS which are partially or wholly "in" that block.

An "empty" block is two integers: 0 and then -1.

A non-empty block will go something like: 0 330 331 333 -1. This means that
LINEDEFS 330, 331, and 333 are "in" that block. Part of each of those line
segments lies within the (hex 80 by 80) boundaries of that block.

What about the block that has LINEDEF 0? It goes: 0 0 ... etc ... -1.

Here's another way of describing BLOCKMAP as a list of the integers, in
order:

        Coordinate of block-grid X origin
        Coordinate of block-grid Y origin
        # of columns (blocks in X direction)
        # of rows (blocks in Y direction)
        Block 0 offset from start of BLOCKMAP, in integers
          .
          .
        Block N-1 offset (N = number of columns * number of rows)
        Block 0 list: 0, numbers of every LINEDEF in block 0, -1 (ffff)
          .
          .
        Block N-1 list: 0, numbers of every LINEDEF in block N-1, -1 (ffff)

-----------------------------
CHAPTER [5]: Pictures' Format
-----------------------------

The great majority of the entries if the directory reference resources that
are in a special "picture" format. The same format is used for the pictures
of items (like medikits), the sprites for the enemies (like imps), the
wall patches, and various miscellaneous pictures for the status bar, menu
text, inter-level map, and etc. The floor and ceiling textures are NOT in
this format, they are raw data; see chapter 5.

Each picture has three sections, basically. First, a four-integer header.
Then a number of long-integer pointers. Then the picture pixel color data.

[5-1]: Header
=============

The header has four fields:

(1) Width. The number of columns of picture data.
(2) Height. The number of rows.

    This defines a rectangular space or limits for drawing a picture within.

(3) Left offset. The number of pixels to the left of the center; where the
    first column gets drawn.
(4) Top offset. The number of pixels above the origin; where the top row is.

    To be "centered", (3) is usually about half of the total width. If the
    picture had 30 columns, and (3) was 10, then it would be off-center to
    the right, especially when the player is standing right in front of it,
    looking at it. If a picture has 30 rows, and (4) is 60, it will appear
    to "float" like a blue soul-sphere. If (4) equals the number of rows,
    it will appear to rest on the ground. If (4) is less than that for an
    object, the bottom part of the picture looks awkward.

    With walls patches, (3) is always (columns/2)-1, and (4) is always
    (rows)-5. This is because the walls are drawn consistently within their
    own space (There are two integers in each SIDEDEF which can offset the
    beginning of a wall's texture).

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

[5-2]: Pointers
===============

After the header, there are N = (# of columns) long integers (4 bytes each).
These are pointers to the data for each COLUMN. The value of the pointer
represents the offset in bytes from the first byte of the picture resource.

[5-3]: Pixel Data
=================

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

The first byte is the row to begin drawing this post at. 0 means whatever
height the header (4) upwards-offset describes, larger numbers move
correspondingly down.

The second byte is how many colored pixels (non-transparent) to draw, going
downwards.

Then follow (# of pixels) + 2 bytes, which define what color each pixel is,
using the game palette. The first and last bytes AREN'T drawn, and I don't
know why they are there. Probably just leftovers from the creation process on
the NExT machines. Only the middle (# of pixels in this post) are drawn,
starting at the row specified in byte 1 of the post.

After the last byte of a post, either the column ends, or there is another
post, which will start as stated above.

255 (hex FF) ends the column, so a column that starts this way is a null
column, all "transparent". Goes to the next column.

Thus, transparent areas can be defined for either items or walls.

Note that all the item and enemy sprites' names are in the DIRECTORY between
the S_START and S_END entries, and all the wall patches are between the
P_START and P_END entries.

---------------------------------------
CHAPTER [6]: Floor and Ceiling Textures
---------------------------------------

All the names for these textures are in the DIRECTORY between the F_START and
F_END entries. There is no look-up or meta-structure as with the walls.

Each texture is 4096 raw bytes, making a square 64 by 64 pixels, which is
pasted onto a BLOCK's floor or ceiling, with the same orientation as the
automap would imply, i.e. the first byte is the color at the NW corner, the
64th is the color at the NE, etc.

The data in F_SKY1 isn't even used since the game engine interprets that
"special" ceiling as see-thru to the SKY texture beyond. So the F_SKY1 entry
can have zero length.

[6-1]: Animated floors
----------------------

See Chapter [8-4-1] for a discussion of how the animated floors and walls
work.

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

Not much detail here, and I'm just guessing at the song format anyway.

[7-1]: D_[xxxxxx]
=================

Songs.  What format are they? Somewhere I read that they are in the MUS
format, which I have absolutely no knowledge of. But it's obvious what each
song is for, from their names.

[7-2]: DP[xxxxxx] and DS[xxxxxx]
================================

These are the sound effects. They come in pairs - DP for pc speaker sounds,
DS for sound cards.


The DS sounds are in RAW format: they have a four integer header, then the
sound samples (each is 1 byte since they are 8-bit samples).

The headers' four integers are: 3, then 11025 (the sample rate), then the
# of samples, then 0.

------------------------------------------------
CHAPTER [8]: Miscellaneous Non-picture Resources
------------------------------------------------

[8-1]: PLAYPAL
==============

There are 14 palettes here, each is 768 bytes = 256 rgb triples. That is, the
first three bytes of a palette are the red, green, and blue portions of
color 0. And so on.

Palette 0 is the one that is used for almost everything.

Palettes 10-12 are used (briefly) when an item is picked up, the more items
that are picked up in quick succession, the brighter it gets, palette 12
being the brightest.

Palette 13 is used while wearing a radiation suit.

Palettes 3, then 2, then 1 again are used after getting beserk strength.

If the player is hurt, then the palette shifts up to X, then comes "down" one
every half second or so, to palette 2, then palette 0 (normal) again. What X
is depends on how badly the player got hurt: Over 100% damage (add health
loss and armor loss), X=8. 93%, X=7. 81%, X=6. 55%, X=5. 35%, X=4. 16%, X=2.

Palettes 1 and 9 contain the secret codes which allow you to play
Commercial Doom eight months before it gets released. Just kidding!
Maybe F_SKY1 has that data in it. Let's get outta here!

[8-2]: COLORMAP
===============

This resource contains 34 sets of 256 bytes, which "map" the colors "down" in
brightness. (Brightness is controlled by the 5th field in the SECTORS, see
Chapter 4-9 above). E.g. at very low brightness, almost all the colors are
"mapped" to black, the darkest grey, green, blue, etc. In each set of 256
bytes, byte 0 will have the number of the palette color to which original
color 0 gets mapped. Etc. Which set of 34 corresponds to which exact
brightness level is something I haven't bothered to figure out. Better things
to do...like the maps.

[8-3]: DEMOs
==============

These are the demos that will be shown if you start doom, but don't play an
episode. Each has a record of the keystrokes. Didn't bother to figure the
formats out, since demos can be created using the devparm parameter:

DOOM -devparm -record DEMONAME

The extension .LMP is automatically added to the DEMONAME. Other parameters
may be used simultaneously, such as -skill [1-5], -warp [1-3] [1-9]. The
demos in the WAD are in exactly the same format as these LMP files, so a LMP
file may be simply pasted or assembled into a WAD, and if its length and
pointer directory entries are correct, it will work.

I've read that someone is collecting LMP files which show truly heroic feats,
like slaughtering boss guys with just a pistol, killing a whole level of bad
guys with just beserk punch, while at 1% health, etc. By the time you read
this, it's probably too late to join in the fun (i.e. submit a good one), but
who knows. At this moment, I don't know who to contact, please send me any
information you have.

I've also read that some are worried that if the .LMP formats are cracked,
cheaters will make bogus demos and destroy the whole point of distributing
.LMPs to prove how great a player one is. I think it would be a ridiculously
difficult feat to make a fake demo, but out of deference to paranoia, I'll
never even attempt to crack the structure, nor distribute info on it.

[8-4]: TEXTURE1 and TEXTURE2
============================

These resources contains a list of the wall names used in the various
SIDEDEFS sections of the level data. Each wall name actually references a
meta-structure, defined in this list. TEXTURE2 has all the walls that are
only in the registered version.

First is a table of pointers to the start of the entries. There is a long
integer (say, N) which is the number of entries in the TEXTURE resource.

Then follow N long integers which are the offsets in bytes from the beginning
of the TEXTURE resource to the start of that texture's definition entry.

Then follow N texture entries, which each consist of a 8-byte name field and
then a variable number of 2-byte integer fields:

(1) The name of the texture, like STARTAN3, is the name that is used in a
    SIDEDEFS resource.
(2) always 0. Purpose unkown.
(3) always 0. Purpose unkown.

(4) total width of texture
(5) total height of texture

The fourth and fifth fields define a "space" (usually 32 by 128 or 64 by 72
or etc...) in which individual wall patches are "placed" to form the overall
picture. This is done because there are some wall patches that are used in
several different walls, like computer screens, etc.

(6) always 0. Purpose unkown.
(7) always 0. Purpose unkown.

(8) Number of 5-field patches that follow. This is why each texture entry
    has variable length. Many entries have just 1 patch, one has 64 patches!

        1. x offset from top-left corner of texture space defined in field
           4/5 to start placement of this patch
        2. y offset
        3. number, from 0 to whatever, of the entry in the PNAMES resource,
           which contains the name from the DIRECTORY, of the wall patch to
           use...
        4. always 1, is for something called "stepdir"...
        5. always 0, is for "colormap"...

Note that patches can have transparent parts, since they are in the same
picture format as everything else. Thus there can be (and are) transparent
wall textures. These should only be used on a border between two sectors, to
avoid the "displaying nothing" problems discussed earlier.

Here is how one can "add" walls, while still retaining all the original ones
it came with: in a pwad, have replacement entries for PNAMES and TEXTURE2.
These will be the same as the originals, but with more entries, for the wall
patches and assembled textures that you're adding. Then have P_START,
P2_START, ...,  P2_END, and P_END entries, with the ... representing however
many entries are needed for the number of new wall patches you have.

Note you must be careful with naming the entries. If the name duplicates an
entry in the main DOOM.WAD, the one in the pwad will replace the original,
and if they aren't the same size in pixel dimensions, problems could occur
in the display (no crashes, probably, just ugly walls to look at because
of the random junk).

So names like "WALL66_6" or "W119_24" whatever are probably not a good idea,
unless you are using some great program that indexes and keeps track of all
the wall names in the universe (If you have such a program, please send it
to me!). Names like "JS_W12_3" and "JOEWALL2" are better.

[8-4-1]: Animated walls
-----------------------

It is possible to change the walls and floors that are animated, like the
green blocks with a sewer-like grate that's spewing green slime (SLADRIPx).
The game engine sets up as many as 8 animation cycles for walls and 5
for floors based on the entries in the TEXTURE resources. The entries in
"First" and "Last", and all the entries between them (in the order that they
occur in a TEXTURE list), are linked. If one of them is called by a SIDEDEF,
that SIDEDEF will change texture to the next in the cycle about 5 times a
second (?), going back to "First" after "Last". Note that the entries between
First and Last need not be the same in number as in the original, nor do they
have to follow the same naming pattern, though that would probaly be wise.
E.g. one could set up ROCKRED1, ROCKREDA, ROCKREDB, ROCKREDC, ROCKREDD,
ROCKREDE, ROCKRED3 for a 7-frame animated wall!

If "First" and "Last" aren't in either TEXTURE, no problem. Then that cycle
isn't used. But if "First" is, and "Last" either isn't or is listed BEFORE
"First", then an error occurs.

First           Last            Normal # of frames

BLODGR1         BLODGR4         4
BLODRIP1        BLODRIP4        4
FIREBLU1        FIREBLU2        2
FIRELAV3        FIRELAVA        2
FIREMAG1        FIREMAG3        3
FIREWALA        FIREWALL        3
GSTFONT1        GSTFONT3        3
ROCKRED1        ROCKRED3        3
SLADRIP1        SLADRIP3        3

(floor/ceiling animations) -

NUKAGE1         NUKAGE3         3
FWATER1         FWATER3         3
SWATER1         SWATER4         4?
LAVA1           LAVA4           4
BLOOD1          BLOOD3          3

Note that the SWATER entries aren't in the regular DOOM.WAD, so there's your
easy opportunity to put in a custom floor animation without taking away any
originals...

[8-5]: PNAMES
=============

This is a lookup table for the numbers in TEXTURE[1 or 2] to reference to an
actual entry in the DIRECTORY which is a wall patch (in the picture format
described in chapter 4).

The first two bytes of the PNAMES resource is an integer P which is how
many entries there are in the list.

Then come P 8-byte names, each of which duplicates an entry in the DIRECTORY.
If a patch name can't be found in the directory (including the external
pwad's directories), an error will occur. This naming of resources is
apparently not case-sensitive, lowercase letters will match uppercase.

The middle integer of each 5-integer "set" of a TEXTURE1 entry is something

from 0 to whatever. Number 0 means the first entry in this PNAMES list, 1 is
the second, etc...
--
****  **  ***  ***  **  **** : CALL OF THE  |         Hank Leukart
*  * *  * *  *  *  *  * *  * :   SHADOWS    |  ([e-mail])
**** **** ***   *  *  * **** :Apogee//Cygnus|   "Official" DOOM FAQ Writer
* *  *  * *     *   **  * *  :    March     |  FAQ via E-mail or ftp.uwp.edu