If you want to obtain a copy of TRINITY2.WAD, then download it from:


(or from one of the mirror sites) and the files are:

  trinity2.txt   - explanatory text file about trinity2.wad
  trinity2.zip   - the WAD file itself (310K zipped); this is the main data file.
  trinityu.txt   - explanatory text file about trinityu.wad.
  trinityu.zip   - this WAD (6K zipped), together with trinity2.wad, allows one
                   to play the Trinity level with Ultimate Doom.

Alternatively, feel free to grab them from here:

[ trinity2.txt | trinity2.zip | trinityu.txt | trinityu.zip ]

                   Trinity.Wad: How I Made It.
          For those who don't know and can't be arsed
       to work it out for themselves, but do give a shit.
                          Steve McCrea 

               <<FIRST DRAFT 8th September 1994>>

I am writing this article in response to numerous inquiries about the
techniques used in the creation of Trinity, and in particular a
direct request from Ian Mapleson. It is in no way intended as a
textbook approach, and I accept no responsibility for any time wasted
as a result of following the procedures documented here. I may stray
from the subject matter from time to time, as I said to the producer
last week... Although titled "How I Made It", this may not be
strictly true. I leave it as an exercise to the reader to determine
which bits have been glossed over for clarity.


As with all design, it is important to have the right tools and be
familiar with them. I restricted myself unnecessarily at this early
stage by only downloading DEU. I think this was a big mistake.  The
other editors out there may well have some great features I missed
out on totally. I know, for instance, that at least one of the others
supports auto stair contruction. But since I didn't get the others, I
don't know what else is available to speed design.  My recommendation
for those starting out in WAD design is to get them all, find out
which does what best and then mix and match. You may find yourself
using one for most of the layout and then just switching quickly to
another to do some trick or other. Hopefully you won't get too

Before I started on Trinity, I had designed a few mini-levels in DEU.
The first was just one room, then I did a couple of Wolfenstein
levels, and so on. This got all the big mistakes out of the way,
such as overlaying lines and vertices, splitting sectors wrongly,
and losing work because DEU crashed. Then I laid out the courts in
Trinity from memory, and ran about in Doom checking that the scale
felt right.  Initially there was an area surrounding the college but
I dropped it because it was going to be boring, and the map was huge
anyway.  I left most walls the standard texture, and only added
things like wood for gates. Having satisfied the sense of scale, I
put in most of the rooms and passages, and added rough doors.

DEU TIP: If you have several sectors divided like this
                  \           /
                   \         /
                   1\_______/2   C
             A      /       \ 
                   /    B    \
                  /           \
NEVER combine vertices 1 and 2, even if you believe you want to,
unless you are _absolutely sure_ that the design won't be changing
again. This caught me a few times, and in DEU at least, it is mighty
annoying to undo.

DEU TIP: If you have a sector with several internal sectors and you
want to add a linedef and split the sector like this,
                | 1|   x-x  x-x  x-x |
                |  |-- | |  | |  | | |
                | 2|   x-x  x-x  x-x |
in other words, so that the linedef's first sidedef points towards the
internal sectors. This is done by selecting vertex 1, then vertex 2,
before pressing F8-5. The reason is that DEU has a bug which prevents
the lines not facing the edges of the sector from being updated.


About this time, I realised that it would be doing the college an
injustice to use the standard Doom textures. I decided to scan some
photographs of the college and put them in, so I borrowed Peter
Morgan's (thanks Pete) camera on a sunny day and wandered over to
Trinity. I tried to make the photographs I took clear from
obstruction, shadow free and square to the viewer, i.e., with as
little distortion as possible. I then scanned standard sized 6"x4"
prints at on average 150dpi with Bill Milne's (thanks Bill) colour
scanner. I used Adobe PhotoShop on Bill's Mac to straighten the
images and crop off what I was sure I didn't need, but I DIDN'T
change the resolution or convert from 24 bit colour and I DIDN'T
crop right up to the edges of what I wanted.

This was AFTER the test run on the Wren library, the southern upper
wall of the southwest courtyard (NOTE: Apologies to those who know
Trinity: yes, I have rotated the college 90 degrees!), when I scaled
the image to 64x256 and saved it as an 8 bit GIF. If you look
carefully at the texture in the level, you will see that it is now
128 wide, scaled from 64!  Yech. I wasn't going to make that mistake
again, although I couldn't be bothered to rescan the Wren library.

When I was pretty sure what size I wanted for graphics, I COPIED
the images, cropped, scaled, tinted, smoothed, converted to GIF, and
so on.  Some graphics didn't tile very well, and I either touched
them up to tile properly (e.g., stone) or mirrored one half (e.g.,
the windows on the outside of the dining hall).

There are three hand drawn graphics in Trinity: the sky, plaster, and
the burgundy wood panelling. Again I started with a 24 bit palette,
and used the pencil and airbrush tools before blending, motion
blurring, tinting etc. to produce the final image. Several edit
cycles were required to get something that I was (sort of) happy with
in Doom.


The standard Doom texture is a maximum of 128 pixels high, and on
walls higher than this the texture repeats vertically. Clearly I
didn't want this in Trinity, so I use a couple of tricks to avoid it.
On walls with void space behind (no sector behind) a sector is added
with floor and ceiling heights chosen to divide the wall into sections
less than 128 high.
   /   added     \
  /    sector     \
      tall wall

  ----------------- top of wall
  upper texture
  ----------------- ceiling of added sector
  normal texture
  ----------------- floor of added sector
  lower texture
  ----------------- bottom of wall
Textures are applied as shown. The line between the sectors is marked
as 2S/Im/So in DEU, i.e., two sided, impassable, and blocks sound.
The blocks sound bit is to reduce the size of the REJECT data. See
the unofficial specs for details. The impassable bit is to prevent
you or monsters going into the sector (I had this problem with skulls
initially. It was disturbing to find skulls appearing from nowhere!).
The normal texture must be a single patch or the Medusa effect (looks
like snakes and you turn to stone) will occur.

In Doom, each texture is constructed from one or more graphics
patches. The texture definition contains no image data, just the size
of the texture, and a list of patches and their position in the
texture. The _patch_ definition contains the image data.

For walls which already had sectors behind them (e.g., above a doorway)
non-repeating tall textures are acheived by "stepping" the wall. A
separate sector is required for each step. In side view,

            ------- ceiling
           |<-- top texture
         |<-- middle texture

------------------- floor


Initially I just replaced patches in single patch textures. I hacked
around with dmgraph to make it convert a GIF directly to a patch.
Then I used a program I had previously written for sound lumps to
make a PWAD of patches with names the same as the names of patches in
single patch textures. These then replaced the same-named patches
when the PWAD is included using -file.

However a better solution was necessary as (a) I was running out of
single patch textures, and (b) I needed some user defined multipatch
textures. So I wrote a program to convert the texture definition
entries in the main Doom WAD to an ASCII format, and another which
recreated the binary definition entries from the ASCII format. The
big advantage of this method was that it allowed the creation of NEW
textures with sensible names like "stone" and "plaster". A typical
definition of a new texture "doorcrst", a 128x128 texture with
three old patches and one new:

DOORCRST 128 128
                door11_1 4 0
                door11_1 124 0
                door11_1 -116 0
                pcrest4 46 37

The first released version of Trinity had redefined switch textures,
so that when the switch was encountered later in the standard levels,
it looked really bad. In the second version I fixed this by setting
the switches into walls so that only the switch part of the texture
was visible. This is _highly_ recommended for levels which may be
grouped into PWAD episodes.

Actually it's just occurred to me that there is a neater, if more
memory hungry, way to do this seamlessly. Widen the switch texture
and put the new switch on the right of the old one, then when using
your new switch offset the texture by the appropriate amount. As
long as no other levels use a repeated switch on a wall, then this
is perfect. For example, say you wanted a new switch pair, you could
tack them on the right of the SW1BRN1 and SW2BRN1 switch pair. The
original definition of SW1BRN1 is
SW1BRN1 64 128
                wall02_2 0 56
                wall02_2 0 0
                sw3s0 16 75
which you redefine to be
SW1BRN1 256 128
                wall02_2 192 56
                wall02_2 192 0
                wall02_2 64 56
                wall02_2 64 0
                wall02_2 0 56
                wall02_2 0 0
                sw3s0 16 75
                pplast 96 0
                pplast 160 0
                sw3s0 144 75
The old switch is still at offset 0. The new switch is at offset 128.
Note the repetition of the wall patch. This allows for roundoff error
in the texture mapping engine, which expects similar texture to be
just to the left and just to the right of the texture being drawn.
Don't forget to define the other switch position SW2BRN1 similarly!
This technique allows for a large number of different switch designs
to be used in a PWAD.

The programs I mention in this section are available as a zip
dmtex10c.zip at infant2. Alternatively you could try deutex which
will be supported and updated.


If you haven't seen Trinity.WAD, I recommend you look at it before
reading this section as it contains a massive spoiler. However if you
haven't seen Trinity you probably aren't reading this document (?!?),

Several people have asked how the cyberdemon movie is done. I have
even heard it described as "voodoo magic"! Nothing could be further
from the truth. It is actually very simple. To quote Matt Fell in
the unofficial Doom specs 1.3,

       "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 based on the entries in the TEXTURE
resources, and up to 5 based on what's between F_START and F_END. The
entries in FirstTexture and LastTexture, below, 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
probably be wise. E.g. one could set up ROCKRED1, ROCKREDA, ROCKREDB,
ROCKREDC, ROCKREDD, ROCKREDE, ROCKRED3 for a 7-frame animated wall!"

Hence the movie in Trinity is defined in the ASCII texture file as a
series of textures SLADRIP1, MOVIE01, MOVIE02, ..., MOVIE98,
SLADRIP3. The important thing is the order in which the textures
are listed. The Doom EXE contains the names of the FirstTextures
and LastTextures so it isn't possible to have additional animation
cycles in a PWAD.

And because the sprites and the Doom logo have the same format
as patches, they are just listed as if they were patches. For
example, a frame of the movie is defined

MOVIE08 256 128
                pblak 0 0
                pblak 64 0
                pblak 128 0
                pblak 192 0
                t 67 40
                r 86 40
                i 106 40
                n 124 40
                i 144 40
                t 162 40
                y 181 40
                m_doom 67 50
                cybre7 -20 20
                playf3f7 198 64

where "pblak" is a totally black patch, and t, r, i, n, and y are
the characters. Initially, the movie used the character set in the
game but this caused crashes (for a reason I won't go into now) so
after consulting iD, I included the character set again in the PWAD
with new names.

The technique described in the Graphics Addition section for adding
new switches can also be applied to new animated textures. Just
make the new animation length a multiple of the old length, and
put the old animation at the left of the textures. Don't forget to
satisfy the roundoff errors!


You may not have noticed, but the sky in the latest version of Doom
doesn't repeat anywhere around the horizon. (Thanks to Olivier
Montanuy, author of DeuTex, for teaching me this trick.) This is done
by defining a sky texture (SKY1, SKY2, or SKY3 depending on the
episode) which is 1024x128 in size, and pasting patches into it so
that 0=East, 256=North, 512=West, and 768=South. Note that this means
that the textures are left/right mirrored! I can't think of any way
to make the sky texture animated. However you could fake twin skies
by only allowing the player to see half the sky during one part of a
level, and then later only allowing him to see the other half! A
crap example would be bright blue skies -> red skies+mushroom cloud.


In this document I have outlined some techniques which can be used to
seemingly extend the Doom engine. The use of these inevitably slows
down Doom and so should be used sparingly, unless you _really_ need
the effect.

If you intend to design something like Trinity, collect together as
many tools as you can, and read all the documentation you can find,
particularly the Unofficial specs. Good luck!