[Coco] Impossibly-fast CoCo 3 sprites :)
operator at coco3.com
Tue Feb 5 00:35:17 EST 2008
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
>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.
More information about the Coco