| |
turtle
Account closed
Registered: Mar 2005
Posts: 44 |
how big can a bitmap scroller be ??
trying to make a bitmap scroller.
but it eat to much raster time.
can make it 4 x 5 char bigg.
is there any tricks =) ??
use
!for i,5 {
!for a,8 {
lda $2008+(320*(i-1))+(a-1)
sta $2000+(320*(i-1))+(a-1)
lda $2010+(320*(i-1))+(a-1)
sta $2008+(320*(i-1))+(a-1)
lda $2018+(320*(i-1))+(a-1)
sta $2010+(320*(i-1))+(a-1)
lda $2020+(320*(i-1))+(a-1)
sta $2018+(320*(i-1))+(a-1)
.
.
.
.
.
.
.
.
}}
|
|
| |
Frantic
Registered: Mar 2003
Posts: 1631 |
Did you check:
http://codebase64.org/doku.php?id=base:vic#screen (under the "movement" heading)
? |
| |
Monte Carlos
Registered: Jun 2004
Posts: 351 |
Depends on how fast the scroller should be (how many pixels per frame). With one pixel per frame, you have 8 (8*18600 cycles) frames to scroll the bitmap using double buffering, which is enough to do software scrolling (320*25*8<8*18600).
With small borders you have a 39x24 cursor wide area visible.
There is enough time for loops, so no need to place code for copying every single byte. With two pixels per frame you have 4x18600 cycles to softscroll the bitmap, which is still enough time. For faster movements you need hardware scrolling, which needs 25 rasterlines on top of the screen for vertical movement and 8 lines for horizontal movement. |
| |
turtle
Account closed
Registered: Mar 2005
Posts: 44 |
it is a char set paintet in amica paint
5 char high. ( 5 * 8 = 40 line)
****************************************2000
****************************************
****************************************
****************************************
**************************************** -2640
charet $4000
char + col $0400 + $d800
do some smoot scroll
so have to move memory from $2000 - $2640
move char + col
and then put a new char to the right.
that eat raster time. |
| |
turtle
Account closed
Registered: Mar 2005
Posts: 44 |
|
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Sounds like a job for VSP, see the codebase64 link above... |
| |
Frantic
Registered: Mar 2003
Posts: 1631 |
Regarding double buffering and such, there is some stuff written on that topic in the following articles:
http://codebase64.org/doku.php?id=base:rant4
http://codebase64.org/doku.php?id=base:rant11#free_anydirection..
...which may perhaps serve as inspiration in case you don't go for the VSP kind of solution?
Dunno if you can save some time by doing some sort of triple (or more) buffer system so you'll do:
LDA buff1
STA buff2
STA buff3
i.e., copying to two frame-buffers at once, so you reduce the need to do an LDA for every STA..
rather than
LDA buff1
STA buff2
..and then:
LDA buff2
STA buff1
...in case that might lead to an overall reduction in cycle consumption or so, in case you initialize the routine by copying some frame ahead in order to avoid the initial peak of cycles that would otherwise appear during the first frame. I didn't really think this through though, so there might be some problem with this approach.. In either case, color RAM data of course has to be shuffled in a timely manner. |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Quote: Sounds like a job for VSP, see the codebase64 link above...
Noooo... VSP is the devil, don't use it! Infact, VSP should be banned from all C64 productions.
(That statement may or may not have anything to do with the fact that my C64 is very prone to VSP crashes... :D) |
