Lovingly reproduced from the Game Engine Black Book: Wolfenstein 3D by Fabien Sanglard.
The Beautiful Hacks Hidden in the Engine
Lovingly reproduced from the Game Engine Black Book: Wolfenstein 3D by Fabien Sanglard.
Wolfenstein 3D is full of small elegant solutions to problems that looked unsolvable. Some of them are practical optimizations. Some of them are genuinely beautiful pieces of computer science. Here are the best ones.
Pre-Baked Trigonometry
Calculating cosine and sine at runtime involves floating point operations, which are painfully slow on the 386. The engine's solution: calculate all 360 values once at startup and store them in a lookup array. Need the cosine of 73 degrees? One array access.
There's also a small RAM-saving trick: since cos(x) = sin(x + 90), the engine allocates an array of 450 entries (360 + 90), fills it with sine values, and then points the cosine table at an offset 90 entries into the same array. Two tables for the price of slightly more than one.
The FizzleFade
When you die in Wolfenstein 3D, the screen doesn't just cut to black. It "fizzles." Individual pixels turn red, seemingly at random, covering more and more of the screen until everything is gone. When you defeat a boss, the same effect plays in blue.
The critical properties of this effect are: every pixel on screen is colored exactly once, each pixel is colored in a seemingly random order, and the total number of pixels covered increases at a perfectly consistent rate.
A naive implementation would track which pixels had been colored and pick from the remaining ones randomly. But that means maintaining a list of 64,000 positions, which uses RAM, and it doesn't guarantee consistent speed.
The actual implementation uses a Linear Feedback Shift Register (LFSR). A LFSR is a bit register that generates a pseudo-random sequence of values by shifting its bits and using XOR to generate a new bit from specific positions called "taps." The key property of a properly chosen LFSR: it visits every value in its range exactly once before cycling back to the start. No repeats.
Wolfenstein 3D uses a 17-bit LFSR with two taps. On each iteration, 9 of the 17 bits are used as an X coordinate and 8 as a Y coordinate. The corresponding pixel is colored. After 131,072 iterations (the full length of the sequence), every possible coordinate combination has been visited exactly once. Since 320x200 = 64,000 is less than 131,072, the engine just skips any generated coordinate that falls outside the screen boundaries.
The specific implementation is the "Galois" representation of an LFSR, which allows the XOR operation to be performed in a single instruction regardless of how many taps are involved. The result: a perfectly deterministic, perfectly random-looking, perfectly consistent screen wipe, implemented in about 30 lines of assembly.
The Palette Trick
Because VGA uses indexed colors, every pixel stores not a color but a reference to a color in a 256-entry table. The actual RGB values are in the palette. This means changing the palette immediately changes how the entire screen looks.
The engine exploits this to implement screen flashes. Taking damage? Shift the whole palette toward red. Picking up an item? Flash to white. Transitioning between menus? Fade to black. All of these take only 768 bytes (256 colors times 3 channels) and 768 output instructions. The entire screen is affected by a single small data change.
The Pseudo-Random Generator
Many game systems need random numbers: deciding whether an enemy hits, selecting AI behaviors, randomizing events. Wolfenstein 3D uses a lookup table of 256 pre-calculated values. Each entry serves two roles: it is a random number between 0 and 255, and it is the index of the next value to fetch. The table forms a chain 256 entries long.
John Carmack later admitted this was not ideal: the table wasn't even a proper shuffle, and some values appear more than once while others are missing. "This was bad," he noted. But it worked well enough in practice.
Performance: How Fast Did It Actually Run?
With all the optimizations described across these articles, how well did Wolf3D actually perform on real 1990s hardware? Thanks to Jim Leonard and Foone Turing, who maintain personal collections of period-accurate machines, and a modified version of the engine that displays frames per second, actual benchmarks were collected.
The results show a wide range. A 286 at 6MHz with a basic VGA card managed 5fps. A 386DX at 40MHz with a Cirrus Logic VGA card reached 34fps.
The most striking finding is the importance of the VGA card. Cirrus Logic's VRAM was optimized for fast writes, giving a massive performance advantage over other cards. A 386DX-40 with a bad VGA card could perform at the same level as a 386SX-16 with a good one. Upgrading the VGA card could literally double the framerate.
To compensate for slower machines, the engine allows reducing the 3D canvas. At maximum resolution the engine casts 304 rays and renders 46,208 pixels per frame. At minimum, it casts only 64 rays and renders 2,432 pixels. A 386SX-16 that managed 16fps at maximum resolution reached 52fps at minimum. The window size slider on the options screen was a genuine performance tool, not just a preference.
One Final Joke
In 1994, 3D Realms published Rise of the Triad, directed by Tom Hall, using a heavily modified Wolfenstein 3D engine. It had the same scalable window size system. At the minimum window setting, instead of just making the view small, it displayed a message: "Buy a 486! :)"