This chapter is definitely a very meaty chapter full of intense technical details on the use of DirectDraw. I would have benefitted greatly from reading this chapter during the Compulsive days. As I was reading this, though, I began to wonder how niche of an audience this chapter would appeal to.

The Casino stuff we worked on during the Compulsive days and before catered to those who had no 3D acceleration cards, and so we were forced to stick to using DirectDraw for our sprites, and perform custom alpha blitting routines because there was no hardware support for 2D alpha blitting.

At this point, I began to contemplate who exactly the target audience must be for your book?

If the target audience includes the veteran programmer who may already be in the industry, then a major obstacle in their interest for this chapter would be the fact that it is standard in most games to require hardware acceleration in order to play their product. If 2D graphics are what the veteran is interested in, then there is a low probablity that the veteran is in the same boat as Compulsive was where they had to cater to those without hardware acceleration. There are those that are developing 2D for handheld PCs or maybe the Game Boy Advance... this chapter may not help them very much because it is very technology-specific.

If the target audience would include novice programmers hoping to get a job in the industry or just know how to do stuff, then this chapter may not help them much because they would probably rather do their sprites using Direct3D. There is a Direct3D utility class (XSprite?) that emulates sprites in every way, but with the benefit of hardware acceleration. If I were to create a sprite-based project, chances are, I would disregard the relatively small (and shrinking) percentage of the computing population that doesn't use hardware acceleration on their machines. During a research phase, I was able to draw 101 alpha-blitted 3D sprites that each took up about a quarter of the (800x600) screen at a rate of over 60 frames per second... on my 2.8 gig GeForce 3. Even though it was a high end machine, I think it is an indication that when you don't consider the hardware acceleration constraint, then you're able to achieve much more in the performance, and that may be more important to the reader than being compatible with all common denominations of computers.

It may help to emphasize the uniqueness of the situation that would cause the reader to want to use the information in chapter 6.

I also wanted to read the 3D chapter before I wrote feedback on this because maybe you might talk about the 3DSprites within the 3D chapter.

As a fan of the 2D genre of videogames, it saddens me to admit that 2D programming is looked down upon in game development as much as Visual Basic is looked down upon by C++ programmers. With that said, I'd also advise that you make your 3D Graphics chapter just as meaty, if not meatier, than your 2D Graphics chapter... for the sake of perception by your audience. It was the mistake that Andre LaMothe made in his game programming books, that he was more 2D programmer than 3D programmer, among other things... and the market now is very much a 3D market.

Other directions you can take with this chapter or the 3D chapter is the following (mere suggestions):

1) Specify how this technology applies to textures used in 3D graphics. Maybe show how to display an animating texture from Bink? I'm finding animating textures to be a common motif, lately.

2) Enlarge the scope of this chapter to include the use of DirectDraw AND the use of Direct3D's XSprite(?) class, just to prove you are aware of both.

...also, Drawing font on textures, that's another thing I would like to learn. There seems to be two ways of doing fonts on textures.... one way is two triangles per letter, but is there actually a way to just paint the font like in DirectDraw? I wonder.

I assume Kain's talking about D3D...?

In D3D8 you can't get a DC for a surface. You can in D3D9, however there are a host of restrictions and because it locks the surface you should only do it if you know the texture isn't in the pipeline -- else severe performance hit. Even then, you're putting a lot of faith in the driver.

Personally, I would use GDI only for debug situations or maybe painting textures at start of day.