[Coco] real-time mouse cursor

[Roger Taylor]

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 
>>updating stuff.
>>VSYNC   TST     $FF02
>>a@      TST     $FF03
>>         BPL     a@
>>         RTS
>
>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.