One way to achieve this is to allocate the list of all possible screen coordinates and shuffling it, but it would be terribly inefficient and unfeasible for the early 90’s hardware.
When your character dies in Wolfenstein 3D, the screen is gradually covered with red pixels. That’s something I’ll try to keep in mind next time I’ll get a knee-jerk reaction to some ugly hacks. It relies on undocumented assumptions, but if these assumptions were embedded deeply enough in the whole codebase, they were never changed. It’s fragile, but there was no risk of breaking it because there was no reason to change it.
In short, it’s a kind of code that would not pass the code review.ĭoes it matter? Not in a slightest. It’s ugly and quite fragile as it relies on some undocumented assumptions and seemingly unrelated implementation details. Don’t polish the non-critical codeĪfter reading the book I took a look at Wolfenstein 3D source code and read through the memory manager module. It’s definitely a technique that could be useful now or even in the distant future. That’s also the format in which they were stored on disk in the game resources files! The conversion from the actual assets delivered by the artist to something the game could use in runtime was done as a part of the build process. To handle both scaling and transparency, they were converted into small meta-programs that modified the regular texture scalers. The sprites in Wolfenstein 3D - enemies, loot, elements of the environment - were not stored or blitted as regular bitmaps. Transform your assets so they are ready to use They help a lot, but I wish there was a better option, one that would feel more natural. The problem with them is that they feel quite alien, have severe limitations or they don’t smoothly interop with regular code.
In the Android world we have a few kinds of metaprogramming: annotation processing, reflection, code weaving, and recently Kotlin compiler plugins. It was an example of metaprogramming: a program writing another part of itself. Instead, there was a function that generated all necessary “scalers” in the runtime. What was needed was the set of simple “draw the Nth column of a texture scaling it down to 40 pixels” assembly routines. For a better performance, you couldn’t make all the calculation on the fly. VGA graphics cards didn’t have hardware support for texture scaling, so it had to be done by software.
But this kind of optimizations is what made Wolfenstein 3D possible! There were probably one or two major tricks that made id Software folks think this project can be done, but the rest was shaving 10% off here, and 5% there to get the decent framerate.ĭon’t underestimate the power of compounding. This means that all the minor optimization are left undone. I’ll only make two points here: from the business point of view an ok-ish performance and a couple more features are usually preferable to astonishing performance with only basic features and the programmers would go an extra mile for performance optimization if they see big wins - halving the memory footprint or making something work an order of magnitude faster. This is an interesting topic which deserves a whole post on its own. But just as often our amazing hardware is hogged by not-so-amazing software and we’re forced to wait for what feels like an eternity to get the simple task done. We’re surrounded by the amazing hardware and we interact on a daily basis with equally amazing software that does almost magical things. Minor performance optimizations do matter The book is worth reading just for this single takeaway. The book offers the most intuitive explanation of how the floating point numbers work I’ve ever read. What can a software developer learn in 2018 from reading the book about a game developed in the early ‘90s? Here are my takeaways. While I was mostly reading it for fun, it got me thinking. The question I get when I tell people about this book is whether I get any useful insight from it. There’s a short chapter about id Software team (if you’re interested in this topic I recommend another great book, “Masters of Doom”), and then there’s the meaty part: deep dive into Wolfenstein’s engine.
The book starts with a background on the hardware available at the time when Wolfenstein 3D was created and highlights the technical challenges of creating a First Person Shooter game that would run on it. Some was a pure joy of nerding out and poring over the details of some assembly code listings.
Some of my enjoyment comes from the nostalgic vibes I got while reading this book: my first PC was a 386SX and a floppy disk with Wolfenstein 3D shareware version was often in use. One of the most interesting and fun books I’ve read last year was Fabien Sanglard’s “Game Engine Black Book: Wolfenstein 3D”.