abrash-black-book/43-06.md
2013-12-30 20:26:41 +11:00

64 lines
3.6 KiB
Markdown

If the CRT controller scans more slowly than the CPU can modify memory
(likely with a 386, a fast VGA, and narrow images), then the CPU can rip
right past the CRT controller, with the same net result of mismatched
top and bottom parts of the image, as the CRT controller scans out first
unchanged bytes and then changed bytes. Basically, shear will
occasionally occur unless the CPU and CRT proceed at exactly the same
rate, which is most unlikely. Shear is more noticeable when there are
fewer but larger images, since it's more apparent when a larger screen
area is sheared, and because it's easier to spot one out of three large
images momentarily shearing than one out of twenty small images.
Image shear isn't terrible—I've written and sold several games in which
images occasionally shear, and I've never heard anyone complain—but
neither is it ideal. One solution is page flipping, in which drawing is
done to a non-displayed page of display memory while another page of
display memory is shown on the screen. (We saw page flipping back in
Chapter 23, we'll see it again in the next chapter, and we'll use it
heavily starting in Chapter 47.) When the drawing is finished, the
newly-drawn part of display memory is made the displayed page, so that
the new screen becomes visible all at once, with no shearing or flicker.
The other page is then drawn to, and when the drawing is complete the
display is switched back to that page.
Page flipping can be used in conjunction with bit-plane animation,
although page flipping does diminish some of the unique advantages of
bit-plane animation. Page flipping produces animation of the highest
visual quality whether bit-plane animation is used or not. There are a
few drawbacks to page flipping, however.
Page flipping requires two display memory buffers, one to draw in and
one to display at any given time. Unfortunately, in mode 12H there just
isn't enough memory for two buffers, so page flipping is not an option
in that mode.
Also, page flipping requires that you keep the contents of both buffers
up to date, which can require a good deal of extra drawing.
Finally, page flipping requires that you wait until you're sure the page
has flipped before you start drawing to the other page. Otherwise, you
could end up modifying a page while it's still being displayed,
defeating the whole purpose of page flipping. Waiting for pages to flip
takes time and can slow overall performance significantly. What's more,
it's sometimes difficult to be sure when the page has flipped, since not
all VGA clones implement the display adapter status bits and page flip
timing identically.
To sum up, bit-plane animation by itself is very fast and looks good. In
conjunction with page flipping, bit-plane animation looks a little
better but is slower, and the overall animation scheme is more difficult
to implement and perhaps a bit less reliable on some computers.
### Beating the Odds in the Jaw-Dropping Contest {#Heading8}
Bit-plane animation is neat stuff. Heck, good animation of *any* sort is
fun, and the PC is as good a place as any (well, almost any) to make
people's jaws drop. (Certainly it's the place to go if you want to make
a *lot* of jaws drop.) Don't let anyone tell you that you can't do good
animation on the PC. You can—*if* you stretch your mind to find ways to
bring the full power of the VGA to bear on your applications. Bit-plane
animation isn't for every task; neither are page flipping,
exclusive-ORing, pixel panning, or any of the many other animation
techniques you have available. One or more tricks from that grab-bag
should give you what you need, though, and the bigger your grab-bag, the
better your programs.