|Previous||Table of Contents||Next|
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, its important to keep in mind that theres a large chunk of the human mind that doesnt work in a linear fashion.
Ive 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, theres nothing worse than debugging someone elses code; theres always the nasty feeling that you dont quite know whats going on. The overall operation of this code wouldnt 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 notbut as for me, it hit me exactly right. started laughing helplessly, tears rolling down my face. When went back to workpresto!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 wellbut that its 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 Ive had to field a lot of questions about whether Im a Zen disciple. Im notactually, Im more of a Dave Barry disciple. If you dont know who Dave Barry is, you should; hes good for your right brain.) Give your mind a break once in a while, and Ill bet youll find youre more productive.
Were strange thinking machines, but were the best ones yet invented, and its worth learning how to tap our full potential. And with that, its back to dirty-rectangle animation.
In the last chapter, Introduced the idea of dirty-rectangle animation. This technique is an alternative to page flipping thats 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 dont support page flipping. Dirty-rectangle animation also tends to be simpler to implement than page flipping, because theres only one bitmap to keep track of. A final advantage of dirty-rectangle animation is that its 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 45s animation was also less than ideal, for reasons well explore shortly. The code in Listings 46.1 and 46.2 addresses the shortcomings of Chapter 45s 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 isnt 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 Ive converted the code from using rectangular images to using masked images.
|Previous||Table of Contents||Next|