At the start of each display, the system loads the colors from the
ViewPort's color table into the display's hardware registers, so whatever
is rendered into the BitMap is displayed correctly. But if the VSprite
system is used, and the colors are specified (via SprColors) for each
VSprite, the SprColors will be loaded by the system into the display
hardware, as needed. The system does this by generating Copper
instructions that will jam the colors into the hardware at specific
moments in the display cycle.  Any BitMap rendering, including Bobs, which
share colors with VSprites, may change colors constantly as the video
display beam progresses down the screen.

This color changing can be avoided by taking one of the following
precautions:

  * Use a four bitplane playfield, which only allows the lower 16 colors
    to be rendered into the BitMap (and allows Hires display mode).

  * If a 32-color playfield display is being used, avoid rendering in
    colors 17-19, 21-23, 25-27, and 29-32, which are the colors affected
    by the VSprite system.

  * Specify the VSprite SprColors pointer as a value of NULL to avoid
    changing the contents of any of the hardware sprite color registers.
    This may cause the VSprites to change colors depending on their
    positions relative to each other, as described in the
    previous section.