Graphics Reference
In-Depth Information
Actually, the only thing we really need for this technique to work in general is that
the objects in the world have a different color from the object we are trying to move.
The reason is that we have been talking about color numbers and the association
between actual colors and their numbers is quite arbitrary and can be changed at will.
This will become clear later when we talk about color lookup tables. One can play
similar tricks with other bit operations such as or / and .
(6) Maintain several “pages” of information and “flip” between the pages. For
example, to show a walking man, one could precompute several different walking
positions of the man, and then cycle between them. Having predrawn images in
memory may very well be faster than computing them dynamically.
The speed of objects depends on how far apart they are drawn in succession. A
basic way to keep track of multiple moving figures is to cycle through them. One can
keep track of them using arrays. If objects overlap but one knows their relative
distances from the viewer one can prioritize them by distance and use a painter's algo-
rithm (see Chapter 7) and draw the nearer objects last.
One big problem with multiple objects is collision detection. Bounding boxes (see
Chapter 6) may be helpful in cutting down on the amount of computation if the objects
are complicated. Sometimes one knows where collisions can occur and then one only
has to check in those places. One potential problem is shown in Figure 2.23 where
two objects crossed paths but no collision would have been detected since one only
checks for that in their final position. To handle that one could keep track of the paths
of objects and check their intersections.
Now, the methods above have lots of constraints and will only work in certain sit-
uations. In (2) and (3), each figure has to fit into a block with a fixed background in
that block. The methods also tend to be slow. However, in the early days of the per-
sonal computer the graphics system did not give developers much to work with. There
is another issue in the case of CRTs that was alluded to briefly in Section 1.3. Writing
a block of memory to the frame buffer while the hardware is scanning it and dis-
playing the picture will usually cause flicker in the image. This is caused by the fact
that the scan is much faster than the memory writes and during one scan only part
of the memory block may have been written. To get flicker-free images a programmer
would have to be very careful about the timing of the writes, which would usually be
done during the vertical retrace of the beam. Furthermore, everything would have to
be done in assembly language to get maximum speed. Fortunately, by using APIs like
Figure 2.23.
A collision-detection problem.
Search WWH ::




Custom Search