Lovingly reproduced from the Game Engine Black Book: Wolfenstein 3D by Fabien Sanglard.
The Machine That Wasn't Built for This
In 1991, there were 56 million PCs in the United States. None of them were built for games. And yet, a four-person team in Wisconsin decided to make the most ambitious game anyone had ever seen on one. To understand what they were up against, you need to understand the machine.
A PC of 1991 was five subsystems chained together: CPU, RAM, video, audio, and inputs. For gaming purposes, the quality of each could be summarized bluntly: the RAM was barely tolerable, the video was impossible, the audio was very poor, the inputs were okay, and the CPU was impossible. Two "impossibles" out of five. Not a great start.
The CPU: Fast at the Wrong Things
The predominant chip was Intel's 80386. On paper, impressive: a 386DX at 33MHz pushed 8 MIPS (millions of instructions per second), leaving every games console of the era in the dust. A Super NES managed 1.4 MIPS. A Genesis, 1.79. The PC won that fight handily.
The problem was floating point. 3D math requires keeping track of fractional numbers, which in programming means using a "float" type. But the 386 had no hardware floating point unit. If your code used floats, the compiler emulated them in software, and the result was so slow it was completely unusable for anything real-time. A dedicated math co-processor (the i387) could be purchased separately, but at $200 in 1991, few people had one.
So game developers were stuck with a choice: integers (fast but can't handle fractions) or floats (accurate but impossibly slow). Neither was good enough on its own. The solution to this problem would become one of the engine's most interesting tricks.
The RAM: A Labyrinth of Restrictions
MS-DOS kept every PC running in what was called "real mode," a compatibility measure designed to ensure old software still worked. The cost was severe: regardless of how much RAM was physically installed in a machine, only 1MB could be addressed. And out of that 1MB, only 640KB was actually available to run a program. Every driver the user had loaded (for their mouse, their keyboard layout, their sound card) ate further into that 640KB.
Making things worse, memory wasn't addressed in a simple, flat way. Two 16-bit registers had to be combined to form a single memory address, which led to a situation where three different pointers could point to exactly the same physical location yet still fail an equality test. Pointer arithmetic could silently wrap around if an array exceeded 64KB. The language had to invent special keywords (near and far) just to describe the difference between two types of pointer.
David Patterson and John Hennessy, authors of the foundational computer architecture textbook, described the x86 as "an architecture that is difficult to explain and impossible to love." For 1991 game developers, it was even worse: it was impossible to avoid.
Machines of the era did often have more than 1MB of RAM installed, but accessing it required loading special drivers. Two competing standards existed (EMS and XMS), they worked completely differently, and many customers had no idea they needed to do any of this. id Software had to ship a separate help document explaining to players why a machine with 4MB of RAM might still report "not enough memory."
The Video: Clever but Deeply Flawed
The dominant video standard was VGA. Every PC used it. Every game had to work with it. And it was a nightmare.
The VGA's framebuffer was not a simple block of memory you could write pixels into one by one. Instead, it was split across four separate 64KB banks. To write pixels, a developer had to manage these banks manually, setting mask registers to route each write to the right place. Michael Abrash, one of the leading programming experts of the era, opened his own chapter on the subject with: "Right off the bat, I'd like to make one thing perfectly clear: The VGA is hard, sometimes very hard, to program for good performance."
Two modes were most relevant for games. Mode 12h offered 640x480 resolution with 16 colors and had the advantage of square pixels, but no double buffering was possible and 16 colors severely limited what artists could do. Mode 13h offered 320x200 resolution with 256 colors and was easier to program, but it stretched the framebuffer when displayed on screen (circles became ovals), and again, no double buffering.
Double buffering is how smooth animation is achieved. Without it, the CPU writes to the framebuffer while the screen is actively reading from it, causing a visual glitch called "tearing," where two partial frames appear stitched together on screen. Both main VGA modes made double buffering structurally impossible. Or so it seemed.
The bus connecting the VGA card to the CPU was also a bottleneck. An 8-bit ISA VGA card could push roughly 1.1MB per second. A full 320x200 frame is 64,000 bytes. The theoretical maximum framerate, assuming a CPU that took zero time to render anything, was 17 frames per second. On a 16-bit card that improved to around 65fps, but other things shared the bus too: keyboard, mouse, sound.
The Audio: A Four-Way Fragmented Mess
The default sound device was the PC Speaker, a silver-dollar-sized beeper capable of producing only square waves. These could be turned into approximate tones by rapidly switching frequency, but the results were closer to "tolerable" than "good."
Players who wanted real audio had to buy a separate sound card and plug it into an ISA slot. Four cards were on the market: the AdLib (FM synthesis only, 9 channels of instrument simulation), the Sound Blaster (AdLib-compatible plus digitized PCM audio), the Sound Blaster Pro (stereo support), and the Disney Sound Source (a cheap parallel-port device with 7kHz PCM playback). Each card was completely different to program. None of them were universal. Many PCs had no card at all.
A game that wanted to support all of these had to implement four entirely different audio systems and bundle the sound assets in multiple formats.
The Inputs: Four Ports, All Different
Before USB standardized everything, input devices connected via a patchwork of incompatible ports. The keyboard used a PS/2 port. The mouse used a serial port. A joystick plugged into a game port that was only available if the user happened to have a Sound Blaster installed. The parallel port was for printers, though it could also power the Disney Sound Source.
Each port had its own protocol, its own interrupt handling, and its own quirks. Joystick calibration alone was a multi-step process involving capacitors, loop counters, and the physics of how fast a potentiometer could charge.
In Summary
The PC was a machine that could crunch integers and display static images. It could not double buffer. It could not do floating point at speed. It could only address 1MB of RAM without drivers that half the playerbase didn't know how to install. Its audio ecosystem was completely fragmented. Its video system required managing four separate memory banks manually.
"To say a PC was difficult to program for games would be an understatement," Sanglard writes. "It was a nightmare."
And yet, one small team was already halfway through building something remarkable on it.