                              Important concepts
                              ------------------

The first thing any map maker needs to know is the terminalogy used to 
describe everything.  So, here goes:

Map:

   A map is all the information that describes a single episode/mission. 
Many people like to use the word 'level' instead, however I think that 
'map' is a better word to use.  I tend to use 'level' to mean the 
difficulty level the player selects when playing doom. 

Vertexes:

   A vertex is a point in 2D space.  Therefore, a vertex is really an 
ordered pair of map coordinates.  Vertexes appear as dots in DMapEdit 
(if they are shown).

Note: Of all the choices of words to use (vertex, point, node, etc) id
software decided to use vertex, and I just decided to follow along with
their terminalogy.  They also call the plural of vertex 'vertexes', and
not 'vertices'.  So, I also used this.

Lines:

   Lines are straight line segments from one vertex to another.  Lines 
themselves don't have any ordered pair information, and so since 
vertexes do, all lines must run between 2 vertexes.  Lines are used for 
walls in Doom, but they can also be used for other things, as explained 
later in this file.

Linedefs:

   A linedef is short for 'line definition', and is the information that 
describes a line.  Basically, lines and linedefs are the same thing.

Sidedefs:

   All lines have 2 sides to them, a left and a right side.  To 
understand this, keep in mind that even though DMapEdit shows a line as 
2 dimentional, it is really a vertical plane (no z-axis tilt).  (This 
plane doesn't have any thinkness to it, by the way.)  When you are 
playing Doom, you can see these planes as walls.  Of course, you only 
see one side of this plane at a time.  The other side can't be seen 
because the first side blocks your vision of it.  These are the 2 sides 
of the line I am talking about.

Ok, so which side is the left and which is the right?  Well, remember that
lines start at vertex A and end at vertex B.  If you think of yourself as
standing on vertex A and look straight at vertex B, then the 2 sides 
face out to your left and to your right.  The left one is the left 
side, and the right one is the right side.

Now, a sidedef (side definition) describes a side of a line.  A line 
may, however, only have 1 sidedef.  If so, then this line is called 
single-sided.  It actually does have 2 sides, of course, but the second 
side isn't defined (no sidedef).  So, here we see a distinction between 
a side and a sidedef.  All lines have 2 sides, but either 0, 1, or 2 
sidedefs.  A line with no sidedefs is possible, and will usually occur 
during map making, however it should never appear in a finished map.  
Doing so will confuse Doom and cause strange things to happen.

Sectors:

   A sector is a closed polygon area of the map, formed by the lines.  A
sector definition describes the characteristics of this area, including
the floor and ceiling altitudes, floor and ceiling textures (see below),
lighting, etc.  Any time you want any one of these characteristics to 
change, you need to create a new sector for it (to hold the new def)

Interestingly enough, the area of a sector is completely determined by 
lines and sidedefs.  But, we'll get into that a little later..

Closed polygon:

   A closed polygon is a shape formed with 3 or more lines connected to 
that each vertex has at least 2 lines jointed there.  Also, starting at 
any one vertex, you can follow a path of lines, following each one only 
once, and arrive back at that vertex again.  That's the technical 
description; basically it is an object, such as a triangle, square, 
trapazoid, or any other possible configuration of lines.  If it's still 
unclear, there little illustration will hopefully clear it up:


   +----+      +          +----+         +    +      +   +          +
   |    |     / \        /    /          |    |     /     \        /
   |    |    /   \      /    /           |    |    /       \      /
   |    |   /     \    /    /            |    |   /         \    /
   +----+  +-------+  +----+             +----+  +------+    +--+

   Closed polygons, legal sectors        Open polygons, illegel sectors

A term I often use for open polygons is 'line dead-end error'.  This is 
from the fact that if you are tracing along the lines, you will hit a 
dead end sooner or later.  Close polygons will allow you to trace along 
the lines forever, around and around..

Things:

   Things are all objects in the game, such as barrels, dead bodies, 
guns, ammo, players, monsters, player starting points, etc.  Walls, doors, 
elevators, windows, etc are not Things, but rather lines and sectors.  
All Things should lie within sectors, and not be stuck in a solid wall.

Blockmap:

   This is an internal structure that Doom uses to detect wall 
collisions.  Once you make a new map, a blockmap must be generated 
before it can be used with Doom.  DMapEdit itself doesn't use this 
structure for anything, so you only need to worry about making it right 
before you play the map.

Nodes:

   This is another internal structure (a Binary Space Partition tree) used
by Doom to figure out which walls are behind which, so it can skip 
drawing certain walls and be the fast game we all love.  I don't really 
know how it uses it for this purpose, but it does.  Because I don't know 
this, though, DMapEdit doesn't use it in any way, just like the 
blockmap.  So, don't bother making nodes until when you make the blockmap.

Segments:

   A segment is simply a whole line or a piece of a line.  Segments are 
tightly related with nodes, and created when nodes are created.  Node 
generatation is automatic, and so you will probably never need to know 
about segments.

Sub Sectors:

   Another internal structure tightly related with nodes.  It describes 
a piece of a sector, in the shape of a convex polygon (less then or equal
to 180 degrees bend between all lines, measured on the inside angle of the
polygon).

Texture:

   A texture is an image that is projected onto a plane surface, just 
like a slide projecter projects an image on a screen.  So why is it 
called a texture then?  Because that's what id calls it, and I'm going 
along with their terms.  The use of the word texture goes back before 
that, though.  I guess because before texture-mapping, walls looked flat 
and boring.  When an image is projected on that wall, though, it can 
seem to have a lot of texture to it then.  So, it's actually a visual 
texture, and not a surface texture.

PWAD:

   A PWAD (also known as a 'working wad file'), is a collection of data 
files all combined into one file, with extention WAD.  The file DOOM.WAD 
is an IWAD file, however.  Both are WADs.  IWAD probably stands for
Initial WAD, while PWAD stands for Patched WAD.  The first 4 bytes of a
WAD file will be IWAD or PWAD, thus identifying it's WAD type.  Basically,
when you play doom with a PWAD file, it will try to get any data it need
from the PWAD, and if it can't find something, it will load it from the
IWAD instead.  DMapEdit only saves out PWADs, since only id software has 
the right to use an IWAD header for a WAD.

E1M1:

   This is just map notation for the episode and mission numbers. 
(episode 1, mission 1 in this case).  This happens to be the way a 
header looks in the wad file, and is just an abbriviation, really.  I 
will often call this the 'map position'.

Object:

   An object is a Thing, Vertex, Line, Sidedef, or Sector.  Objects are 
the building blocks the user has to make maps with.

---

To build maps properly, a map maker needs to understand how the various
map elements work and inter-relate.

Objects can be broken up into 2 groups: Things and non-Things.  This is 
because all non-things tend to inter-relate with each other, while 
Things don't inter-relate to anything.  This gives Things a certain
advantage.  Things can be edited completely independently of non-Things.
If you are in the middle of making walls, sectors, etc, you can just
switch over and pop some Things in no problem.  You can edit Things
without any other Objects even created yet.  Or, you can wait and put
Things in last.

Also, editing of Things doesn't affect Nodes or the Blockmap.  Thus, if 
you have a finished map (nodes and blockmap generated), you can change 
the Things around all you want, save it, and play it with Doom as it is 
without the need for a new Blockmap or Nodes.

Lines:

   As you know, lines go from one vertex to another.  Thus, lines are 
dependent on vertexes.  You cannot have a line if you don't have a 
vertex first.  Fortunatly, DMapEdit will automatically create vertexes 
for you on the fly as you create new lines if it needs to.  So, you 
really don't have to lay a foundation of vertexes first.  (note that a 
Vertex is just an ordered pair of coordinates, and that Things also have 
an ordered pair of coordinates.  Things, however, don't use a vertex to 
determine it's location, but uses it's own internal ordered pair).

Lines are the source of all non-Thing actions.  For example, having a 
door open, an elevator raise, a bridge fall, etc.  What action a certain 
line will bring about is determined by the linetype (a linedef 
element).  This linetype also determines how the line is activated.  I 
believe that all lines must be activated on the right side.  They will
not activate from the left side.  If you ever have a line that you can't
activate in your WAD, make sure that it is the right side that you are
attempting to activate, and not the left.

Finally, line actions effect a sector.  While the line is the source of 
the action, it is the sector that actually does anything.  With many 
linetypes, the sector affected is determined by set rules.  Many more, 
however, aren't.  For these linetypes, you need to have a way to tell 
Doom what sector a line is supposed to affect.  This is accomplished 
with a trigger id number.  Both lines and sectors have trigger id 
numbers.  Usually this is just set to zero if it isn't used, however, 
when used, it links a line (or lines) to a sector (or sectors).  How?  
By having a common trigger id number.  Thus, a line with trigger id #1 
will affect any sector with a trigger id #1.  As you can see, this 
allows the possibility of having many sectors all affected by one line.  
It also, however, allows several lines to activate one sector.

An important thing to know is that you should never have a single line 
in a finished map, like so:

       +--------------+
       |              |
       |              |
       |   +------+   |
       |              |
       |              |
       +--------------+

Though it might work in Doom, a line like this has no thickness.  What 
wall in the real world has zero thickness?  It also tends to mess with 
DMapEdit when you do this.  If you want something of this nature, do 
this instead:

       +--------------+
       |              |
       |              |
       |   +------+   |
       |   +------+   |
       |              |
       |              |
       +--------------+

Using a width of 8 or so makes it seem pretty thin, makes it look better 
and more realistic, and follows the general rule of using only closed 
polygons.  If you check out all of Doom's original maps, you will see 
that they always do things this way.

Sidedefs:

   Sidedefs are dependent on lines.  You can't have a sidedef without a 
line for it to go with.  You can have up to 2 sidedefs to one line, 
however; one on each side.  Since a player can only be on one side or 
the other, only one sidedef is visible at any one time.  The visible 
sidedef determines what the wall (line) looks like, texturewise.  
Sidedef textures can be transparent, however.  If the visible sidedef 
texture is transparent, you won't see the other sidedef texture, 
though.  It is only visible from the other side of the line.  This may 
seem strange, but it does allow for some interesting illusions.  It's a 
lot like one-way mirrors, except they aren't mirrors, but seemingly 
solid walls.

Sectors:

   Sectors are dependent on lines also, though in a much more unusual 
way than sidedefs.  The actual size and shape of the sector is determined 
by the lines that make up the polygon.  Because of this, in theory open 
polygons could a sector.  However the problem Doom has then is that it 
doesn't know how to determine what sector a player, monster, or other 
Thing is in.  It is the sidedefs of a line that actually determine the 
sector.  With a closed polygon, each line has an inside facing sidedef:

     +----------------------------------+
     |                 ^                |
     |                 |                |
     | <--- inside facing sidedefs ---> | <--- outside facing sidedef
     |                 |                |
     |                 v                |
     +----------------------------------+

All sidedefs have a 'sector facing' number, which tells Doom what sector 
this sidedef helps surround.  This is the only way Doom has of knowing 
where the sector is located.  In the above example, all four inside 
sidedefs must point to the same sector number, and for any sector, all 
the inside sidedefs must point to the same sector number.  If not, Doom 
will have a fit.  Having one of the outside sidedefs pointing to the 
sector instead of the inside sidedef will cause problems too, as well as 
having an inside sidedef point to the wrong sector.  These are examples 
of what I call 'damaged sectors'.  For time to time while using 
DMapEdit, certain actions may cause a 'damaged sector'.  Unfortunately, 
there is no real way of checking for this as you are editing.  If you 
find a damaged sector, you should fix it, so Doom won't crash.

So far, we have only discussed simple sectors.  There are also complex 
(or donut) sectors.  Also called 'a sector within a sector' by many 
people, it is basically a polygon (or group of polygons) inside of 
another polygon, like so:

     +------------------------------------------+
     |               sector area #1             |
     |  +----------------+  +----------------+  |
     |  |                |  | sector area #3 |  |  outside void area
     |  | sector area #2 |  +----------------+  |
     |  |                |  | sector area #4 |  |
     |  +----------------+  +----------------+  |
     |            also sector area #1           |
     +------------------------------------------+

In this example, sectors 2, 3, and 4 are simple sectors.  Sector #1, 
however, is a complex sector.  The inside sidedefs of the outermost 
polygon must point to sector #1, and the outside sidedefs of sector #2 
polygon and sector 3 and 4 polygon must point to sector #1 also.  
Fortunately, DMapEdit handles creating both simple and complex sector.  
It is, however, highly useful to know how sectors are set-up to that you 
can spot damaged sectors.  The main source of damaged sectors is from 
first creating a simple sector, and them adding a polygon inside of it 
later.  At this point, it is a complex sector, yet it is a damaged one.  
Only the outer polygon is set to the sector.  In such a case, you must 
remake (fix) the sector.

Another type of sector is one that exists in multiple polygons.  This is 
usually refered to as extended sectors.  Basically, you have more than 
one polygon with the same sector number.  This, in fact, causes no 
problems for Doom, and allows for some very interesting possibilities.  
The only downside of it all is that since it is all one sector, all of 
the polygons have the same characteristics (floor and ceiling heights 
are all the same).

Another thing to remember is that lines can never cross one another.  
This is an error if it occures.  If you want something like this, be 
sure to put a vertex at the intersector point, and make 4 lines out of 
it instead.  Crossed lines will really upset Doom, since polygons will 
overlap one another.  Another common error much like this one is shown 
here:

     A-------------B-------------C
     |             |             |
     |  Sector #1  |  Sector #2  |
     |             |             |
     D-------------E-------------F

This doesn't look like a problem, probably, it isn't if you have 7 
lines.  But, if you only have 5 lines, being: AC, DF, AD, CF, and BE, 
then you do have a problem, and it's usually hard to find these types of 
problem.  The reason it's a problem is because of lines AC and DF.  The 
inside sidedefs of each line must point to both sector #1 and sector #2, 
which is impossible, since each sidedef can only point to one sector.  
Another way of looking at this is that you really only have 1 closed 
polygon, and a line that looks like it splits it (though not really 
crossing it any other lines).  Well, it looks like 2 polygons, but it 
isn't to Doom, or to DMapEdit, and a single line by itself is an error.  
A rule to remember is that each and ever vertex can never have only 1 
line connected to it.  If it does, you have an error, and Doom will crash.

textures:

   Sector defs have a floor texture name, and a ceiling texture name.  
These are the images you will see on the floor and ceiling of that 
sector.  Floors are seen from above them, and ceilings from below.  This 
seems trivial, and it is, but just wanted to say that you can't see then 
from the other direction.

   All sidedefs can have a 3 different textures, or have '-' for a 
texture name, meaning no texture.  A '-' texture is basically a totally 
tranparent texture.  Some textures are semi-transparent, meaning they 
have holes in them that you can see through.  Some textures aren't 
transparent at all, but also fall into this catarogy.  What catarogy, 
you ask?  Well, the single-patch texture catarogy.  All textures are 
made up of patches, which are just rectangular images.  If more than one 
patch is used for a texture, then each patch is drawn, overlapping 
anything under it.  This is done to help save memory and diskspace.  
Anyway, this isn't all that important.  What is important is that only 
single-patch textures can be used on double-sided lines (line has 2 
sidedefs).  Using a multi-patch texture on a double-sided line will 
cause problems in doom (the wall will look real weird and the game will 
slow way down).  In truth, it is not the the fact that a line is 
2-sided, but rather that the line attribute bit '2s' that controls if 
transparent textures are allowed on the line.  This bit is only ever set 
for 2-sided lines, though, so it amounts to the same thing.

Only the middle texture can have a transparent texture, or no texture.
Upper and lower textures will have problems with them (as I'll explain
in a bit).

You are probably wondering what the differences are between these 3 
textures, and why 3 textures are needed.  Well, here's another picture 
first:

             --------+
                     |
                     |
                     +--------
                     .
                     .
        Sector #1   A.B   Sector #2
                     .
                     .
                     +--------
                     |
                     |
             --------+

This is a side view (like you see in doom) looking down a line (between 
the 2 sectors).  This line is 2 sided, with sidedef A facing sector #1, 
and sidedef B facing sector #2.  Now, while a player is standing in 
sector #2, he sees into sector #1 because sidedef B has a '-' middle 
texture.  (remember, from sector #2, you only see sidedef B, and not 
sidedef A).  Sidedef B, while it has 3 textures, only has the middle 
texture visible.  To understand why, lets look at sector #1.

If a player stands in sector #1, he can see into sector #2 through the 
middle texture on sidedef B, which will be '-' also.  However, there is 
also a texture between sector #1's ceiling and sector #2's ceiling that 
he sees, as well as a texture between sector #1's floor and sector #2's 
floor.  These are the upper and lower textures, and are drawn on steps, 
and ceiling-steps.  Sidedef B hides both of these textures, though, 
since one is above the ceiling, and the other is below the floor.  An 
interesting fact is that only one sidedef of a line will have a visible 
upper texture, and only only one will have a visible lower texture.

So, the upper texture area is always between the 2 ceiling heights, and 
the lower texture area is always between the 2 floor heights.  What if 
the ceiling heights are both the same?  Then both sidedefs will have 
hidden upper textures.

Now, think about standing in sector #1 and looking at the lower 
texture.  Suppose we have a '-' texture as the lower.  What will we 
see?  The answer is nothing.  We are looking under the floor now, and 
will see to infinity.  This isn't good.  You might think that you should 
just see black, but in fact you will see garbage usually.  The rule is, 
don't use transparent or semi-transparent textures on lower or upper 
textures.

Ok, so that covered 2-sided lines, but what about 1-sided lines?  Well, 
the upper texture will start at the ceiling height, and the lower at the 
floor height.  Both textures are theorectically infinitly high.  Both, 
however, are hidden.  So, for single-sided lines, you only see the 
middle texture.  Because there is no sector behind a single-sided line, 
transparent textures are not allowed, and will only show junk if used.

Texture pegging:

   There is a line attribute for unpegging both the upper and the lower 
textures of sidedefs on the line.  We will only look at the upper 
texture to illustrate this, though it works the same way for the lower 
texture.

A pegged texture, to explain it the most simply, moves along with the 
ceiling when it moves.  For example, a door, which is simply a moving 
ceiling, always uses a pegged upper texture.  Thus, when the ceiling 
comes down (or goes up), the texture moves along with it.  If it is 
unpegged, the texture will remain stationary while the ceiling moves.  
This makes it look like the upper texture magically appears from the 
bottom as the ceiling lowers, or disappears from the bottom as the 
ceiling comes up.  Note that the ceiling moving in this example is the 
door sectors, and not the sector in front of it.

Ok, that's a simple explaination, but there's more to it than that 
really.  pegged textures actually follow the lower ceiling, while 
unpegged follow the higher ceiling.  So:

        --------A
                |
                |
                B--------
                .
     Sector #1  .  Sector #2
                .
                .
        --------+--------

Now, of course, the visible upper texture is on the sidedef facing 
sector #1.  If the upper texture is pegged,  the texture appears to move 
when sector #2's ceiling moves, disappearing or appearing from sector 
#1's ceiling (a door seems to disappear into sector #1's ceiling).  In 
other words, the texture is drawn relative to B.

An unpegged texture will follow sector #1's ceiling height instead.  If 
sector #1's ceiling moves, so will the upper texture, seeming to vanish 
or appear at B.

Ok, so unpegged upper textures sound pretty useless, right?  Well, for 
doors and such, it is, except for special effects.  It is useful for 
windows and such, however, that don't have moving ceilings.  By 
unpegging the upper texture, you can have the texture align with the 
walls on either side of the window.  That's about the main use of it.

It's also useful for staircases.  If you can see the staircase from the 
side, then having it unpegged will make the lower texture follow the 
base floor, where all the stairs have the same height.  Thus, they will 
all align with one another.

