GCW Games & More & Wacky Windows Companion

home *** CD-ROM | disk | FTP | other *** search

/ GCW Games & More & Wacky Windows Companion / gcw.iso / doom / starwar / trinity.txt < prev next >

Wrap

Text File | 1994-09-30 | 16.2 KB | 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!