[Coco] Compiler Sprites

[Richard Goedeken]

Hi Allen,

I didn't know you worked for Microware; that's very interesting.  I grew up in
Cedar Rapids and went to school at ISU in Ames, so I was also nearby during
those times.

Regarding the sprite compilation, I don't know how Chet did it for the Coco
version of GR2K so I can't really compare the implementations, but I can
comment on some particular features of the DynoSprite implementation which I
think are noteworthy.

First, it's done automatically by the Python script and as such doesn't
require any development time.  If Chet had a sprite compiler as well then I'm
sure it was also an automatic system.

Another key feature of the sprite compiler that I wrote is that the code which
it outputs is very close to if not perfectly optimal for what it does.  In
most cases, a human could not write better code when doing it by hand.  This
took a lot of effort.  To give a simple example, if we needed to write out 5
pixels with a value of 0, a naive implementation might generate code like this:

lda ,x
anda #$F0
ora #$00
sta ,x
lda #0
sta 1,x
sta 2,x

Whereas my sprite compiler would write something like this:

lda ,x
anda #$F0
sta ,x
clra
clrb
std 1,x

And finally, my sprite compiler generates draw and erase routines which save
the background bytes before drawing the sprite, and replace them during the
erase operation.  This increases the complexity of the compiler by a
significant amount, and it also requires more 6809 cycles for drawing and
erasing, but it also allows for games which otherwise would not be possible
(basically anything with a top-down perspective, or textured backgrounds for a
side-scroller).  I'm sure that GR2K does not do this, because the background
is always black.  And if you look closely you can see that even Gantelet 2
does not properly mask out the sprite pixels.  My sprite compiler also can
generate both 6809 and 6309 routines, and the 6309 routines are about 25% faster.

For games which don't require the background pixel storage and replacement, it
would be possible to modify the sprite compiler to remove this feature (and
generate faster 6x09 code) but it would be quite a bit of work.

Richard

On 12/04/2014 07:48 AM, Allen Huffman wrote:
> I was working at Microware along with Eric Crichlow (GR2K MM1) and Chet
> Simpson (GR2K CoCo) during the days of "The Challenge". My memory is foggy,
> but I think it was Chet who first explained to me the concept of a blasting
> out bytes on a screen using assembly code rather than copy/paste type
> stuff. I may be wrong, but I think he used that technique in GR2K CoCo and
> had a sprite compiler.
> 
> What is it about your implementation that makes it different? I thought it
> was just looking at some bytes (the sprite bitmap) and emitting 6809
> assembly statements that would recreate those bytes?
> 
> I really need to learn how to get MESS going again on my Mac. I want to
> play with this.
> 
> -- A
>