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.
