Initial conversion to markdown
This commit is contained in:
James Gregory
parent
a96a114403
commit
5e10794a24
362 changed files with 67353 additions and 0 deletions
146
43-01.md
Normal file
146
43-01.md
Normal file
|
|
@ -0,0 +1,146 @@
|
|||
------------------------ --------------------------------- --------------------
|
||||
[Previous](42-05.html) [Table of Contents](index.html) [Next](43-02.html)
|
||||
------------------------ --------------------------------- --------------------
|
||||
|
||||
Chapter 43\
|
||||
Bit-Plane Animation {#Heading1}
|
||||
--------------------
|
||||
|
||||
### A Simple and Extremely Fast Animation Method for Limited Color {#Heading2}
|
||||
|
||||
When it comes to computers, my first love is animation. There’s nothing
|
||||
quite like the satisfaction of fooling the eye and creating a miniature
|
||||
reality simply by rearranging a few bytes of display memory. What makes
|
||||
animation particularly interesting is that it has to happen fast (as
|
||||
measured in human time), and without blinking and flickering, or else
|
||||
you risk destroying the illusion of motion and solidity. Those
|
||||
constraints make animation the toughest graphics challenge—and also the
|
||||
most rewarding.
|
||||
|
||||
It pains me to hear industry pundits rag on the PC when it comes to
|
||||
animation. Okay, I’ll grant you that the PC isn’t a Silicon Graphics
|
||||
workstation and never will be, but then neither is anything else on the
|
||||
market. The VGA offers good resolution and color, and while the hardware
|
||||
wasn’t *designed* for animation, that doesn’t mean we can’t put it to
|
||||
work in that capacity. One lesson that any good PC graphics or assembly
|
||||
programmer learns quickly is that it’s what the PC’s hardware *can*
|
||||
do—not what it was intended to do—that’s important. (By the way, if I
|
||||
were to pick one aspect of the PC to dump on, it would be sound, not
|
||||
animation. The PC’s sound circuity really is lousy, and it’s hard to
|
||||
understand why that should be, given that a cheap sound chip—which even
|
||||
the almost-forgotten PC*jr*had—would have changed everything. I guess
|
||||
IBM figured “serious” computer users would be put off by a computer that
|
||||
could make fun noises.)
|
||||
|
||||
Anyway, my point is that the PC’s animation capabilities are pretty
|
||||
good. There’s a trick, though: You can only push the VGA to its
|
||||
animation limits by stretching your mind a bit and using some unorthodox
|
||||
approaches to animation. In fact, stretching your mind is the key to
|
||||
producing good code for *any* task on the PC—that’s the topic of the
|
||||
first part of this book. For most software, however, it’s not fatal if
|
||||
your code isn’t excellent—there’s slow but functional software all over
|
||||
the place. When it comes to VGA animation, though, you won’t get to
|
||||
first base without a clever approach.
|
||||
|
||||
So, what clever approaches do I have in mind? All sorts. The resources
|
||||
of the VGA (or even its now-ancient predecessor, the EGA) are many and
|
||||
varied, and can be applied and combined in hundreds of ways to produce
|
||||
effective animation. For example, refer back to Chapter 23 for an
|
||||
example of page flipping. Or look at the July 1986 issue of *PC Tech
|
||||
Journal*, which describes the basic block-move animation technique, or
|
||||
the August 1987 issue of *PC Tech Journal*, which shows a
|
||||
software-sprite scheme built around the EGA’s vertical interrupt and the
|
||||
AND-OR image drawing technique. Or look over the rest of this book,
|
||||
which contains dozens of tips and tricks that can be applied to
|
||||
animation, including Mode X-based techniques starting in Chapter 47 that
|
||||
are the basis for many commercial games.
|
||||
|
||||
This chapter adds yet another sort of animation to the list. We’re going
|
||||
to take advantage of the bit-plane architecture and color palette of the
|
||||
VGA to develop an animation architecture that can handle several
|
||||
overlapping images with terrific speed and with virtually perfect visual
|
||||
quality. This technique produces no overlap effects or flicker and
|
||||
allows us to use the fastest possible method to draw images—the **REP
|
||||
MOVS** instruction. It has its limitations, but unlike Mode X and some
|
||||
other animation techniques, the techniques I’ll show you in this chapter
|
||||
will also work on the EGA, which may be important in some applications.
|
||||
|
||||
As with any technique on the PC, there are tradeoffs involved with
|
||||
bit-plane animation. While bit-plane animation is extremely attractive
|
||||
as far as performance and visual quality are concerned, it is somewhat
|
||||
limited. Bit-plane animation supports only four colors plus the
|
||||
background color at any one time, each image must consist of only one of
|
||||
the four colors, and it’s preferable that images of the same color not
|
||||
intersect.
|
||||
|
||||
It doesn’t much matter if bit-plane animation isn’t perfect for all
|
||||
applications, though. The real point of showing you bit-plane animation
|
||||
is to bring home the reality that the VGA is a complex adapter with many
|
||||
resources, and that you can do remarkable things if you understand those
|
||||
resources and come up with creative ways to put them to work at specific
|
||||
tasks.
|
||||
|
||||
### Bit-Planes: The Basics {#Heading3}
|
||||
|
||||
The underlying principle of bit-plane animation is extremely simple. The
|
||||
VGA has four separate bit planes in modes 0DH, 0EH, 10H, and 12H. Plane
|
||||
0 normally contains data for the blue component of pixel color, plane 1
|
||||
normally contains green pixel data, plane 2 red pixel data, and plane 3
|
||||
intensity pixel data—but we’re going to mix that up a bit in a moment,
|
||||
so we’ll simply refer to them as planes 0, 1, 2, and 3 from now on.
|
||||
|
||||
Each bit plane can be written to independently. The contents of the four
|
||||
bit planes are used to generate pixels, with the four bits that control
|
||||
the color of each pixel coming from the four planes. However, the bits
|
||||
from the planes go through a look-up stage on the way to becoming
|
||||
pixels—they’re used to look up a 6-bit color from one of the sixteen
|
||||
palette registers. Figure 43.1 shows how the bits from the four planes
|
||||
feed into the palette registers to select the color of each pixel. (On
|
||||
the VGA specifically, the output of the palette registers goes to the
|
||||
DAC for an additional look-up stage, as described in Chapters 33 and 34
|
||||
and also Chapter A on the companion CD-ROM.)
|
||||
|
||||
Take a good look at Figure 43.1. Any light bulbs going on over your head
|
||||
yet? If not, consider this. The general problem with VGA animation is
|
||||
that it’s complex and time-consuming to manipulate images that span the
|
||||
four planes (as most do), and that it’s hard to avoid interference
|
||||
problems when images intersect, since those images share the same bits
|
||||
in display memory. Since the four bit planes can be written to and read
|
||||
from independently, it should be apparent that if we could come up with
|
||||
a way to display images from each plane independently of whatever images
|
||||
are stored in the other planes, we would have four sets of images that
|
||||
we could manipulate very easily. There would be no interference effects
|
||||
between images in different planes, because images in one plane wouldn’t
|
||||
share bits with images in another plane. What’s more, since all the bits
|
||||
for a given image would reside in a single plane, we could do away with
|
||||
the cumbersome programming of the VGA’s complex hardware that is needed
|
||||
to manipulate images that span multiple planes.
|
||||
|
||||
\
|
||||
**Figure 43.1** *How 4 bits of video data become 6 bits of color.*
|
||||
|
||||
All in all, it would be a good deal if we could store each image in a
|
||||
single plane, as shown in Figure 43.2. However, a problem arises when
|
||||
images in different planes overlap, as shown in Figure 43.3. The
|
||||
combined bits from overlapping images generate new colors, so the
|
||||
overlapping parts of the images don’t look like they belong to either of
|
||||
the two images. What we really want, of course, is for one of the images
|
||||
to appear to be in front of the other. It would be better yet if the
|
||||
rearward image showed through any transparent (that is,
|
||||
background-colored) parts of the forward image. Can we do that?
|
||||
|
||||
You bet.
|
||||
|
||||
\
|
||||
**Figure 43.2** *Storing images in separate planes.*
|
||||
|
||||
\
|
||||
**Figure 43.3** *The problem of overlapping colors.*
|
||||
|
||||
------------------------ --------------------------------- --------------------
|
||||
[Previous](42-05.html) [Table of Contents](index.html) [Next](43-02.html)
|
||||
------------------------ --------------------------------- --------------------
|
||||
|
||||
* * * * *
|
||||
|
||||
Graphics Programming Black Book © 2001 Michael Abrash
|
||||
Loading…
Reference in a new issue