5:35 AM
After all of the heavier reading I've been doing lately—machine learning, CUDA programming, fundamental Lisp programming, etc.—I wanted to kick back and read something a bit more relaxing and entertaining. Luckily, at just the right time a friend lent me a couple of books that promised to fit the bill perfectly: the Game Engine Black Books for Wolfenstein 3D and Doom, both by Fabien Sanglard. I grew up with these games, with them being my first and second PC FPS games. I played countless hours of these and other id Software games and other games that used id Software engines like Rise of the Triad, Heretic, and Hexen. I couldn't wait to dig into these books and see what was underneath the games that pleasantly wasted away the night hours of my youth.
 | VS. |  |
Game Engine Black Book: Wolfenstein 3D
I quickly realized what a beautiful book this was going to be with nearly full-page, glossy color pictures of the game and die photos of the Intel 80386-DX processor that ran the game when it first came out on May 5th, 1992. It was incredibly fun to just page through the book and look at the different pictures, and peruse the various explanations surrounding the pictures about the game engine's design. It took a little while to settle down and actually start reading through the book.This Black Book starts out with forwards by John Carmack, Tom Hall, and John Romero, and then there's a short introduction that gives an overview of the game market, the PC market, and the state of video games in that era. This was the time of Super Nintendo and Sega Genesis, and the i386 processors had been out for a few years by the time Wolfenstein 3D was released. The i386DX-33 was over four times more powerful than the Super Nintendo processor, and even more powerful i486 processors were coming to the market from mid-1989 to 1992. The video game consoles were primarily sprite-based hardware designs, so they weren't set up for running a 3-D game like Wolfenstein well at all. The PC was definitely the hardware of choice for this game, power-wise, but as Sanglard goes on to explain, it had its own downsides for game development.
The next chapter went into the state of the hardware that was targeted for Wolfenstein 3D in detail. The game was designed to run okay even on an i286 CPU, but even on the i386 processors, the compromises that were made in the design were astonishing. I had forgotten how bad things were back then with no hardware floating point units, only a handful of registers, and an utter mess of a memory hierarchy with real mode and segmented addressing. The state of video cards was not much better with no direct double-buffering in hardware, an essential feature for running smooth animation in a 3-D game. These VGA video cards were not set up to run games in the least, so double-buffering needed to be hacked and kludged together. Thankfully, that was possible to do. Sound was just reaching a tolerable level of performance at the time with AdLib and Sound Blaster cards, if you sprang for the add-in card and were able to get it working. Sound cards were rarely included in PC builds at the time, and I remember many a night fiddling with vaguely understandable IRQ and DMA settings before plug-n-play. Funny, now I actually know what those things mean, and what they're used for, but it's all handled automatically by the chipset and the OS.
That chapter was definitely a fun trip down memory lane. The next chapter switched gears and was all about the decidedly small team that made the game, especially by today's standards, and they completed the game in four months! There were four full-time people that founded id Software a year before starting Wolfenstein 3D. John Carmack and John Romero were the programmers, Adrian Carmack was the artist, and Tom Hall was the creative director. Another four people contributed, but did not work on the game full-time from start to finish. These were Jay Wilbur in business, Kevin Cloud as a computer artist, Robert Prince as the composer, and Jason Blochowiak as another programmer. The development studio was none other than the first floor of John Carmack's two floor apartment. Wild. The rest of the chapter went through the development tools they used and built to make the code, level maps, artwork, and sound assets of the game.
Chapter 4 gets into the real meat of the game architecture, and it's the longest chapter of the book. It was fascinating to learn about the ingenious performance hacks and algorithms they (mostly John Carmack) implemented to achieve playable frame rates with the hardware they had to work with. The game is restricted in numerous ways so that the code doesn't have to spend much time calculating things like clipping or player perspective. The floor and ceiling were solid colors, and all walls were orthogonal. The player couldn't look up or down, jump, or crouch, so walls were always perfectly vertical and the (obscured) horizon was always dead-center on the screen. The only polygons in the game were the walls, which were rectangles. Everything else was a sprite. The maximum view port was smaller than full-screen at 304x152 pixels, and it could be adjusted down from there if needed for a faster frame rate on slower hardware. These along with plenty of other restrictions made the game playable on the i286, although the best experience was still on an i386DX or better CPU.
The other common optimization was to code critical loops and code sequences in x86 assembly. Quite a few code listings in the book are just lines of assembly code, mostly of moving values around in various registers. Dropping down to assembly was necessary because compilers at the time weren't the best at outputting even remotely optimized code, and a smart developer could arrange assembly code much better than any compiler could. This deficiency in the compiler shouldn't all be blamed on it, for x86 assembly was truly horrendous. I am at the same time in awe of John Carmack for doing what he did with the code and eternally thankful that I never had to do x86 assembly programming like that myself. Even today it's something to be avoided because the complexity is now nearly unmanageable and compilers have made huge strides besides, but oh my gawd, that assembly programming must have been the most awful, tedious exercise in memorizing and recalling useless instruction set trivia.
This whole chapter was pure gold, covering everything from the renderer in detail to the enemy AI to the audio programming and sound effects. The writing wasn't always the greatest, but explanations were at least insightful, and I could always parse out what Sanglard meant, even with numerous typos and grammatical errors. Normally these kinds of mistakes would be obnoxious, but the book was so full of great pictures, diagrams, and information that was completely engrossing to me that I was willing to overlook that shortcoming.
The last few short chapters were also quite interesting, and a nice way to wrap up the book. Chapter 5 described the sequel to Wolfenstein 3D, Spear of Destiny. Chapter 6 covered a number of ports to other systems, including Super Nintendo (heavily compromised), Jaguar, iPhone, and VR ports. Chapter 7 concluded with a little information about the successors to Wolfenstein 3D and where each of the designers and developers are now. The whole book was an excellent tour of a classic game that changed the video game industry forever, and if you're at all interested in the details of one of the games that started the FPS genre, you have to read this book.
Game Engine Black Book: Doom
This Black Book followed a very similar format to the Wolfenstein 3D book with the same result of an incredible experience digging through the game engine of one of the most influential PC games ever made. I went through waves of nostalgia as I paged through pictures of the Doom game world and explanations of how it calculated and rendered the intense game that consumed hours upon hours of my free time growing up. It was fascinating to see how all of it was implemented, and on such meager hardware, too! id Software achieved an incredible amount of performance and features with their idTech 1 engine that they created for Doom.
The book starts off with forwards by John Carmack and Dave Taylor and a short introduction just to wet your appetite. Then it jumps into the hardware that Doom was designed for in chapter 2. Doom was able to run on an i386, but by 1993 when Doom was being developed, the i486 was becoming affordable and was over 2x faster than the equivalent frequency i386, so that was the new target system. Everything else was improving rapidly as well. Video cards took a big step up in performance with the VESA VL-Bus and tighter component integration on the cards. Sound cards became even more fragmented, unfortunately, but sound quality was improving by leaps and bounds. Networking was also becoming possible by this time with multiple ways to connect PCs for multiplayer co-op and deathmatch play. Finally, compilers had improved to the point where it wasn't necessary to do nearly everything in assembly. The Watcom compiler allowed id Software to code Doom almost entirely in C, freeing the developers to think at a higher level and implement more features more rapidly.
Chapter 3 is entirely new because id Software used an entirely different development environment for Doom. Instead of developing everything on unstable DOS PCs, they took the chance on using expensive NeXT workstations. Even a fairly basic NeXTstation cost $4,995 in 1991, and a NeXTcube ran $12,395! It turned out to be worth it, though, because these workstations were rock-solid and allowed John Carmack and the other developers to make incredible progress instead of constantly fighting with crashing machines and a poor development environment. This chapter did a great job going through the architecture and benefits of the NeXT systems, and how id Software used them to full effect.
The next chapter was about the team and tools, like chapter 3 in the Wolfenstein 3D book. Things had changed dramatically, with the team moving to Dallas, TX and growing to fourteen people by the end of development. The tools were evolving, too, with some of the character sprites and animation done using stop motion capture, and the map editor (DoomED) taking on new features to support the multitude of new capabilities in the game engine. Walls in the game no longer needed to be orthogonal, although they still had to be vertical for rendering to be fast enough. Floors and ceilings could change height to create steps, platforms, and other environmental features. Various kinds of traps and ambushes were also possible now. It's quite amazing how many features were added to idTech 1 when compared to the Wolf3D engine. These new features, especially the non-orthogonal walls and varying heights, required a more efficient data structure for the maps, and the BSP (Binary Space Partitioning) node tree was commandeered for the job.
Nearly half of the book is taken up by chapter 5 on the idTech 1 game engine. This chapter is just a monster of awesome information about the engine. It goes through every detail from the game tic design and use of fixed-point arithmetic to sound propagation and enemy AI. The section on the 3D renderer was especially interesting and detailed. There are great explanations on how the environment was drawn with its additional complexity, texture mapping with perspective correction, sprite clipping and animation, and diminished lighting to give the game its intense horror movie feel. This renderer section in particular was so interesting that it made me want to go implement a bunch of the algorithms myself just to be able to recreate them and see them in action. It looks like it would be immensely satisfying.
The last chapter described in fairly good detail how a number of ports of Doom were done on other game consoles. The console ports included the Atari Jaguar, Sega 32X, Super Nintendo, Sony PlayStation, 3DO, and Sega Saturn, and both the system architectures and Doom engine implementations are described. I was in high school during this era of the great console wars, although I never played Doom on any of them, just the excellent experience of the PC. I had forgotten how different these console architectures were, and some of the design decisions that went into those systems were truly remarkable...and strange. The sections on the Super Nintendo and PlayStation ports were my favorites. The Super Nintendo would have never been able to run Doom on its own, but with the extra power of the SuperFX chip that was used in Star Fox and a few other games, it was able to pull it off reasonably well. The PlayStation port was the most faithful of the ports, and even added some cool new features like colored ambient lighting. Of all of these systems, the PlayStation was exceptionally powerful for making great games. Even though other systems might have looked more powerful on paper, they all had disadvantages and unfortunate design decisions that handicapped them while the PlayStation was so easy to develop for that its potential could consistently be achieved in practice.
I enjoyed this book as much, if not more than the Wolf3D Black Book. From the beautiful full-color pictures to the detailed explanations of technical feature implementations to the well-chosen code listings sprinkled throughout the book, this was an incredibly fun guided tour of a legendary game engine. I devoured this book, and through it all, I wanted to do two things: go back and play through Doom again and re-implement some of those rendering algorithms for myself. I can't think of higher praise for a book, so if you've ever played Doom and want to know how it works, you need to go treat yourself to this book and the Wolfenstein 3D Black Book, too.
The book starts off with forwards by John Carmack and Dave Taylor and a short introduction just to wet your appetite. Then it jumps into the hardware that Doom was designed for in chapter 2. Doom was able to run on an i386, but by 1993 when Doom was being developed, the i486 was becoming affordable and was over 2x faster than the equivalent frequency i386, so that was the new target system. Everything else was improving rapidly as well. Video cards took a big step up in performance with the VESA VL-Bus and tighter component integration on the cards. Sound cards became even more fragmented, unfortunately, but sound quality was improving by leaps and bounds. Networking was also becoming possible by this time with multiple ways to connect PCs for multiplayer co-op and deathmatch play. Finally, compilers had improved to the point where it wasn't necessary to do nearly everything in assembly. The Watcom compiler allowed id Software to code Doom almost entirely in C, freeing the developers to think at a higher level and implement more features more rapidly.
Chapter 3 is entirely new because id Software used an entirely different development environment for Doom. Instead of developing everything on unstable DOS PCs, they took the chance on using expensive NeXT workstations. Even a fairly basic NeXTstation cost $4,995 in 1991, and a NeXTcube ran $12,395! It turned out to be worth it, though, because these workstations were rock-solid and allowed John Carmack and the other developers to make incredible progress instead of constantly fighting with crashing machines and a poor development environment. This chapter did a great job going through the architecture and benefits of the NeXT systems, and how id Software used them to full effect.
The next chapter was about the team and tools, like chapter 3 in the Wolfenstein 3D book. Things had changed dramatically, with the team moving to Dallas, TX and growing to fourteen people by the end of development. The tools were evolving, too, with some of the character sprites and animation done using stop motion capture, and the map editor (DoomED) taking on new features to support the multitude of new capabilities in the game engine. Walls in the game no longer needed to be orthogonal, although they still had to be vertical for rendering to be fast enough. Floors and ceilings could change height to create steps, platforms, and other environmental features. Various kinds of traps and ambushes were also possible now. It's quite amazing how many features were added to idTech 1 when compared to the Wolf3D engine. These new features, especially the non-orthogonal walls and varying heights, required a more efficient data structure for the maps, and the BSP (Binary Space Partitioning) node tree was commandeered for the job.
Nearly half of the book is taken up by chapter 5 on the idTech 1 game engine. This chapter is just a monster of awesome information about the engine. It goes through every detail from the game tic design and use of fixed-point arithmetic to sound propagation and enemy AI. The section on the 3D renderer was especially interesting and detailed. There are great explanations on how the environment was drawn with its additional complexity, texture mapping with perspective correction, sprite clipping and animation, and diminished lighting to give the game its intense horror movie feel. This renderer section in particular was so interesting that it made me want to go implement a bunch of the algorithms myself just to be able to recreate them and see them in action. It looks like it would be immensely satisfying.
The last chapter described in fairly good detail how a number of ports of Doom were done on other game consoles. The console ports included the Atari Jaguar, Sega 32X, Super Nintendo, Sony PlayStation, 3DO, and Sega Saturn, and both the system architectures and Doom engine implementations are described. I was in high school during this era of the great console wars, although I never played Doom on any of them, just the excellent experience of the PC. I had forgotten how different these console architectures were, and some of the design decisions that went into those systems were truly remarkable...and strange. The sections on the Super Nintendo and PlayStation ports were my favorites. The Super Nintendo would have never been able to run Doom on its own, but with the extra power of the SuperFX chip that was used in Star Fox and a few other games, it was able to pull it off reasonably well. The PlayStation port was the most faithful of the ports, and even added some cool new features like colored ambient lighting. Of all of these systems, the PlayStation was exceptionally powerful for making great games. Even though other systems might have looked more powerful on paper, they all had disadvantages and unfortunate design decisions that handicapped them while the PlayStation was so easy to develop for that its potential could consistently be achieved in practice.
I enjoyed this book as much, if not more than the Wolf3D Black Book. From the beautiful full-color pictures to the detailed explanations of technical feature implementations to the well-chosen code listings sprinkled throughout the book, this was an incredibly fun guided tour of a legendary game engine. I devoured this book, and through it all, I wanted to do two things: go back and play through Doom again and re-implement some of those rendering algorithms for myself. I can't think of higher praise for a book, so if you've ever played Doom and want to know how it works, you need to go treat yourself to this book and the Wolfenstein 3D Black Book, too.
0 အမွတ္တရေျပာသြားတာ:
Post a Comment