Initial conversion to markdown

46-01.md

@@ -0,0 +1,97 @@
+  ------------------------ --------------------------------- --------------------
+  [Previous](45-06.html)   [Table of Contents](index.html)   [Next](46-02.html)
+  ------------------------ --------------------------------- --------------------
+
+Chapter 46\
+ Who Was that Masked Image? {#Heading1}
+---------------------------
+
+### Optimizing Dirty-Rectangle Animation {#Heading2}
+
+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 {#Heading3}
+
+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](45-06.html)   [Table of Contents](index.html)   [Next](46-02.html)
+  ------------------------ --------------------------------- --------------------
+
+* * * * *
+
+Graphics Programming Black Book © 2001 Michael Abrash