|
| |
|
Graphics Scrollection [2022] |
Credits :
| Code | .... | Rastah Bar |
| Graphics | .... | Adon |
| | | Almighty God of Atlantis, Excess, Level 64 |
| | | Asthor of EXclusive ON |
| | | Data of De-Koder, Tropyx |
| | | DATA-LAND |
| | | DawnBringer |
| | | Deev of Onslaught |
| | | Dr. TerrorZ |
| | | Duce of Extend |
| | | Eyesee of Anubis, Nuance, Plush |
| | | Fabs of Hokuto Force, Onslaught |
| | | grip of F*A*I*C, Istari |
| | | Jailbird of Booze Design |
| | | Jeremy of Fantastic 4 Cracking Group |
| | | Jok of DreamWeb, Elysium |
| | | Lackey |
| | | Leon of Chorus, Lethargy, Resource, Singular, Storm |
| | | Mermaid of Genesis Project, Vision |
| | | ptoing of Funkentstört |
| | | Rudi of Darklite, RasterDream |
| | | Veto of Oxyron, PriorArt, Tristar & Red Sector Inc. |
| | | Wile Coyote |
| | | Wizofwor |
| Loader | .... | Lft of Kryo |
| Test | .... | Dr. Science of Atlantis |
Download :
Look for downloads on external sites:
Pokefinder.org
Production Info
Submitted by Rastah Bar on 19 April 2023
This demo streams hires bitmaps from floppy and scrolls them upwards at a speed of 2 pixels per frame. No VIC ‘illegal’ display mode is required and hence 192 rasterlines can be displayed using any border color you like.
At 2 pixels/frame there’s 2 seconds available for loading and scrolling an entire screen. When you look at benchmarks (f.e. here https://www.linusakesson.net/software/spindle/v3.php, https://csdb.dk/forums/?roomid=12&topicid=148180&showallposts=1, https://csdb.dk/forums/?roomid=7&topicid=142376&showallposts=1) you can see that when 50% CPU time is available for loading, the state-of-the-art loaders, on the average, can load and depack about one hires bitmap (including screen ram color info) during that time. This means that the actual scrolling (which involves copying large amounts of data between screen buffers) must be done with only about 50% of CPU time available.
In the production notes to the demo “Dragon’s Lunch” (https://csdb.dk/release/?id=185095&show=notes#notes) a trick is explained that combines linecrunching with VSCROLL such that crunched lines are hidden under the upper border in 24 row mode. With the right sequence of VSCROLL+Linecrunch values, at a scrolling speed of 2 rasterlines per frame, only once every 8 frames data has to be copied from one display buffer to the other. Unfortuenately, this isn’t fast enough to stream bitmaps from floppy: with 50% CPU time available, this copying of data has to be done in the equivalent of 4 frames. But copying bitmap and screenram data, and displaying new gfx data, takes at least 9000*9 = 81000 cycles, which corresponds to more than 4 frames. So an improvement is needed.
Note that one can implement those sequences in two ways: one can start crunching lines on the first normal badline, for example, if VSCROLL is set to 5 the first linecrunch is done on rasterline $35. Alternatively one can set VSCROLL to 0 initially, start crunching on line $30, and then perform FLD. However, to stream bitmaps from floppy the first method must be used, as will explained next.
Consider this 12-step sequence of (VSCROLL, #crunched lines)
1. (6,0), 2. (4,0), 3. (2,0), 4. (0,0), 5. (5,1), 6. (3,1), 7. (1,1), 8. (6,2), 9. (4,2), 10. (2,2), 11. (0,2), 12. (5,3),
where you would switch to the other display buffer after step 12 and start at step 1 again, having copied data from the current buffer 3 character lines higher into the other buffer during these steps (and having refreshed the graphics at the bottom of the screen).
In steps 8 and 12 there is one visible crunched line on rasterline $37. I realized that this does not have to be problem, since the visible rasterline is the last one of the crunched character line, and that is actually the one you want to display anyway. This is for bitmap graphics, not for color data.
(As I mentioned, setting VSCROLL to 0 initially, starting crunching on line $30 followed by FLD does not work here, since the VIC chip will then be in idle state in the first visible rasterline in steps 8 and 12.)
So, setting VSCROLL right away and starting the crunching on the first badline shows correct bitmap graphics on line $37 in steps 8 and 12, but wrong color data. The VIC uses the color data read on the last badline of the previous frame. Fortunately this can be fixed!
In steps 7 and 11, the last badline is on line $f2. The last possible badline is on line $f7, and this line is just hidden by the lower border in 24 row mode. So if you switch to a different screen ram area after line $f2, create an extra badline on line $f7, and make sure that the screen ram area switched to has the right color info to be used for the visible crunched line at the top of the screen in the next frame, both the pixel data and its colors turn out right. After line $f7, you can switch back to the normal screen ram location. In case of multicolor bitmaps, the colorram also has to be taken care of. See the production notes to “Graphics Scrollection 2” for details on that.
So with this 12-step sequence streaming bitmaps from floppy becomes feasible at 2 pixels per frame!
In the demo the loading buffers are large enough to contain two full pictures. Half a picture at a time is loaded. At the start of the demo, the data to put on screen is read from the buffers one half screen ahead of the loading position. This will give the loader/decruncher maximum time to do its job (assuming loading is the bottleneck, but there are checks in the code to pause loading or scrolling if necessary).
One more thing. Suppose a more gentle scrolling pace is desired, say 1 pixel per frame. Now it takes 4 seconds for moving up an entire screen. Consider this sequence for moving at 1 pixel per frame:
1. (7,0), 2. (6,0), …, 8. (0,0), 9. (6,1), …, 15. ( 0,1), 16. (6,2)
and back to step 1 while switching to the other display buffer after hardscrolling 2 textlines upwards.
The same extra-badline trick works here too (needed only for the last step), and there is as much as 16 frames available for copying data to the other display buffer! So there will be plenty of time to load new graphics and a large amount of rastertime will still be available for adding music and all kinds of effects!
A 10-step sequence for 4 pixels per frame is:
1. (4,0), 2. (0,0), 3. (3,1), 4. (6,2), 5. (2,2), 6. (5,3), 7. (1,3), 8. (4,4), 9.(0,4), 10. (3,5),
with hardscrolling 5 text lines. |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs (1)
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
