Fabien Sanglard
Total Page:16
File Type:pdf, Size:1020Kb
GAME ENGINE BLACK BOOK DOOM FABIEN SANGLARD 1 Copyright In order to illustrate how the DOOM game engine works, a few screenshots, images, sprites, and textures belonging to and copyrighted by id Software are reproduced in this book. The following items are used under the "fair use" doctrine: 1. All in-game screenshots, title screen. 2. All in-game menu screenshots. 3. All 3D sequence textures. 4. All 3D sequence sprites. 5. All screenshots of DOOM. 6. DOOM name. Photographs with "ROME.RO" watermark belong to John Romero and are reproduced with his authorization. DOOM Survivor’s Strategies & Secrets essays are copyrighted by Jonathan Mendoza and reproduced with his authorization. 3 Acknowledgments Many people helped completing this book. Many thanks are due: To John Carmack, John Romero, and Dave Taylor for sharing their memories of DOOM development and answering my many questions. To people who kindly devoted time to the painful proofreading process, Aurelien Sanglard, Jim Leonard, Dave Taylor, Jonathan Dowland, Christopher Van Der Westhuizen, Eluan Miranda, Luciano Dadda, Mikhail Naganov, Leon Sodhi, Olivier Cahagne, Andrew Stine, and John Corrado. To Simon Howard, for not only proofreading but also sending pull requests to the git repo. His efforts saved countless hours at a time where the deadline was concernedly close. To Jim Leonard who once again volunteered his time and encyclopedic knowledge of audio hardware and software (the Roland section was heavily based on his articles). To Foone Turing who volunteered his fleet of 386s, 486s, and ISA/VLB VGA cards to ac- curately benchmark DOOM. To Andrew Stine, founder of doomworld.com, for sharing his encyclopedic knowledge of DOOM and putting me in touch with the right people. To James Miller and Leon Zawada who researched and discovered the origin of the back- grounds. James also collected and photographed all toy props used to shape DOOM weapons. To Rob Blessin, founder and owner of Black Hole, Inc for answering all my questions about NeXT, helping me assemble a NeXTstation, and lending me a rare NeXTdimension board. If you ever want to restore a NeXT or acquire your own, Rob is likely a good starting point. To Alexey Khokholov, author of PCDoom-v2. His backport helped to generate accurate performance metrics. 5 To Alexandre-Xavier Labonté-Lamoureux for his patch restoring C drawing routines in PCDoom-v2. To Simon Judd, author of Slade3, a map editor used to create maps showcasing special aspects of the renderer. To Colin Reed and Lee Killough for their node builder, BSP 5.2, which was used to inject maps into the DOOM engine. To the developers of Chocolate DOOM which was heavily hacked to generate many ex- planatory screenshots. To Bruce Naylor for kindly making time for an interview and enlightening me with his master knowledge of BSPs. To John McMaster for his insanely high resolution photos of Intel 486 and Motorola 68040 CPUs. To Romain Guy for taking the pictures of my 486 motherboard, my NeXTCube mother- board, and my NeXTDimension motherboard. To Samuel Villarreal for finding the origin of the BFG artwork and reverse engineering DOOM console animated fire. To Rebecca Heineman (author of DOOM 3DO) for proof-reading and fact checking the 3DO section. To Carl Forhan, owner and founder of Songbird Productions for releasing DOOM Jaguar source code and answering my questions. To Leon Sodhi, for sharing his studies of DOOM wall rendition. To John Corrado, for sharing his knowledge of visplanes. To Matthew S Fell, author of the Unofficial DOOM specs which was instrumental in building the map visualizer featured in this book. To Alexandre-Xavier Labonté-Lamoureux for providing the SNES screenshot demonstrat- ing dithering and diminished lightning. To Aiden Hoopes, Alexandre-Xavier Labonté-Lamoureux (axdoomer), Anders Montonen, coucouf, Bartosz Pikacz, Bartosz Taudul, Boris Faure @billiob, Brandon Long, Brian Gilbert 6 @troldann, Chris @JayceAndTheNews, Daniel Lo Nigro, Daniel Monteiro , Davide Gualano @davesio, George Todd, Guilherme Manika, Jamis Eichenauer, John Corrado, Klaus Post, Marcel Lanz, Marcell Baranyai, Marco Pesce, Marcus Dicander, Matt Riggott, Matthieu Nelmes, Miltiadis Koutsokeras, Olivier Cahagne, Olivier Neveu, Patrick Hresko, phg, Richard Adem @richy486, Rory Driscoll, Ryan Cook, Sam Williamson, Steve Hoelzer, Tor H. Hau- gen @torh, tronster, Tzvetan Mikov, Vasil Yonkov, Frank Polster, Boris Chuprin, Rory O’Kenny and Vincent Bernat for reporting errata. – Fabien Sanglard [email protected] 7 How To Send Feedback This book strives to be as accurate and as clear as possible. If you find factual errors, spelling mistakes, or merely ambiguities, please take a few minutes to report them on the Game Engine Black Book: DOOM companion webpage located at: http://fabiensanglard.net/gebbdoom Thanks :) ! 9 Foreword by John Carmack In many ways, DOOM was almost a "perfect" game. With hindsight and two decades more skill building, I can think of better ways to imple- ment almost everything, but even if I could time machine back and make all the changes, it wouldn’t have really mattered. DOOM hit a saturation level of success, and the legacy wouldn’t be any different if it was 25% faster and had a few more features. The giant aliased pixels make it hard to look at from a modern perspective, but DOOM felt "solid" in a way that few 3D games of the time did, largely due to perspective correct, subpixel accurate texture mapping, and a generally high level of robustness. Moving to a fully textured and lit world with arbitrary 2D geometry let designers do mean- ingful things with the levels. Wolfenstein 3D could still be thought of as a "maze game", but DOOM had architecture, and there were hints of grandeur in some of the compositions. Sound effects were actually processed, with attenuation and spatialization, instead of sim- ply being played back, and many of them were iconic enough that people still recognize them decades later. The engine was built for user modification from the ground up, and the synergy of share- ware distribution, public tool source release, and early online communities led to the origi- nal game being only a tiny fraction of the content created for it. Many careers in the gaming industry started with someone hacking on DOOM. Blasting through the game in cooperative mode with a friend was a lot of fun, but compet- itive FPS deathmatch is one of the greatest legacies of the game. Seeing another player running across your screen, converging with the path of the rocket that you just launched, is something that still makes millions of gamers grin today. There was a lot of clever smoke and mirrors involved in making DOOM look and feel as good as it did, and it is a testament to the quality of the decisions that so many people thought it was doing more than it actually was. This remains the key lesson that still mat- 11 ters today: there are often tradeoffs that can be made that gets you a significant advantage in exchange for limitations that you can successfully cover up with good design. – John Carmack 12 Foreword by Dave Taylor I find the technology behind great products fascinating, but I’m even more fascinated by the conditions that lead to that technology. I don’t feel in any way responsible for the greatness of DOOM. Technologically, that was all Carmack, and anything that came close in my code was only due to his influence. In the course of struggling to keep up with Carmack, I would sometimes fall asleep in the office. I remember hearing that at least for a window there, Carmack felt guilty that I was working so hard. Knowing his intense work ethic, perhaps that put a little more spring in his already indefatigable step. What I do know is that I had joined an already well-oiled development team in the form of Carmack, Romero, Adrian, and Kevin. This wasn’t their first rodeo. I later learned the mother of their invention was a harsh time constraint at Soft Disk, a com- pany that sold a subscription of curious demos on diskette. They wanted to start making games instead of just toy applications, and their manager allowed them, but only if they could deliver a game every two months like clockwork. Back then, there were no game engines. In fact, DOS was not a complete operating system, and you had to finish writing the drivers for your game to work. So this was an incredibly harsh time constraint, and it forced them into doing constant triage on what they wanted to achieve with each game. I was so convinced that this painful constraint is what led to the team’s impressive work on DOOM, that years later, I would teach a university class inspired by id’s path to success. The other teachers warned me not to be nice to the students, or they would take advantage of me. Relishing an acting challenge, these were my first words to the class: "My name is Dave Taylor. I’m a working producer, and I don’t have time for you. You owe me a shipped game every week, and if you don’t ship, you’ll get an F." Three classes and 127 games later, almost all of my students went on to jobs in the game 13 industry, no mean feat with a game design degree, and many of them credit the painful time constraints of the class. Terror works. I recommend it. Which brings me to our newest source of terror. I am not popular amongst my peers for having a low opinion of games. I consider what we make an opiate for the mind with about as much redeeming value.