Closed konimaru closed 3 years ago
I do have a solution for this which just needs one final test this evening on real h/w.
Out of curiosity, in MoveBlock the location of the wait-for-move-to-finish depends on the previous direction. Why is that? The vs23 documentation seems hopelessly out of touch with reality.
The reason is that you can set up the start address for a block move while the previous move is still in progress, but only if the latter is a forward move. For a reverse move, the start address is used as the end address, so it cannot be modified until the move has completed.
Turns out that source and destination address for the block move have to be at least 4 bytes apart (at least in the configuration I am using, i.e. skip == 0). Modes 3 and 4 happened to trigger a delta of 2 which made it all fall apart ...
For the record: #61
From the looks of it, SDL's MoveBlock function doesn't work vs23s010 style. The latter honors live updates while moving stuff around. SDL simply takes a snapshot of what is there and copies it somewhere else. I'd argue all platforms should have the same behaviour, in this case following h/w. Your call.
from left to right: original, 1st ^L, 2nd ^L
Fixed in 55bbcf2cc.
Said function utilises half an empty line to efficiently generate empty lines during scrolling. This can be handled differently without much penalty (and getting the VRAM back).