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

[Glen Hewlett]

Hi Richard,

I did look through your source code and I did pick up some good hints from it.  Thanks for the summary below.  One cool thing I came up with during our email discussions of compiled sprites was to also use half stack blasting in the compiled sprite if you can.  This can really speed up the writing time and shrink the length of the code.

The idea is use U as the index pointer and if you have a few rows of the sprite that are identical or many parts that are identical you can load the registers as normal with the LD instruction then point U to the right of the lowest row then you PSHU D,DP,X,Y & PSHU D,DP or whatever registers you can/need then LEAU  -row above,U and PSHU D,DP,X,Y & PSHU D,DP etc.

This is really useful for simple sprites that have a lot of repeating patterns within them.  For the rest of the sprite you would fill in the gaps that stack blasting didn’t get as usual with regular compiled sprites (i.e. LD, ST ,U...)

Compiled sprites sure can get messy pretty quick.  To me this has been a great learning experience.  Thanks again for sharing your code, you have some great ideas for shrinking the code and making it faster.

Cheers,
Glen

> On May 18, 2017, at 1:54 AM, Richard Goedeken <Richard at fascinationsoftware.com> wrote:
> 
> Yeah I spent a lot of time working on this problem a couple of years ago.  The
> code is all there on github.  The sprites are compiled by a python program,
> and it does a ridiculous amount of computation to try and find the most
> optimal 6809 assembly code.  The order in which you load the accumulators and
> write out the pixels can save or lose you some cycles. For example you can
> save some cycles if you finish one row with a value in A or B which will also
> be used on the following row. For the indexed addressing mode, 5-bit offsets
> are the smaller than 8-bit (compiled sprites take a lot of RAM), so you want
> to position your row pointer in the horizontal center of the sprite and be
> able to write to pixels in the [-16,+15] byte range for each row.  If a row
> beneath the current row only has 1 or 2 bytes to be written, it's faster to
> use 16-bit offsets and leave the index register alone than to update it to the
> next row with "leax 256,x". For loading new pixel values into the accumulators
> you can use coma/clra/deca/inca to save cycles/bytes if the new value is zero,
> or the inverse, or plus/minus one, compared to the old value.  There are a lot
> of crazy things you can do; all this stuff is implemented in my python script.
> 
> Richard
> 
> 
> On 05/11/2017 03:49 AM, Dittel, Torsten wrote:
>> ?For those interested in Sprites I recommend to have a look at Richard Goedeken's Game Engine "Dynosprite" here:
>> https://github.com/richard42/dynosprite?
>> 
>> 
>> Regards,
>> 
>> Torsten
>> 
>> 
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco