Previous Table of Contents Next

Chapter 46
Who Was that Masked Image?

Optimizing Dirty-Rectangle Animation

Programming is, by and large, a linear process. One statement or instruction follows another, in predictable sequences, with tiny building blocks strung together to make thinking, which is, of course, A Good Thing. Still, it’s important to keep in mind that there’s a large chunk of the human mind that doesn’t work in a linear fashion.

I’ve written elsewhere about the virtues of nonlinear/right-brain/lateral/what-have-you thinking in solving tough programming problems, such as debugging or optimization, but it bears repeating. The mind can be an awesome pattern-matching and extrapolation tool, if you let it. For example, the other day was grinding my way through a particularly difficult bit of debugging. The code had been written by someone else, and, to my mind, there’s nothing worse than debugging someone else’s code; there’s always the nasty feeling that you don’t quite know what’s going on. The overall operation of this code wouldn’t come clear in my head, no matter how long stared at it, leaving me with a rising sense of frustration and a determination not to quit until got this bug.

In the midst of this, a coworker poked his head through the door and told me he had something had to listen to. Reluctantly, went to his office, whereupon he played a tape of what is surely one of the most bizarre 911 calls in history. No doubt some of you have heard this tape, which will briefly describe as involving a deer destroying the interior of a car and biting a man in the neck. Perhaps you found it funny, perhaps not—but as for me, it hit me exactly right. started laughing helplessly, tears rolling down my face. When went back to work—presto!—the pieces of the debugging puzzle had come together in my head, and the work went quickly and easily.

Obviously, my mind needed a break from linear, left-brain, push-it-out thinking, so it could do the sort of integrating work it does so well—but that it’s rarely willing to do under conscious control. It was exactly this sort of thinking had in mind when titled my 1989 optimization book of Zen of Assembly Language. (Although must admit that few people seem to have gotten the connection, and I’ve had to field a lot of questions about whether I’m a Zen disciple. I’m not—actually, I’m more of a Dave Barry disciple. If you don’t know who Dave Barry is, you should; he’s good for your right brain.) Give your mind a break once in a while, and I’ll bet you’ll find you’re more productive.

We’re strange thinking machines, but we’re the best ones yet invented, and it’s worth learning how to tap our full potential. And with that, it’s back to dirty-rectangle animation.

Dirty-Rectangle Animation, Continued

In the last chapter, Introduced the idea of dirty-rectangle animation. This technique is an alternative to page flipping that’s capable of producing animation of very high visual quality, without any help at all from video hardware, and without the need for any extra, nondisplayed video memory. This makes dirty-rectangle animation more widely usable than page flipping, because many adapters don’t support page flipping. Dirty-rectangle animation also tends to be simpler to implement than page flipping, because there’s only one bitmap to keep track of. A final advantage of dirty-rectangle animation is that it’s potentially somewhat faster than page flipping, because display-memory accesses can theoretically be reduced to exactly one access for each pixel that changes from one frame to the next.

The speed advantage of dirty-rectangle animation was entirely theoretical in the previous chapter, because the implementation was completely in C, and because no attempt was made to minimize display memory accesses. The visual quality of Chapter 45’s animation was also less than ideal, for reasons we’ll explore shortly. The code in Listings 46.1 and 46.2 addresses the shortcomings of Chapter 45’s code.

Listing 46.2 implements the low-level drawing routines in assembly language, which boosts performance a good deal. For maximum performance, it would be worthwhile to convert more of Listing 46.1 into assembly, so a call isn’t required for each animated image, and overall performance could be improved by streamlining the C code, but Listing 46.2 goes a long way toward boosting animation speed. This program now supports snappy animation of 15 images (as opposed to 10 for the software presented in the last chapter), and the images are now two pixels wider. That level of performance is all the more impressive considering that for this chapter I’ve converted the code from using rectangular images to using masked images.

Previous Table of Contents Next

Graphics Programming Black Book © 2001 Michael Abrash