Join the largest DeFi ICO (new crypto coin offering) in 2021 »
HOME · Welcome. This is my earlier site (~1997 to 2010); my new website is now here but some stuff remains on the scorpioncity site. - David Joffe
Game programming with DirectX
[ Home | Chapter 1 | Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 ]

Chapter 1 - Introduction to DirectX

1. A few quick words about these articles

This document and all files and code provided with it are provided "as is" and without any warranty at all, not even the implied warranty of fitness of use for any particular purpose. I am not responsible for any harm that might come from use or misuse of either this document or any of the files available for download from this site. Neither is there any guarantee that the information in this document is correct. If you do not agree to this, go away, stop reading this.

The samples in this document are developed for Visual C/C++ MFC applications, but most of the material covered is pretty much MFC-independent; so don't worry too much if you don't know MFC.

The top-level page to this tutorial contains a list of Frequently Asked Questions. See this first if you have any problems; your question may well be there.

2. What is DirectX?

Before the release of Windows 95, most games were developed for the DOS platform, usually using something like DOS4GW or some other 32-bit DOS extender to obtain access to 32-bit protected mode. Windows 95, however, seemed to signal the beginning of the end of the DOS prompt. Games developers began to wonder how they were going to write games optimally that would run under Windows 95 - games typically need to run in full-screen mode, and need to get as close as possible to your hardware. Windows 95 seemed to be "getting in the way" of this. DOS had allowed them to program as "close to the metal" as possible, that is, get straight to the hardware, without going through layers of abstraction and encapsulation. In those days, the extra overhead of a generic API would have made games too slow.

So Microsoft's answer to this problem was a Software Development Kit (SDK) called DirectX. DirectX was a horrible, clunky, poorly-designed, poorly-documented, bloated, ugly, confusing beast (*) of an API (Application Programming Interface), that was originally purchased from a London company called RenderMorphics, and first seriously released by Microsoft as "DirectX 3", who began to push it as the games programming API of the future. Given the power of their position in the market, they succeeded. Hardware vendors quickly realised that following the Microsoft lead was the prudent thing to do (a few that didn't, went under), and soon everyone began to produce DirectX drivers for their hardware. In many ways this was a good thing for game developers.

The current version (at time of writing this paragraph) is DirectX 7. A lot of improvements have been made to the original DirectX. For example, the documentation doesn't suck as much as it originally did. Some of the poorly designed sections of the original API have been cleanup up and improved. Some of the really poorly designed sections of the original API have been removed.

One of the main purposes of DirectX is to provide a standard way of accessing many different proprietary hardware devices. For example, Direct3D provides a "standard" programming interface that can be used to access the 3D hardware acceleration features of almost all 3D cards on the market that have Direct3D drivers written for them. In theory this is supposed to make it possible for one application to transparently run as it is supposed to across a wide variety of different hardware configurations. In practice, it usually isn't this simple.

One of the reasons it isn't that simple, is that hardware (such as 3D graphics accelerators) normally only support a subset of the features available in DirectX, and you don't really want to use a feature if it isn't available in some sort of hardware accelerated form. To find out which features are available you have to query a device for a list of capabilities, and there can be many of these.

The DirectX API is designed primarily for writing games, but can be used in other types of applications as well. The API at the moment has five main sections:

2.1. DirectX Components

DirectDraw2 dimensional graphics capabilities, surfaces, double buffering, etc
Direct3DA relatively extensively functional 3D graphics programming API.
DirectSoundSound; 3D sound
DirectPlaySimplifies network game development
DirectInputHandles input from various peripherals

Additionally, DirectX 6(?check this) introduces something called DirectMusic, which is supposed to make it easier for game developers to include music in their games so that the mood of the music changes depending on what type of action is going on in the game.

3. DirectX performance and hardware acceleration

Although the performance of Direct3D in software only is not too shabby, it doesn't quite cut it for serious games. DirectX is designed with hardware acceleration in mind. It tries to provide the lowest possible level access to hardware, while still remaining a generic interface. Allowing functions such as 3D triangle drawing to be performed on the graphics card frees the CPU (Central Processing Unit) to do other things. Typical Direct3D hardware accelerators would also have at least 4 or preferably 16 or more Megabytes of onboard RAM to store texture maps (bitmapped images made up of small dots called "pixels"), textures, sprites, overlays and more.

DirectDraw and Direct3D are built as a relatively thin layer above the hardware, using what is called the DirectDraw "hardware abstraction layer" (HAL). For functionality not provided by a certain card, an equivalent software implementation would be provided through the "hardware emulation layer" (HEL).

Diagram illustrating where the DirectDraw/Direct3D architecture fits in, hopefully reasonably accurately.

4. DirectX and COM

The set of DirectX modules are built as COM (Component Object Model) objects. COM is yet another ugly broken interface from Microsoft - although newer versions of COM don't suck as much as the earlier incarnations. Don't get me wrong, I'm not against the existence of something that does what COM does - but the implementation leaves much to be desired. Anyway, a COM object is a bit like a C++ class, in that it encapsulates a set of methods and attributes in a single module, and in that it provides a kludgy sort of inheritance model, whereby one COM object can be built to support all the methods of it's parent object, and then add some more.

You don't need to know much about COM to use DirectX, so don't worry too much about it. You do a little bit of COM stuff when initializing objects and cleaning them up, and when checking return values of function calls, but that's more or less it.

(*) My own personal opinion. Yours may differ.
[ Home | Chapter 1 | Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 ]