Doom I/II Collection/DM12.ISO/edit/deusf/trinity.txt

Text File | 1994-09-30 | 17KB | 366 lines

                   Trinity.Wad: How I Made It.
             For lost drunken men who no longer know
              where they are, but DO care. (Cell #2)
                          Steve McCrea
               <<FIRST DRAFT 8th September 1994>>





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

    This information is published with DeuTex
        with permission from Steve McCrea

    This file is a bit obsolete. Get the last
    version directly from Steve McCrea.


Examples are taken from doomtex, which was used for TRINITY.WAD.
to convert doomtex format to DeuTex format, simply add a '*' then a space
before each patch name (not before wall names). Here is an example:
--------
doomtex:
--------
DOORCRST 128 128
                door11_1 4 0
                door11_1 124 0
                door11_1 -116 0
                pcrest4 46 37
-------
DeuTex:
-------
DOORCRST 128 128
*               door11_1 4 0
*               door11_1 124 0
*               door11_1 -116 0
*               pcrest4 46 37

case is not significant for DeuTex, but it was for doomtex.

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




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.

LEVEL DESIGN

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
confused!

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.

SCANNING PHOTOGRAPHS

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.

TALL WALLS

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. (Notice that I say _less_ than 128 high.
Initially you might think, as I did, that 128 high would be perfect.
However, if there is a substantial colour change from top to bottom
of a texture then, as in Trinity, glitches appear on the walls at the
dividing lines due to round off in the vertical texture mapping.)
    _____________
   /   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
         |
---------

      doorway
------------------- floor
This is not as neat as the other method because the ceiling texture
of the sector between the top and middle textures will always be
visible, and must be chosen to minimise breaking up the look of the
wall. It is also harder to add because the sector should clearly
be very thin (in Trinity they are 2 units thick) and this is very
fiddly work away from the autogrid.

GRAPHICS ADDITION

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

For textures to repeat properly when the length is greater than the
width of the texture, the width should be a power of two. For some
reason, the "aastinky" texture in Doom is 24 units wide. The last
eight columns of the graphic will never be seen (but they're not
very exciting anyway).

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.

         old switch texture
               |
               v
           x--------x <-- thin sector with 'metal' textures
  -----x---x--------x---x-----
         ^            ^    wall
         |            |
         +------------+------ new switch surround

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. Not that I'm condoning the use of a large
number of switches in PWADs - in fact, some of the best PWADs are
totally ruined by switches everywhere. (No Return01s, I mean names,
mentioned. Speaking of which, which I'm not of course, did you know
that there are two graphics added to Return to Phobos? Switches!
Both of them! Good grief, Michael! _Beautiful_ WAD, but...)

Note: remember to make the textures a power of two wide if you want to
allow for roundoff.

The programs I mention in this section are available as a zip
dmtex10c.zip at infant2. Alternatively you could try deutex by Olivier
Montanuy which is easier to use, and will be supported and updated.

THE "ANIMATION"

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 (?!?),
so...

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 could squeeze twenty or more thin
animations into a large texture!

THE SKY

You may not have noticed, but the sky in the latest version of Trinity
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.
It's probably a good idea to disorient the player in between with,
for example, a teleport, so he doesn't catch on to the trick too
quickly.

CONCLUSION

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
(well, really _want_, anyway) the effect.

If you're about to start your first big WAD, collect together as many
tools as you can, and read all the documentation you can find,
particularly the Unofficial specs. Good luck!