Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Initial conversion to markdown

Browse source
This commit is contained in:
James Gregory 2013-12-30 17:51:31 +11:00
commit 5e10794a24
362 changed files with 67353 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

110
43-04.md Normal file
View file

@ -0,0 +1,110 @@
------------------------ --------------------------------- --------------------
[Previous](43-03.html) [Table of Contents](index.html) [Next](43-05.html)
------------------------ --------------------------------- --------------------
For those of you who haven’t experienced the frustrations of animation
programming on a PC, there’s a *whole* lot of animation going on in
Listing 43.1. What’s more, the animation is virtually flicker-free,
partly thanks to bit-plane animation and partly because images are never
really erased but rather are simply overwritten. (The principle behind
the animation is that of redrawing each image with a blank fringe around
it when it moves, so that the blank fringe erases the part of the old
image that the new image doesn’t overwrite. For details on this sort of
animation, see the above-mentioned *PC Tech Journal* July 1986 article.)
Better yet, the red images take precedence over the green images, which
take precedence over the blue images, which take precedence over the
white backdrop, and all obscured images show through holes in and around
the edges of images in front of them.
In short, Listing 43.1 accomplishes everything we wished for earlier in
an animation technique.
If you possibly can, run Listing 43.1. The animation may be a revelation
to those of you who are used to weak, slow animation on PCs with EGA or
VGA adapters. Bit-plane animation makes the PC look an awful lot
like—dare I say it?—a games machine.
Listing 43.1 was designed to run at the absolute fastest speed, and as I
mentioned it puts in a pretty amazing performance on the slowest PCs of
all. Assuming you’ll be running Listing 43.1 on an faster computer,
you’ll have to crank up the **DELAY** equate at the start of Listing
43.1 to slow things down to a reasonable pace. (It’s not a very good
game where all the pieces are a continual blur!) Even on something as
modest as a 286-based AT, Listing 43.1 runs much too fast without a
substantial delay (although it does look rather interesting at warp
speed). We should all have such problems, eh? In fact, we could easily
increase the number of animated images past 20 on that old AT, and well
into the hundreds on a cutting-edge local-bus 486 or Pentium.
I’m not going to discuss Listing 43.1 in detail; the code is very
thoroughly commented and should speak for itself, and most of the
individual components of Listing 43.1—the Map Mask register, mode sets,
word versus byte **OUT** instructions to the VGA—have been covered in
earlier chapters. Do notice, however, that Listing 43.1 sets the palette
exactly as I described earlier. This is accomplished by passing a
pointer to a 17-byte array (1 byte for each of the 16 palette registers,
and 1 byte for the border color) to the BIOS video interrupt (**INT**
10H), function 10H, subfunction 2.
Bit-plane animation does have inherent limitations, which we’ll get to
in a second. One limitation that is *not* inherent to bit-plane
animation but simply a shortcoming of Listing 43.1 is somewhat choppy
horizontal motion. In the interests of both clarity and keeping Listing
43.1 to a reasonable length, I decided to byte-align all images
horizontally. This saved the many tables needed to define the 7
non-byte-aligned rotations of the images, as well as the code needed to
support rotation. Unfortunately, it also meant that the smallest
possible horizontal movement was 8 pixels (1 byte of display memory),
which is far enough to be noticeable at certain speeds. The situation
is, however, easily correctable with the additional rotations and code.
We’ll see an implementation of fully rotated images (in this case for
Mode X, but the principles generalize nicely) in Chapter 49. Vertically,
where there is no byte-alignment issue, the images move 4 or 6 pixels at
a times, resulting in considerably smoother animation.
The addition of code to support rotated images would also open the door
to support for internal animation, where the appearance of a given image
changes over time to suggest that the image is an active entity. For
example, propellers could whirl, jaws could snap, and jets could flare.
Bit-plane animation with bit-aligned images and internal animation can
look truly spectacular. It’s a sight worth seeing, particularly for
those who doubt the PC’s worth when it comes to animation.
### Limitations of Bit-Plane Animation {#Heading6}
As I’ve said, bit-plane animation is not perfect. For starters,
bit-plane animation can only be used in the VGA’s planar modes, modes
0DH, 0EH, 10H, and 12H. Also, the reprogramming of the palette registers
that provides image precedence also reduces the available color set from
the normal 16 colors to just 5 (one color per plane plus the background
color). Worse still, each image must consist entirely of only one of the
four colors. Mixing colors within an image is not allowed, since the
bits for each image are limited to a single plane and can therefore
select only one color. Finally, all images of the same precedence must
be the same color.
It is possible to work around the color limitations to some extent by
using only one or two planes for bit-plane animation, while reserving
the other planes for multi-color drawing. For example, you could use
plane 3 for bit-plane animation while using planes 0-2 for normal
8-color drawing. The images in plane 3 would then appear to be in front
of the 8-color images. If we wanted the plane 3 images to be yellow, we
could set up the palette registers as shown in Table 43.2.
As you can see, the color yellow is displayed whenever a pixel’s bit
from plane 3 is 1. This gives the images from plane 3 precedence, while
leaving us with the 8 normal low-intensity colors for images drawn
across the other 3 planes, as shown in Figure 43.5. Of course, this
approach provides only 1 rather than 3 high-precedence planes, but that
might be a good tradeoff for being able to draw multi-colored images as
a backdrop to the high-precedence images. For the right application,
high-speed flicker-free plane 3 images moving in front of an 8-color
backdrop could be a potent combination indeed.
------------------------ --------------------------------- --------------------
[Previous](43-03.html) [Table of Contents](index.html) [Next](43-05.html)
------------------------ --------------------------------- --------------------
* * * * *
Graphics Programming Black Book © 2001 Michael Abrash