[Coco] real-time mouse cursor
operator at coco3.com
Sat Jan 26 22:18:27 EST 2008
At 07:57 PM 1/26/2008, you wrote:
>Roger Taylor wrote:
>>Hopefully others are paying attention to your tutes so they might
>>can dive into something graphics intensive. I've known for ages
>>most of what you're saying but the part about letting IRQ decide
>>when to switch the screen and having the main code not accidentally
>>get mixed up with the current state is something that carries a
>>little bit of worry since IRQ can happen at any time during the
>>main code execution, even if predictable at 60hz.
>>I mostly use the following VSYNC subroutine in all of my screen
>>VSYNC TST $FF02
>>a@ TST $FF03
>> BPL a@
>That's the way to use the PIA interrupt but as time is crucial, I'd
>suggest in-line code rather than a subroutine. That will remove the
>cycles needed to BSR or JSR and RTS.
>Are you writing for any Coco or just a Coco3? If the latter, you can
>also use the GIME interrupts.
I've thrown away the real-time cursor idea for now. There's no way
to do all the sprite save/draw/restore within one 60hz frame without
slowing down the front code tremendously. My game still runs but the
other 64 sprites (the jewels) move around pretty slow. The HSYNC
trick with tracking the raster beam and doing some work while a
sliding window passes down the screen around the mouse.y area can be
done and I've proved it, but it's too time consuming.
I've since reduced the hand-shaped cursor to a 16x16 sprite and added
it to the sprite table. The FIRQ interrupt only pumps sound and
occasionally samples the joystick at ideal times if the last sample
was 128, or if a certain time has passed to reduce popping, as in my
other game. The main code has sped up so much that I'm impressed at
how fast the 64 sprites are moving around considering I'm doing a lot
with the MMU and restoring the old sprite positions to the area that
was underneath which is from a backdrop image. So, there's 3
screens. 1 is the backdrop, 2 are for page flipping. I couldn't
even use stack blasting to erase each work screen prior to plotting
the sprites because it was still much slower than the restored area
method. I'm also using tricks to reuse registers, blast what I can,
do away with as much math as I can, and no loops for the sprite or
restored sprite rows.
FIRQ will save the current joystick values in sprite #0 in the table
and I'm hoping to find a way for the main code to grab the sprite
info while FIRQ isn't updating it. I don't want to mask interrupts
at any time.
I'm even going to use simulated mouse precision calcs to make the
cursor at least 160x100. It'll slide around a tad based on the
direction and speed of the mouse/joystick movement.
Next is on to adding the game logic that sets up the checkerboard,
lets you exchange any two h/v adjacent jewels, fills in the gaps
after a row or column clearout, etc. That will probably take a week
to get it smart enough to behave like the real game. I've reduced
the PCM timer to allow for non-MUSICA tracks. MUSICA waves seem to
work best at a certain frequency and the requirement is not ideal for
this game's framerate and # of sprites. Instead, I'll use real
samples at 8kz or less and tweak it until it sounds smooth and not
annoying (I hope). Still, optional tracks.
More information about the Coco