flatduckrecords wrote: ↑Wed Aug 23, 2023 1:15 pm
Can you explain a wee bit about the squeezing, and in particular how you derived the numbers for the
shift_table please?
It was all vague guesswork.
The number indicates how many bytes, counting from the left, get rotated by 1 pixel to the right, before the rest are just copied up from the line below. On the next line, the same value is used, but this time counting in from the right. So it manages to lose a pixel somewhere along each line, but always at a byte boundary. Each value in the shift_table thus corresponds to two lines of the screen and thus two entries from the line address table. Note there are 80 entries in the shift_table, and the scroll works over 160 rows. The number in the table should be 15 or less, such that the point where a pixel is lost never crosses the centre of the screen.
First, you have to keep track of how wide the scroll is at each row, and make sure the number you've chosen extends as far as the remaining pixels. Or else it'll just take a pixel out of the empty space beside the scroller. You judge this because every 16 rows the scroll gets 16 pixels narrower, 8 in from the left and 8 in from the right. You could add an extra factor to the table to skip the blank space on a row first, if you'd like to optimise it a bit.
Then it's guesswork. I start from the bottom up; pick a number somewhere part-way along the row, from 0-15. Then another, and another. I try to distribute them evenly along the row, scattering back and forth, for 8 numbers picked from 1-15. That's the last group of numbers labelled with the ';1' comment.
The next row up, labelled ';2', the scroll is now a byte narrower, so the numbers must be from 2-15, and so-on, up to the top, where the numbers run from 10-15. The last few use '16' so everything shifts inward 1 pixel, to help with aligning the stipple that gets applied on the last few rows.
As I ran it, I found lots of cases where a pixel is removed, then because the lines move inward, the pixel right next to it gets taken out a few lines above, and so a 'doubled-up' pixel completely disappears, rather than all the doubles being gradually whittled away. I haven't figured out a way to predict and avoid this yet. You can try to track it happening - I put a grid of BRIGHT 0/1 white squares over the screen and watch it run to try to track the points these problems occur, then try an tweak the relevant number. But it's a painful process. It'd be easier if you could take out a specific pixel on each row, but I have to do it all at byte edges for speed.
Note also that the scroll up the screen shifts varying numbers of lines counting up from the bottom - not always the full 160. This means that as you go up the scroller, various lines get over-written by the one below and disappear entirely. This squeezes the text vertically. Again, I need to look at tweaking this so that doubled-up rows don't entirely disappear.
I'm trying to refine it for this version, but it's hard work.
)
)
