124 lines
2.8 KiB
Markdown
124 lines
2.8 KiB
Markdown
Another limitation of bit-plane animation is that it's best if images
|
||
stored in the same plane never cross each other. Why? Because when
|
||
images do cross, the blank fringe
|
||
|
||
* * * * *
|
||
|
||
Palette Register
|
||
|
||
Register Setting
|
||
|
||
* * * * *
|
||
|
||
0
|
||
|
||
00H (black)
|
||
|
||
1
|
||
|
||
01H (blue)
|
||
|
||
2
|
||
|
||
02H (green)
|
||
|
||
3
|
||
|
||
03H (cyan)
|
||
|
||
4
|
||
|
||
04H (red)
|
||
|
||
5
|
||
|
||
05H (magenta)
|
||
|
||
6
|
||
|
||
14H (brown)
|
||
|
||
7
|
||
|
||
07H (light gray)
|
||
|
||
8
|
||
|
||
3EH (yellow)
|
||
|
||
9
|
||
|
||
3EH (yellow)
|
||
|
||
10
|
||
|
||
3EH (yellow)
|
||
|
||
1
|
||
|
||
13EH (yellow)
|
||
|
||
12
|
||
|
||
3EH (yellow)
|
||
|
||
13
|
||
|
||
3EH (yellow)
|
||
|
||
14
|
||
|
||
3EH (yellow)
|
||
|
||
15
|
||
|
||
3EH (yellow)
|
||
|
||
* * * * *
|
||
|
||
Table 43.2 Palette RAM settings for two-plane animation.
|
||
|
||
* * * * *
|
||
|
||
around each image can temporarily erase the overlapped parts of the
|
||
other image or images, resulting in momentary flicker. While that's not
|
||
fatal, it certainly detracts from the rock-solid animation effect of
|
||
bit-plane animation.
|
||
|
||
Not allowing images in the same plane to overlap is actually less of a
|
||
limitation than it seems. Run Listing 43.1 again. Unless you were
|
||
looking for it, you'd never notice that images of the same color almost
|
||
never overlap—there's plenty of action to distract the eye, and the
|
||
trajectories of images of the same color are arranged so that they have
|
||
a full range of motion without running into each other. The only
|
||
exception is the chain of green images, which occasionally doubles back
|
||
on itself when it bounces directly into a corner and reverses direction.
|
||
Here, however, the images are moving so quickly that the brief moment
|
||
during which one image's fringe blanks a portion of another image is
|
||
noticeable only upon close inspection, and not particularly unaesthetic
|
||
even then.
|
||
|
||
\
|
||
**Figure 43.5** *Pixel precedence for plane 3 only.*
|
||
|
||
When a technique has such tremendous visual and performance advantages
|
||
as does bit-plane animation, it behooves you to design your animation
|
||
software so that the limitations of the animation technique don't get in
|
||
the way. For example, you might design a shooting gallery game with all
|
||
the images in a given plane marching along in step in a continuous band.
|
||
The images could never overlap, so bit-plane animation would produce
|
||
very high image quality.
|
||
|
||
### Shearing and Page Flipping {#Heading7}
|
||
|
||
As Listing 43.1 runs, you may occasionally see an image shear, with the
|
||
top and bottom parts of the image briefly offset. This is a consequence
|
||
of drawing an image directly into memory as that memory is being scanned
|
||
for video data. Occasionally the CRT controller scans a given area of
|
||
display memory for pixel data just as the program is changing that same
|
||
memory. If the CRT controller scans memory faster than the CPU can
|
||
modify that memory, then the CRT controller can scan out the bytes of
|
||
display memory that have been already been changed, pass the point in
|
||
the image that the CPU is currently drawing, and start scanning out
|
||
bytes that haven't yet been changed. The result: Mismatched upper and
|
||
lower portions of the image.
|