[Coco] real-time mouse cursor
6809er at bjork-huffman.net
Sat Jan 26 10:42:59 EST 2008
After read my reply, I think I need to fill in a bit more on the details...
For any game or program that uses a GUI there is a graphics system
that updates the screen.
In most games the graphics system uses two screens, one to display
the current game image and the other to "build" the next game image
on. The reason for doing this way is to remove all game flicker.
Game flicker is caused by changing the graphics while the VDG (or
GIME) is displaying that page that graphics are changing. If you
build the game screen and then tell the VDG to "switch" to the new
game image then this removes the graphics flicker.
But there are two rules about screen switch:
First, you only switch when building the new screen is done. (That
simple and straight forward.)
Second, you only switch during the V-Blank. This one takes a little
The screen is built of about 243 scan lines but the TV image is about
262. (We are talk 60hz frames.) It is those extra scan lines that
you don't see are the V-blank and the perfect time switch the screen.
In most of my games, I would have the IRQ set to fire at the start of
the V-Blank and the IRQ code would do the switching to the new
screen, if need. (Then clear the "switch" flag to show the main code
that the screen was switched.)
The next item the IRQ would do is read the joystick reading. By
reading the joystick at the same level of noise created by the
monitor I would get less "jiggle" on the joystick reading.
Anyway, do the screen switching during the V-Blank made sure the game
would never flicker between the two screens.
Oh yes, The code would need to check if the "switch" flag was cleared
before making any changes on the next "build" screen.
At 06:58 AM 1/26/2008, you wrote:
>Roger, that is a lot of CPU time for drawing a mouse cursor.
>I would added the mouse cursor into the graphics system as a sprite
>and be done with it.
More information about the Coco