[Coco] [Color Computer] Chet Simpson's Sprite Compiler

[James Diffendaffer]

>>This was commonly used on the Speccy for large sprites so that less
>>manipulation of the pointer was required. And yes, sprite data was
>>stored in reverse order on even rows.
>
>
>The 6809 could do it either way without advantage or penalty. The 
>index
>pointer can be auto incremented or decremented. The only possible 
>advantage
>may be if doing it one way results in an 8-bit addition to get to the 
>next line rather than requiring a 16-bit addition.

Exactly.  We are talking about squeezing out every last clock cycle
here.  The Z80 suffered a bigger penalty than the 6809 so I know it
was common on the speccy.

>The best speed improvement would most likely actually be to draw the 
>bytes
>out of order entirely. Preload color/byte values which are repeated
>multiple times in the sprite images and write each of them in all
> their
>locations before moving onto the next color/byte values. This reduces
>loading operations (multiple stores per load instead of 1:1).

You'd just need to count every last clock cycle to make sure moving
the pointer in larger jumps didn't exceed the clocks for the extra loads.
With a clever game design you could actually design some sprites to
take advantage of this.  

I'm rebuilding some single color Atari sprites to be the same shapes
but with more colors and doing it by hand is tedious.
We really need a sprite designer that generates the sprite data or
code automatically.  


>
>John Kowalski (Sock Master)
>http://www.axess.com/twilight/sock/