garfield wrote:
Good job! There's nothing quite like pictures (still and moving) to really put an idea across.
How much slower would a backstore bg erase be, do you think?
The core loop of the erase routine at the moment is basically this (presuming the accumalator is pre-filled with 0)
loop:
STA ScreenAddress,X
DEX
BPL loop
which (when the branch occurs, which is most of the time) would take 9 cycles per byte to erase (presuming no page boundarys crossed for the address + the index).
To do background erasing would basically mean changing it to this
loop:
LDA BackGroundGraphic,X
STA ScreenAddress,X
DEX
BPL loop
An increase from 9 cycles to 13 cycles (4 cycles more). I'll leave you to do the maths for the percentage increase. Obviously there are additional overheads in setting up the address of the background graphic but the main area to look for any speed differences is in the inner most loop of the erase routine.
The erase routine is optimised to erase full char rows for the width of the sprite. Any part char rows (i.e. that sometimes can occur at top or bottom of sprite) are dealt with separately but in a similar manner.
For background erasing your scenery graphics would need to be stored in row format rather than the typical column format used for sprites (See Swift sprite document for explanation of these formats if you are unsure about them). This gives a speed increase in plotting these graphics initially as well as when it comes to erasing them but of course they need to be vertically aligned to char rows and be whole char rows in height. But this is a common technique for most games regardless of whether the background has sprites floating over them or not.