[Coco] Impossibly-fast CoCo 3 sprites :)

[Roger Taylor]

At 10:31 PM 2/4/2008, you wrote:
>Roger Taylor wrote:
>
>>Each sprite gets it's own subroutine that uses direct values 
>>written to the screen with indexed addressing.
>
>So where do you think the main speed increase comes from? The "loop 
>unrolling", skipped transparent pixels, or faster opcodes 
>(addressing modes etc)

Mainly the use of direct writing to the screen where possible.  Only 
the edges of a sprite are broken into one-byte writes, while wider 
portions are stored as two bytes,  using precalculated screen offsets 
from reg.x which points to the top/left edge of the sprite, and ya 
can't unroll something that's not looped in the first place.  Each 
sprite is plotted byte for byte with no loops.  Skipping transparent 
pixels is definately part of the deal since I can't think of any 
reason on Earth why I'd want to convert sprites to opcodes and insist 
on plotting invisible pixels.  So the major speed increase comes from 
the things you mentioned above, and more, including the optimized 
sprite eraser/restorer.

>You realise that you're also one step closer to the dynamic 
>recompilation techniques used in MAME and various other emulators!?! 
>;) Of course in your case you're 'compiling' graphics primitives 
>rather than CPU code from another processor... but still...

In my case, generating a chunk of 6809 code to plot a sprite doesn't 
require labels or loops, so the code can be appended in one buffer 
while the start address of each sprite is saved in a JSR table.