| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
upscroll: fast code needed.
i'm coding a fullscreen smooth up scroller.
Actually i'm using some unrolled code to use minimum amount of cycles, but i want to know if there is a well-know method to achehive best results.
Someone can point me in the right direction? |
|
| |
Didi
Registered: Nov 2011
Posts: 487 |
Secure possibility with NTSC compatibility would be to switch between 2 screenpages each time you need to move the screen up by one line. Then you even do not need to unroll the code because you have plenty time to copy the screen onto the hidden page and then just switch the page when it's needed. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Are we talking bitmap here or just screen ram + color ram?
|
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: Are we talking bitmap here or just screen ram + color ram?
only text and colors. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Then a combination of double buffering (i.e copying an eight of the screen mem each frame) like Didi says and a (partly?) unrolled piece of code moving color mem in one frame is a solution.
Note here that although moving the color mem has to be done in one frame, it only happens every eight frame.
You could perhaps also utilize the fact that usually the color isn't different for all characters on the screen. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
even easier: scroll up each line from top to bottom after it is displayed. Should be more than possible within one frame and without loop unrolling. No need to do that while the raster is off screen. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: even easier: scroll up each line from top to bottom after it is displayed. Should be more than possible within one frame and without loop unrolling. No need to do that while the raster is off screen.
You mean that:
-start screen scroll using %xxxxx111 in $d011 and count down to %xxxxx000;
-starting from raster line $3b, move up line just displayed (reading data from next one) and go on like this, every 8 lines, until last text line
-put %xxxxx111 in $d011 (under bottom border?) and redo from start.
(of course, putting new content in last line as well...)
Is this what you mean? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
@bitbreaker: If you mean a plain copy then it's not entierly obvious. He wants both screen + color.
lda $0428
sta $0400
lda $d828
sta $d800 ; =16 cycles ...which gives 16*1000 cycles for a full screen, unrolled.
One line unrolled (=40 chars) could work. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Only way you're going to get any faster than the techniques mentioned above is by doing something content-aware to take advantage of patterns in the data.
e.g. if your colour ram always has the same colour for adjacent pairs you can halve the number of LDA, or if you are using 2xN tiles where the right hand character IDs are always one higher than the (even) left hand, so you can do an ORA#1 instead of another LDA
Also - do you have "interesting" content the full width of the screen? Or are the first few/last few columns just a tiled background, or perhaps has some useful property like column 0 always having the same value as column 38?
(ps - just noticed that tlr alluded to taking advantage in common colours, so I guess this is not the first comment in this thread on content-aware scrolling after all :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: Only way you're going to get any faster than the techniques mentioned above is by doing something content-aware to take advantage of patterns in the data.
e.g. if your colour ram always has the same colour for adjacent pairs you can halve the number of LDA, or if you are using 2xN tiles where the right hand character IDs are always one higher than the (even) left hand, so you can do an ORA#1 instead of another LDA
Also - do you have "interesting" content the full width of the screen? Or are the first few/last few columns just a tiled background, or perhaps has some useful property like column 0 always having the same value as column 38?
(ps - just noticed that tlr alluded to taking advantage in common colours, so I guess this is not the first comment in this thread on content-aware scrolling after all :)
I need to scrool full screen width, but for the colors isn't really a problem, because at maximum the color change is done every 2 lines and for 2 lines with same color...
So not problem at all for this.
I coded a scroll like Bitbreaker sayd.
Works just fine. Quite ubeliveable...
Now i just test if can put other things (like music for eg.) because using Bitbreaker method, the cycles not taken from raster time, are distribuited all around the screen...
There are some "cycles" under the border, but i don't know if they are enough to do something... |
| |
Didi
Registered: Nov 2011
Posts: 487 |
Play the music in the interrupt and put the move-up routine in normal code triggered by a flag from the interrupt. The rasterline you have to wait for to copy the next line must not be exacly hit and can be higher. Just check on greater not equal. |
| |
yago
Registered: May 2002
Posts: 333 |
There is also a way to upscroll without any CPU usage.
You set up every 8 lines an rasterinterrupt, which changes the vic-bank/characterset/screen.
The details are a bit complicated, but then you only need to scroll the colorram.
I have used it in the Drowned Church Part in FLUT.
|
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: There is also a way to upscroll without any CPU usage.
You set up every 8 lines an rasterinterrupt, which changes the vic-bank/characterset/screen.
The details are a bit complicated, but then you only need to scroll the colorram.
I have used it in the Drowned Church Part in FLUT.
i wil give a look at your work, but we are details-hungry here...
;) |
| |
Repose
Registered: Oct 2010
Posts: 225 |
I was going to say the same thing. I had considered this raster method to scroll quickly an 80 column screen using custom charsets. You can scroll 80 column text at 9600 baud this way. Just sayin'.
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
@flavioweb
no need to trigger an irq each 8 lines, it would most likely also be enough to start copying late enough so that you don't overtake the raster with your copy action (and cause a glitch by that). Just start at let's say $80 first and in case decrease or increase that value, until things look okay. Then you have all the remaining rastertime free in one block.
The other solutions are of course also doable and need way less rastertime, but have a bigger memory footprint. So it is up to you what is needed more :-) |
| |
yago
Registered: May 2002
Posts: 333 |
Yes, iirc, the 8th-line upscroller requires 16k alone for the bitmap. Some memory left here and there for sprites, but using them requires more complicated irqs.
the "raw cpu" method is surely better for games
|
