|
| |
Credits :
SIDs used in this release :
Download :
Look for downloads on external sites:
Pokefinder.org
Production Info
Submitted by Rastah Bar on 14 December 2020
Scrolling a bitmap with softscroll and double buffering is only feasible at a speed of 1 pixel/frame.
This is because you need to copy 10k of data, which takes at least 80k cycles and tons of memory for speedcode.
Limecrunch is the way to go for faster scrolling (see f.e. the VIC-article). Most examples I’ve seen seem to hide the crunched lines with an illegal VIC mode in combination with a black border. But I found a trick to hide the crunched lines in the border in 24 row mode, while giving as much as 8(!) frames to hardcopy the data between the buffers. The last of these frames is always used to copy colorram.
Here’s a brief explanation:
In 24 row mode, if VSCROLL (lowest 3 bits of $d011) is 7, eight lines of the first character row are visible and if VSCROLL=0 only the last rasterline
of the first character row can be seen. This means you can hide a maximum of 7-VSCROLL crunched lines in the upper border.
When they are invisible you don't have to use an illegal VIC mode and you can choose any border color.
To have as much time as possible to copy the bitmap and character ram between buffers, I looked for a sequence of VSCROLL+"number of crunched lines" that postpones the need for a "hardscroll" (copying data) as long as possible, subject to the constraint that VSCROLL+number of crunched lines < 8.
The sequence of (VSCROLL, #crunched lines) I found for 4 pixels/frame is:
1. (7,0)
2. (3,0) So 4 pixels shifted up by VSCROLL compared to the previous frame and no line crunch is used yet;
3. (6,1) One crunched line moves the gfx up by seven lines and this is partly compensated for by adding 3 to VSCROLL for a net upward shift of 4;
4. (2,1)
5. (5,2)
6. (1,2)
7. (4,3)
8. (0,3)
Each step gives a net upward displacement of 4 rasterlines.
After step 8 you go back to step 1 with hardscrolling 4 textlines. I mean, during the 8 frames the sequence takes all data has been copied 4 textlines/32 pixels higher in the other buffer.
The net displacement from going from step 8 to step 1 is also 4 rasterlines:
4*8 rasterlines (from the hardscroll) minus 3*7 rasterlines (going from 3 to 0 crunched lines) minus 7 (delta softscroll) = 4 rasterlines upwards.
In my demo “2600 AD” a sequence for 2 rasterlines ( = pixels/frame) is applied at different positions on the screen:
(1,0), (6,1), (4,1), (2,1), (0,1), (5,2), (3,2), (1,2) and repeat with hardscrolling 2 textlines up.
I also found sequences for 7 and 8 pixels/frame:
(0,0), (0,1), (0,2), ... (0,6) and back to the first step with hardscrolling 7 textlines up.
(7,0), (6,1), (5,2), ..., (0,7) and back with hardscrolling 8 textlines up.
One disadvantage with these two sequences is that the number of crunched lines is changed in every frame and therefore you have to
make the “memory wrap-around corrections” (see VIC-article) in every frame. Also in the last frame, where the color ram is copied as well.
I did not implement the sequences for 7 and 8 pixels, but think of it: Scrolling 192 visible rasterlines of a multicolor bitmap at one whole character row per frame, while allowing any border color! Pretty cool. |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
9.3/10 (13 votes) 