No, you wouldn't pre-shift the tiles vertically. For vertical movement you'd just draw them higher or lower on the screen. Shifting things vertically from one row to the next is fairly simple, as you're just copying to a different memory address. It's shifting horizontally at less than 8 pixels that's a problem for the Spectrum, as that entails rotating the bits within a byte. So it's much more efficient to prepare that in advance - though it does eat up memory.5MinuteRetro wrote: ↑Fri Dec 08, 2017 9:33 am And not just vertical -- it's diagonal on the ice level. So, eight-direction smooth scrolling. Surely, at least so far as I understand it (which isn't much, tbh), the whole pre-drawn tiles idea can't work here. It can't be possible/practical to draw/store every possible tile combination for eight-way scrolling?
The only faff with vertical scrolling is deciding how to do the cut-off rows at the top and bottom of the screen. If you're using a table of addresses for the lines of the screen, you can draw more lines than you need, and use that table to divert off-screen lines to redundant bits of memory. Or you can draw more than you need on the screen, and hide the cut-off areas behind all-black attributes. Or you can draw in whole rows to a buffer screen in memory, then copy a narrower window from that to the screen to trim the odd lines at the top and bottom. Or you can write a routine that can just draw a reduced number of pixel lines for each row of blocks, to trim down those at the top and bottom of the screen. But sometimes this can add so much extra checking that it's quicker just to draw everything and throw away a few lines of graphics with one of the other methods.