I found Fabien Sanglard’s site awhile ago while searching for information on Doom’s engine. While not extremely exhaustive, each short article on his site gives a nice informative look into several of id’s and other games to see what makes it tick. Well, apparently there was enough demand for him to dive in deeper, because now Fabien has released the Game Engine Black Book for Wolfenstein 3D. Unlike Game Programming Patterns, which I’ve previously posted about, don’t expect to follow along with much or most of this book unless you have some serious graphics and/or assembly language programming under your belt. Wolfenstein 3D was created at a time when there were severe restrictions on what a game could do, especially a 3D game. Through his previous experience and uncanny ability to grasp, learn, and create brilliant new things, John Carmack came up with a fast-performing engine that allowed id to create the most popular shooter of its time, at least until Doom came long.
In the book Fabien first takes a look at the hardware id had to work with at the time, including the Intel i286 and i386 processors, RAM limitations and 2 ways of trying to expand beyond it, video modes, and sound processing. Then a small section covers the asset creation for the game, and the personnel at id who worked on each. Finally Fabien dives into the Wolfenstein 3D source code, and this is definitely the meat of the book. He goes over the general architecture, the 2D and 3D renderers, audio and sound effects, and user input.
This was a fun read, but I’ll say at least 95% of it went over my head. The code in C I could roughly follow, as that’s the language I primarily learned. But there’s a LOT of assembly mixed in, and these days I don’t think even Rasberry Pi programmers deal with it; it’s that low-end (I think BIOS/UEFI and device drivers are the only things that use assembly). I would love to see further books from Fabien. Doom is an obvious choice, but I think something even further along would be great, whether that’s Quake or even Doom 3. I’d just like his analysis on code that I could roughly follow better, whether it’s C or C++.