[Coco] Let's figure out the best method to compile sprites for the CoCo - Please add your input

Glen Hewlett glen.hewlett at sympatico.ca
Thu May 11 00:45:19 EDT 2017


Hi All,

Over the last month or so I’ve been thinking of different ways to compile sprites for the CoCo.  Lately I’ve heard there are a few other people working on this same problem.  Maybe we could have a discussion here on this topic and get anyone who has an idea to help make it as fast as possible.  Then we can have one optimized sprite compiler for everyone to use, or at least to take ideas from and use themselves.

I’ll explain the way my current program compiles sprites and I hope others can add other ideas to it.  Or explain a better method.

My current approach is specific for my Pacman transcode which uses a 16 colour 256 pixel wide screen.  This will be a little different if you are using a more standard CoCo 3 - 320 Pixel wide screen.
The sprites are 16x16 pixels, here is an example to work from:
44 44 44 44 44 44 44 44 - 1
44 44 49 99 99 44 44 44 - 2
44 49 99 99 99 99 44 44 - 3
44 99 99 99 99 99 94 44 - 4
44 99 99 99 99 99 94 44 - 5
49 99 99 99 99 94 44 44 - 6
49 99 99 99 44 44 44 44 - 7
49 99 94 44 44 44 44 44 - 8
49 99 99 99 44 44 44 44 - 9
49 99 99 99 99 94 44 44 - 10
44 99 99 99 99 99 94 44 - 11
44 99 99 99 99 99 94 44 - 12
44 49 99 99 99 99 44 44 - 13
44 44 49 99 99 44 44 44 - 14
44 44 44 44 44 44 44 44 - 15
44 44 44 44 44 44 44 44 - 16

In this example the $9 are yellow and the $4 is black just like the background.  I first had the compiled sprites only write the yellow part to the screen but it turns out that it wrecks the animation as Pac Man opens his mouth while moving, so I need to actually display the $4 as black on screen.

Currently my code writes starts with the instruction LEAX   8,X to setup the index pointer to the top right of the sprite location.
-Next it looks at the first two rows of the sprite together and determines which two byte pattern is used the most and loads that into the D register.  In the example above this would be LDD  #$4444
-Next it would do a bunch of STD  position,X commands to place the contents of D on the screen this would be:
        LEAX    8,X
        LDD     #$4444
        STD     -8,X
        STD     -6,X
	STD	-4,X
        STD     -2,X
	STD	120,X
	STD	125,X
-Next Check to see if A or B can be used as individual values so we do a STA
	STA	127,X
-Next check for the next most used word in the space that is left and load that into D, but also check if A or B already has the correct value and if so do a load only for the A or B accumulator that needs to be changed.
	LDD	#$9999
	STD	123,X
-Check if we have more words to write to the sprite if so do the same as previous step, otherwise fill in the rest of the sprite using byte values.
	LDA	#$49
	STA	122,X
-Once all the pixels are accounted for, move the pointer down to the next two lines and continue doing the next two rows etc. for the rest of the sprite.
        LEAX    256,X

So the code for the first two lines is with [byte counts] and [cycle counts]
[2]     LEAX    8,X     [5]
[3]     LDD     #$4444  [3]
[2]     STD     -8,X    [6]
[2]     STD     -6,X    [6]
[2]	STD	-4,X    [6]
[2]     STD     -2,X    [6]
[3]	STD	120,X   [6]
[3]	STD	125,X   [6]
[3]	STA	127,X   [5]
[3]	LDD	#$9999  [3]
[3]	STD	123,X   [6]
[2]	LDA	#$49	[2]
[3]	STA	122,X	[5]
[4]     LEAX    256,X   [8]

For the first two rows of this sprite it uses 37 bytes and 73 CPU cycles.

The program will process the next two rows similarly to the above process but first take into account the values already loaded into the A and B registers. Then do a STD , STA and STB if it can with the current values.  Then do the same as the above steps until we get to the end of the sprite.

If anyone can think of a better way to compile sprites please share it with us.

Cheers,
Glen



More information about the Coco mailing list