The "What is the Build Engine?" FAQ written by Ken Silverman (started 11/17/1998) -------------------------------------------------------------------------------- What I did for Duke Nukem 3D (Atomic Edition CD) What files am I 100% responsible for on the CD? - EDITART.EXE - KEXTRACT.EXE - KGROUP.EXE - ARTFORM.TXT - TRANSPAL.EXE - WAD2ART.EXE - WAD2MAP.EXE - BSETUP.EXE (Duke team renamed this from my SETUP.EXE) - SETUP.DAT (for use with BSETUP.EXE) - TABLES.DAT (tables for: sin, atn, large font, small font, gamma correction) What files am I partially responsible for on the CD (besides DUKE3D.EXE)? - BUILD.EXE 99% (Allen Blum modified a few things specific to Duke) - BUILDHLP.TXT 20% (I wrote the section on Build & Editart Keys, and the Build MAP format) - KENBUILD.TXT (Alias: "DUKE.TXT" on the v1.3D CD) Set up the skeleton of the file, wrote all of the comments, Allen & George helped with filling the tables) - NAMES.H (file format - BUILD & EDITART parse it) What file formats did I design? - MAP file format - ART file format - GRP file format - PALETTE.DAT file format Also, I wrote some Build .MAP version converters (available over the internet): - CONVMAP6.EXE - CONVMAP7.EXE - BACKMAP6.EXE - BACKMAP7.EXE In April 2000, I made "echo" crash sound patches for Duke3D & Shadow Warrior: - DSNDFX15.EXE (original / outdated QB version for v1.5 only) - DUKSNDFX.EXE (fixes all versions) - SWSNDFX.EXE (fixes v1.2) -------------------------------------------------------------------------------- What is in the "Build Engine" source code? ENGINE.C: Graphics functions: Function to draw everything in the 3D view Function to draw the 2D texturized map view Function to draw status bar pieces Function to change screen size (+, -, Field of view (shrunk mode)) Line drawing for both 2D and 3D modes Simple 8*8 and 3*5 font routines (mostly used in BUILD editor) Screen capture PCX code Functions to load palette Functions to set video modes Function to flip screen pages Function to generate palette lookup tables Function to set gamma correction Functions to help with mirrors (they weren't fully built in to the engine) Stereoscopic modes (red blue glasses, Crystal Eyes, Nuvision) Movement functions: Function to detect if 2 points can see each other Function to find where an instant weapon (pistol, shotgun, chaingun) hits Function to determine if you're near a tagged object Collision detection for all sprites (with smooth sliding) Collision detection to keep you away from moving objects Boring functions: Functions to load/save MAP files Function to load ART file Disk caching system Functions to manipulate sprite linked lists Helper functions: A couple of line intersection functions A couple of math routines like faster atan2, sqrt, 2D rotation Functions to help with animation of certain doors & tiles Function to move vertices connected to many walls A function that returns what sector something is in Some Build editor functions also used in games GAME.C: Sample code for a complete game. Well it's not really complete unless you loved Ken's Labyrinth. This code wasn't actually used in the distributed games, but it was an important code base for the developers to look at when they had questions. Some of their routines were lifted straight from this code. CACHE1D.C: Contains a unique LRU-style caching system Group file code to handle all file loading transparently Compression & Decompression routines used in .DMO files A.ASM: (pure assembly routines) 8 routines for horizontal texture mapping, special cases for masked mapping, translucent masked mapping, and # pixels at a time 11 routines for vertical texture mapping, special cases for masked mapping, translucent masked mapping, # pixels at a time, slopes, voxels MMULTI.C: Contains mid-level network routines. This file arbitrated between COMMIT and the game code. I had to write error correction in this module because COMMIT didn't have it. This was probably the least fun part of making the engine. BUILD.H: Sector, Wall, Sprite structures, defines and other documented shared variables. While I designed the format of the structures, the "game" developers were very involved with what went into them. PRAGMAS.H: Tons of Watcom in-line assembly pragmas, such as 64-bit multiply and divide routines, memory clear & move, and a lot of cute ones for doing math, etc. -------------------------------------------------------------------------------- What engine features weren't used in Duke Nukem 3D? - Stereo shutter glasses modes. I had red-blue mode in for a long time, but it had some bugs with palettes so it was left undocumented. I also added support for Crystal Eyes and Nuvision glasses, but it didn't work on all computers and nobody at Apogee gave a crap so it didn't make it into the released version. - Voxels - I finished debugging them right around the time Duke Nukem Atomic was released. (Too late for Duke) If you want to see what my voxels look like, get Shadow Warrior and enable 3D sprites. - Room over room. This really wasn't part of the Build engine. Believe it or not, both the Shadow Warrior and Blood teams each found their own unique method of performing the room over room effect. This is why room over room was done differently in Shadow Warrior and Blood. Again this was done after Duke Nukem Atomic was released. -------------------------------------------------------------------------------- What code not considered part of the Build Engine did I design for Duke Nukem 3D? - High-level networking - I redesigned this code enough times to really annoy the game programmers with bugs. For example, the game programmers weren't too happy to split all the drawing code from the movement code, making two different random seed functions, 1 for movement and 1 for drawing, defining a small input structure that contained all of the keyboard and mouse inputs in a frame. The list goes on and on. However in the end I learned a lot and the code worked quite well when it worked. One thing I'm proud of that nobody seems to notice is that the feel of movement during a multi-player game is mostly similar to a single player game. No lag! Just for comparison, Doom had plenty of lag in multi-player games. - Status bar - My status bar drawing function was getting complex enough that I decided to totally re-write Todd's status bar code. He was pretty happy when I sent him clean code of a working status bar. - Duke-bots (fake multi-player mode). This was a project I did for fun after version 1.3D was released. Multi-player was so much more fun than those single player monsters that move 1 mile per hour, so I decided to try to simulate that. -------------------------------------------------------------------------------- What I definitely did NOT do for PROGRAMMING Duke Nukem 3D: Todd Replogle was pretty much the other half of Duke Nukem 3D. He is responsible for programming virtually everything specific to Duke Nukem 3D. - Todd Replogle did the character code of Duke Nukem 3D, such as sounds, artwork, control, weapons. - Todd did all the monster code. - Todd designed the .CON file format and parser and made the default CONS. Summary: Todd = CON (= Duke Nukem) - Tons more, but since I didn't program it, I couldn't really tell you what it was! Todd will have to make a FAQ of his own someday! :) Other small contributions to PROGRAMMING: - Allen Blum modified a couple of small things in the Build editor. - Jim Dose provided the Apogee sound engine which he did for Rott. - Mark Dochtermann provided the setup program code and COMMIT.EXE. I also played a big role in the development of Shadow Warrior and Blood. I have only documented my role in the development of Duke Nukem 3D here since it was the project I was most involved with.