C/C++ Windoze programmers who want to learn to write applications that use Microsoft's confusing API

Contributing: If anyone out there is interested in contributing to this tutorial (I would love to make it better but am limited by time/energy constraints) then please let me know (feedback.html.)

Bugs:I have been made aware of a couple of bugs in the code sample. One day far in the future when I find time I will fix them.

Please let me know if you find any mistakes in the article.

1999/04/20: I have added a new not-quite-complete sample, ddsamp (no MFC, phew!). This demonstrates the PutPixel method described in 5.1.2. I made it with Visual C++ 6, but if you have an incompatible compiler you should still be able to just the source files in any project you create.

Some words about DirectX: 

The next few paragraphs constitute my commentary and critique of DirectX. I am soap-boxing; so you can skip the rest of this section if you don't want to hear my rants.

I wrote the following paragraph last December 1998.

I know this tutorial is a bit brief, somewhat inadequate and has a few bugs, but at the moment I've practically stopped doing any programming using DirectX, and have thus also for the moment stopped updating this tutorial. I grew to dislike the DirectX API; it is bulky, it is overcomplicated, it is proprietary, it is poorly designed, and there is no technical reason for the existence of large portions of it, such as Direct3D (a much better job could have been done with the existing industry standard 3D API OpenGL for example.) Besides all this, the chief reason I stopped is that I do not find programming with DirectX fun (your mileage may vary); I got into programming because for me it was fun, and it is no good to me to program if I am not having fun. None of this is to say that you should not learn DirectX. Industrially, its existence is extremely useful, and the amount of driver support from hardware vendors is unmatched by anything else. It is also generally the best (more like only) option if you wish to create cutting edge games for the Windows platform, which is probably why many of you are reading this. The number of great games using DirectX technology is also testimony to what is right about it. As things stand in the industry right now, you can not go wrong by learning DirectX. Don't be discouraged just because I personally do not like it.

Well, for a number of reasons, I am back in a job where I will be doing DirectX programming. I still do not like the API. I want newbie game programmers to realise that DirectX is not an example of a decent API design. Don't get me wrong - what DirectX does is good, and there is a definite need that DirectX fills. But its design is awful. The way things are in the computer industry right now, Microsoft does not have to worry about coming up with something decent - people will use whatever they push, and they know it. This lack of competition has a negative effect on the quality of code that is produced. My advice to newbie programmers is that you should learn how to be critical of ANY software design - you should learn how to recognize quality and lack of it. Never just accept that something is good just because it is the current standard. Right now, we are stuck with DirectX, and we will be using it for many years to come; but in the future, developers should stand up against bad design, and demand quality. If you want to examine various alternate designs for gaming API's, see my section on X/Linux programming at xprog.html. None of the available ones are, however, as feature-rich as DirectX. 

To be fair to Microsoft, they have made some reasonable attempts to improve DirectX - for example, the addition of DirectPrimitive. However, I don't believe in starting with rubbish and then trying to patch it up as best you can. As they say, "Garbage In, Garbage Out". The baggage of execute buffers will still be there with the release of DirectX 3000.