Core Techniques and Algorithms in Game Programming2003

Since the advent of PC computers and before the release of Windows 95, PC games were coded under DOS. Developers had direct access to the hardware, which wasn't as powerful as it is today: no 3D cards, no sound, just a plain CPU and memory mapped frame buffer. Logically, many tips and tricks emerged from the game development community as a way to achieve top performance under this not-so-powerful hardware. All critical routines, for example, were systematically coded in hand-optimized assembly language: rendering cores, block data transfers, and many other tasks could be sped up by many orders of magnitude with some clever planning and deep hardware knowledge. These were the years when each graphics programmer kept his PutPixel routine, counted down to the clock cycles, a trade secret.

But there was more than putting pixels onscreen quickly. Another interesting technique was to overwrite the interrupt vector, and thus have greater control over tasks like keyboard input, timer control, and so on. By replacing specific interrupt handling routines using your own code, you could ensure very low-level access to any system event, from a key press to the internal PC timer, which ticked, if memory does not fail me, 18.2 times per second. This was a dangerous trick because any mistake in your code would leave the PC in an unstable state, often ending in a black screen and a reboot.

Under this context, Windows 95 was launched. Unlike Windows 3.1, Windows 95 was a full-blown 32-bit operating system that loaded at boot time, so everything had to be done from within the OS interface. Gone were the days of using DOS for playing games and typing "win" whenever we wanted to use Microsoft Word. As you can imagine, Windows 95 wasn't very popular with game developers in the early days. Low-level access to the hardware was restricted, and this meant a lot to game developers. The only games that could be played within the main OS interface were relatively simple, mine-sweeper-like games.

Thus, Microsoft decided to create a specific set of tools to allow game developers to code cutting edge games under Windows 95. These tools allowed access to devices the developers were asking for while keeping the system relatively safe. Luckily, these were the years when graphics cards grew up and became 3D accelerators, and audio boards were already mainstream. So, did developers need to access the frame buffer anymore? Well, not as much as years before. In fact, what was required was an intermediate, standard layer of code that exposed the continuous advances of the hardware to developers, so they could use it without directly accessing it. This layer would "understand" the different hardware configurations, and simply map calls to the hardware when possible.

This new product was initially called the Game Software Developer's Kit (SDK) and, as it began to slowly spread around the community, it was renamed DirectX. The first iterations (until DirectX 5) were highly experimental. Microsoft was internally evolving the product and incorporating suggestions from the game developers. Microsoft fought an uphill battle with game developers to convince them that the newborn API was in fact a pretty good idea. These were the years of some pretty crude flames in the famous DirectX versus OpenGL battle. Some developers criticized Microsoft for creating a new API (which for years was rather poor) when a stable, elegant API was already available. Whatever your opinion, the fact is that DirectX's design was greatly improved, having borrowed many ideas from OpenGL. Let's not forget that OpenGL is just a 3D API, whereas DirectX is much more. In fact, some modern games use DirectX for everything but graphics, preferring OpenGL for rendering tasks.

DirectX was updated often (more or less once a year), so each new iteration provided new calls for the newest features present in hardware. Whether it was painting a triangle or reading the joystick input, DirectX mapped new functionality through its API in a matter of months. From version 6 and later, DirectX became a rather good API and finally won widespread acceptance, especially as 3D cards became more and more popular.

Currently, DirectX is the dominant API for PC game development. It is also the driving force in Microsoft's Xbox, which is coded in a special version of DirectX 8. In the PC arena, OpenGL still retains a following of developers. In the end, it is all a matter of preference because both APIs are just interfaces to the hardware, and thus the functionality is nearly identical.

Many DirectX APIs were used in different chapters throughout this book. A complete summary of where they can be found is at the end of this chapter. Thus, we will only focus on Direct3D now, which incidentally is the only API we haven't devoted space to.