That does like the ideal algorithm in terms of speed/efficency

tcdev (./14) :
I'm scrolling horizontally in Xevious. I use two lots of linked sprites.

Each frame (when scrolling) worst case is that you just need to reposition 2 sprites, unlink one and link another. Although the logic is a bit tricky it's still only 4 SCB accesses, which is the key here. I keep track of the left-most sprite in a variable to make things a bit quicker. I also have coded two distinct cases; scrolling that does not require the sprites to change (7/8), and scrolling that does (1/8) in my case (I'm using 50% scaled sprites on the background).

Worst case is when resetting the scroll position to an arbitrary value. Instead of trying to optimise the SCB accesses, I simply unlink and re-link/re-position everything. It's only done very infrequently, and not done during active gameplay.

Also I can confirm that any sprite with height > 0 will be placed in the sprite buffer, regardless of position (on MAME at least, but that is what the MVSTECH doc says too). Not ideal, but that's how it works.

That sounds like the good algorithm in terms of speed. Good to hear you are using that. I was thinking of doing something similar but was tempted by the simplicity of just using 32 linked sprites and letting them wrap around. It's a real shame that the off-screen sprites count toward the horizontal sprite limit.

I think I did read in the docs that it calculates which sprites to draw in the line buffer based on the y coordinate and the height only. That's what the tests I did indicated as well. So any missing or blank characters in a sprite also count towards the horizontal sprite limit.