The test scroller I've got working is nearly ready for 8-way scrolling integration.
Each of the 4 cardinal (L/R/U/D) directions are working (with minor bugs.... a small vertical split bug to squash).
The way I'm thinking of addressing the original issue of THIS thread works like this:
Here's an example of an entire screen buffer (352x288); 4 bitplanes; tiles 16x16; display size: 320x256px.
Visible screen
In terms of the responsibilities of the scroll code (up/down/left/right), each direction will fill one of the four red areas... the left and right scroll will fill the
right and left columns (respectively--the right scroll blits one planeline down) and the up and down will blit to the bottom and top fill rows.
The blocks are blitted in steps. For each pixel in left/right scrolling, a single tile is blitted. When scrolling right, the blocks are blitted left to right. When scrolling left, the direction is reversed.
For up and down it's almost the same, except that there are more columns (20) than steps. No problem. Just blit a double-wide block 4 times. The scheme I'm currently using is blocks 0-5,7,9,11, and 13 are single blocks. The rest are double wides. (I'm actually doing 21 columns with an extra at the end).
Because I decided to give the responsibilities out like that--where only vertical and horizontal blocks belong to the scroll directions that blit them--we have four blocks left out at the corners:
Maybe we call these "adopted blocks," because nobody seems to own them. Maybe if we were going to only scroll 4 directions, those blocks would not come into play.. since you could always scroll once to the left and then once down, for instance, to get the column and row belonging to that block blitted.
Because we have to blit more blocks in the ROWS, my thought is to first try to have the horizontal scroll directions take care of the corner blocks. If scrolling left--for instance... blit B and D. If scrolling right, blit A and C.
If the scroll direction doesn't include a left/right component... and it is pure up or down, then it should be downward scroll blitting A and B and upward scroll blitting C and D.
I haven't implemented this (yet) but this is how I'm thinking.
How does this align with what actually works? Maybe mcgeezer's previous bug (in this thread) dealt with blitting A/B/C/D more than once during the scroll? That's just a guess.
Anyway... this is just some thinking. It may not actually work--it's not tested
