Horizontal Scrolling - Flickering

[LorenzYM]

Hello,
I'm still trying to write my high-rez game and I'd need some help.

At least one part of the game should have a scrolling background.
So i set up 3 screens:
Screen (Xbios 2), scrn1 and scrn2
the player is in a string - lizz$

i managed to create a horizontal scrollscreen with RC_COPY
it scrolls 2 pixels to the left, then i put the player " block" its about 200*200 big.

This way, it's verry slow, but what is even worse - heavy flickering - and the controls ( l -move right, J - move left) don't really work. there is latency...

At the moment, the code looks like that:

Code: Tout sélectionner

INLINE lizz%,32034
INLINE lizzm%,32034
INLINE house%,32034
INLINE house1%,32034
INLINE house2%,32034
!
screen=XBIOS(2)
s1$=SPACE$(32256)
scrn1=(INT(VARPTR(s1$)/256)+1)*256
s2$=SPACE$(32256)
scrn2=(INT(VARPTR(s2$)/256)+1)*256
!
! ----G_MASK_LIZZ---
 ~XBIOS(5,L:scrn1,L:-1,-1)
 BMOVE lizzm%+34,scrn1,32000
  GET 0,0,192,192,lizzm1$
  GET 197,0,528,191,lizzm2$
  GET 0,205,308,399,lizzm3$
  GET 190,400,639,399,lizzm4$
!------G_LIZZ--------
~XBIOS(5,L:scrn2,L:-1,-1)
 BMOVE lizz%+34,scrn2,32000
  GET 0,0,192,192,lizz1$
  GET 197,0,528,191,lizz2$
  GET 0,205,308,399,lizz3$
  GET 190,400,639,399,lizz4$
!
!---------BACKGROUND_HOUSE-----------------
 ~XBIOS(5,L:screen,L:-1,-1)
BMOVE house%+34,screen,32000
BMOVE house%+34,scrn1,32000
BMOVE house1%+34,scrn2,32000
!
!--------SCROLLING----------------

sx%=0
sx1%=640
!
rx%=0
rx1%=0
rx2%=640
!
x%=0
y%=208
DO
   a$=INKEY$ 
   GOSUB  scroll
   sx%=sx%+2
   sx1%=sx1%-2
!
   rx%=rX%+2
   rx1%=rx1%+2
   rx2%=rx2%-2
!
    GOSUB lizz
  exit if sx%=640
Loop
-------CHANGE PICS-TO-SCROLL-------------------
BMOVE house1%+34,scrn1,32000
BMOVE house2%+34,scrn2,32000
sx%=0
sx1%=640
!
rx%=0
rx1%=0
rx2%=640
DO
   a$=INKEY$ 
   GOSUB  scroll
   sx%=sx%+2
   sx1%=sx1%-2
!
   rx%=rX%+2
   rx1%=rx1%+2
   rx2%=rx2%-2
!
    GOSUB lizz
  exit if sx%=640
Loop
!
END
!
!
!-----Proceduren---------
Procedure scroll
   RC_COPY scrn1,sx%,0,sx1%,400 TO XBIOS(2),0,0,3
   RC_COPY scrn2,rx%,0,rx1%,400 TO XBIOS(2),rx2%,0,3
 RETURN
!
Procedure lizz
  IF ASC(a$)=108 THEN    !l- links
    x%=x%+2
    PUT x%,y%,lizzm1$,4
    PUT x%,y%,lizz1$,6
  ENDIF
  IF ASC(a$)=106 THEN   !j - rechts
    x%=x%-2
    PUT x%,y%,lizzm1$,4
    PUT x%,y%,lizz1$,6
   ENDIF
  IF ASC(a$)=97 THEN     !a - lizz2
     PUT x%,y%,lizzm2$,4
     PUT x%,y%,lizz2$,6
    ENDIF
  IF ASC(a$)=98 THEN      !b - lizz3
    PUT x%,y%,lizzm3$,4
    PUT x%,y%,lizz3$,6
     ENDIF
Return


Thats really slow and not suitable for a game...
Ok, ican make it faster when i scroll 16 pixles but the reaction to the keypress is still a problem, beside, flickering.

should i forget about fullscreenscrolling, or is there way to make it react in the right way? without flickering?


I don't know how to use swapping screens in this way. I already have 3 screens for scrolling...
- Next i would add another big block$ to PUT it from the other side of the screen. - and music. of course
then it'll be even slower i guess.

I read about the STE hardwarescrolling, and had a look at the example from paradise, but i didn't really understand it.
Is it hard to convert my code to hardwarescrolling?
Anyway i would be glad if you could give me some advice how i can make it flickerfree and reacting right to the inkey$.
regards,

[sporniket]

to fix the flickering, you generally use vsync before altering your screen. It waits until the screen has been entirely displayed.

But here, I think that you do not know how to use multiple screens.

So, on the use of multiple screen : the goal is to display one (using xbios 5) while drawing on the other. Then when it's done, the one use xbios 5 again to set the current display to the screen that has just been drawed on.

So, now, how to apply this principle :
- backup the system screen adresse (xbios2)
- declare an array of long (%) of 2 elements (say "screen%()")
- allocate 2 memory address suitable for xbios 5, and store the adress in the array
- have an variable storing the index in the array of the screen to display (say "screen_index_display&")
- have another variable storing the index in the array of the screen to draw into (say "screen_index_draw&")
- write a screen building procedure that will draw all the graphics (background + moving parts) at the given memory location. In the game loop, call this procedure with screen%(screen_index_draw&) as the screen location.
- write a "screen swaping" procedure that will use VSync, update screen_index_display& and screen_index_draw&, and finally call xbios(5) to display screen%(screen_index_display&). In the game loop, call this procedure after the call to the build procedure.

[LorenzYM]

well,

i tried the Swap screen1, screen2 / Bmove , screen1, screen2 - thing some time ago but i got to many crashes with it... but i'll try again.

What i wanted to do with the code above is : Horizontal scrolling (left to right) with several pictures.
in the Inline-lines there is

house% - first screen - shown on xbios2 !640*400 pictures
house% - on scrn1 - to scroll it out starting at 0,0
house1% - on scrn2 - to scroll in starting at 640,0

-> two lines of RC_copy for scrolling out scrn1 ( which holds the same as screen(xbios2) (1.starting picture)
in scrn2 (next picture)

then i bmove the next picture to buffers:

house1%- on scrn1 - scroll out
house2% - on scrn 2 - scroll in

... and so on

then i go to procedure scroll again.

so i get constant scrolling of several pics.

next are the moving parts - and thats the problem.

!? Can i have a fourth screen adress - in my case scrn3 ? i didn't try it right now. then i could draw all the scrolling and moving parts to this - then swap it to xbios 2. ?!

maybe i'm thinking to complicated.
theres still the problem with the key-action.
I'm not a coder at all, what do you mean with index..etc.. in my case i solved it with sx% and rx% for rc_copy-coordinates - it works - so far
any sugetions?

[sporniket]

well,
i tried the Swap screen1, screen2 / Bmove , screen1, screen2 - thing some time ago but i got to many crashes with it... but i'll try again.

Crashes might be related to the memory address. On ST, memory address for screen must be a multiple of 256. On STE, it only need to be even.

maybe i'm thinking to complicated.
theres still the problem with the key-action.
I'm not a coder at all, ...
any sugetions?

I know this situation as I experienced it myself when I started coding, and that's why I failed to write a simple Tetris clone at that time: my solution to do it was soooooooooooooo complicated that I threw away the project. All I could do was a simple memory game and a hangman-type game.
Now I could easily do it, but that's because I've studied computer-science and I have been developping for more than 10 years on quite complexe software projects.

So, I that's why I think that what you need to do is to become a coder.
You need to learn how to design a model (data structure) of the problem to solve, and algorithm to process data. If you cannot model properly enough, you will waste a huge amount of time and energy for poor or no results.
Learning algorithms is basic and boring and a little bit time consuming, but it trains your thinking and give you some common sense.
You might take advantage to know some pattern, like Model/View/Controller
And finally you will have to start with a very crude program and elaborate progressively.



So in your problem, what would be my model ?
- The background picture has a variable position along the x axis : let store this in scr_background_x& and scr_background_offset& the move in pixel between each frame.
- There is a moving actor on top of that : let store its coordinates in scr_actor_x& and scr_actor_y&

How do we update this model ?
- The background moves as time passes, and the offset of this move change depending some condition
- The actor moves when user press some keys
So, there will be a procedure "update_background()" that will update scr_background_offset& and then add this value to scr_background_x&
And there will be a procedure "update_actor()" that will scan the keyboard and modify scr_actor_x& and scr_actor_y&.

Now, how do I render the screen ?
- Copy the background picture at its position along x-axis according to scr_background_x&, and clear the area not covered by the picture (you might store a blank screen and copy it on the part not covered)
- Copy the actor at its position according to scr_actor_x& and scr_actor_y&
These two steps can be performed by specifying the memory location of the screen, so there will be a parameter for this, and then we will be able to take advantage of that to use the screen swaping technique.
Let's call this procedure "draw_screen(screen_address%)"

Before putting all of that together, let's go low level with the screen swapping technique (and I will not use array this time) :
As I told before, it needs two screen buffer, say screen1% and screen2%. When the displayed screen is screen1%, one draw into screen2%. When the displayed screen is screen2%, one draw into screen1%.
So you need to know at any time which screen is the one displayed. let's have "is_screen1_displayed!" variable that will be set to true when screen1% is the displayed screen.
The redraw & swap procedure that will manage this system (let's call it "redraw") will perform the following:
- If is_screen1_displayed! is true, call draw_screen(screen2%), vsync, xbios(5;L:screen1%;L:screen2%, -1) and set is_screen1_displayed! to false
- Else call draw_screen(screen1%), vsync, xbios(5;L:screen2%;L:screen1%, -1) and set is_screen1_displayed! to true

Now back to our project, putting all together, the main loop would do this
-while it is not the end of the game
--scan the keyboard for processing an exit key
--update_actor()
--update_background()
--render()
-wend

That's all I can say for now, good luck.

[tomchi]

- If is_screen1_displayed! is true, call draw_screen(screen2%), vsync, xbios(5;L:screen1%;L:screen2%, -1) and set is_screen1_displayed! to false
- Else call draw_screen(screen1%), vsync, xbios(5;L:screen2%;L:screen1%, -1) and set is_screen1_displayed! to true

=

Code: Tout sélectionner

REPEAT
SWAP screen1%,screen2%
~XBIOS(5,L:screen1%,L:screen2%,-1)
VSYNC
' do your stuffs here
UNTIL quit%=TRUE


[tomchi]

Hmmm, I don't really get what you want to do LorenzYM.

Do you want constantly scrolling background and move a sprite over that scrolling ( like a shoot 'em up) or

Do you want to move a sprite and scroll if it goes left or right and not scroll if the player don't want to move ?

My english ain't that good but hope you'll understand my question.

[LorenzYM]

Thanks a lot.
I din't look at gfa for some time.

I'm not sure how the game should work, but I'm thinking of using both tequniques.

1.) Constant scrolling background and then out "sprites" on it. " flying-sequence"

2.) Scrolling if the player-sprites x% > some value

It's gonna be a mixture of adventure and "jump'n Run"

I'll try out some things - and be back. in a while
thanks for helping!

[LorenzYM]

hi,
thanks to tomchi, screen_swapping is now my friend

i have some more questions about scrolling.

in my example sequence i scroll with rc_copy 16 pix to the left, then i put the player to screen. i can live with that speed but if i scroll less than 16 pix it's smoother but to slow.

in the inline there is the scroll pic(high-rez) : in the upper 640*200 fist screen, lower 640*200 second scroll screen. so actually i scroll just half of the (y)screen, (in this case)

However i think i'd would be nice to have a smoother scrolling,
i think it's possible with bmove? but how?

i also like to have 2 pics(640*400) inlined and scroll them horizontally. (what i call fullscreen-scrolling for now)

i found this example code somewhere but i get bombs (peek/poke possibly wrong) why?

Code: Tout sélectionner

For I=0 To 80 Step 2
  Bmove Screen1%,Xbios(2)+I,32000
  Bmove Screen2%,Xbios(2)-32000+I,32000
Next I
Move the entire screen 1 screen to the left:
For I=0 To 80 Step 2
  Bmove Screen2%,Xbios(2)-I,32000
  Bmove Screen1%,Xbios(2)+32000-I,32000
Next I

the second bmove lines are making trouble. i changed the start adress to my inline pics, because this way i don't need to move the pic to a screen adress, thats quite nice.
with this code i get a scrolling effect but not the one i want ( only one pic is scrolled and you can see the whole pic moving all the time..)
any ideas whats wrong with that? it looks allright?

I'm still interested in hardware or fine scrolling but i'm too lazy to learn paradizes code. it takes one pic and copies it to have a 4 times larger screen... well i want to take several inlined pics and scroll horizontally and vertically... hm, it is possible in high rez too, right? i read the overscan article in alive issue 9...
but... c..??? Do i have to create a big picture? but then the inline can't hold it anymore...

anyway, can somebody tell my how to use bmove for smooth/fast scrolling, maybe convert the added rc-copy example to bmove?
i'd really like to finish the mono version of it, then i'll beginn doing a colour version. here is the example sequence (high-rez/ exit with right mouseclick)

lorenzym.rar

[tomchi]

The code you grabbed is a bit weird because of the second BMOVE.
Remember a screen is always 32000 bytes so when you put a pic at adr%+32000 or adr%-32000 it's just like you're putting it under or on top of adr%, that would be fine for a vertical scrolling.
But in the meantime the code shifts first pic 2 bytes resulting in a horizontal scrolling (which is not really that), you'll indeed never see second pic

Here's a small example i did at work right now to show you how horizontal scrolling would be done with BMOVEs.

Right, a screen is 32000 bytes, high rez has 400 lines, so each line is 80 bytes.
I propose you a 8 pix scrolling : a line is 640 pix so shifting one byte in screen address will do that 8 pix movement.

Say your pic is at pic%, BMOVE pic%,XBIOS(2),32000 will copy it.
Now, if we do BMOVE pic%,XBIOS(2)+1,32000
we've shifted the destination 1 byte = 8 pix to the right
But if you do that, you'll see that the pic is shifted but the right end of pic% is at the left of the visible screen.
If you want to do it right, you have to stop copying end of each line ...
That will result in a not so fast routine as you will be able to check by yourself.

Code: Tout sélectionner

RESERVE 5000
CLS
screen1%=MALLOC(32000)         ! buffers for pics
screen2%=MALLOC(32000)         !
screen3%=MALLOC(32000)         !
mainbuffer%=MALLOC(64000)      ! buffer for screen swapping
mainscreen1%=mainbuffer%              ! split in
mainscreen2%=ADD(mainscreen1%,32000)  ! two parts
PCIRCLE 320,200,199                   ! fill the pics buffers ...
PRINT "middle screen"
BMOVE XBIOS(2),screen1%,32000
CLS                                   ! haha
PRBOX 50,50,600,150
PRINT "right screen"
BMOVE XBIOS(2),screen2%,32000
CLS                                   ! hehe
PCIRCLE 50,50,50
PCIRCLE 500,100,50
PRINT "left screen"
BMOVE XBIOS(2),screen3%,32000
CLS                                   ! woosh !
REPEAT                                ! MAIN LOOP
  SWAP mainscreen1%,mainscreen2%
  ~XBIOS(5,L:mainscreen1%,L:mainscreen2%,-1)
  VSYNC
  a$=INKEY$                           ! scroll using keypad
  SELECT a$                           ! 6 scrolls to the right
  CASE "6"
    IF x%<79
      INC x%
    ENDIF
  CASE "4"                            ! 4 scrolls to the left
    IF x%>-79
      DEC x%
    ENDIF
  CASE " "
    quit%=1
  ENDSELECT
  SELECT x%
  CASE -79 TO -1                    ! left
    taille1%=80+x%
    taille2%=-x%
    srce1%=screen1%-x%
    srce2%=screen2%
    dest%=mainscreen1%
    FOR i%=0 TO 399                ! you have to do it line by line ....
      BMOVE srce1%,dest%,taille1%
      BMOVE srce2%,dest%+80+x%,taille2%
      ADD srce1%,80
      ADD srce2%,80
      ADD dest%,80
    NEXT i%
  CASE 0                              ! center
    BMOVE screen1%,mainscreen1%,32000
  DEFAULT                             ! right
    taille1%=80-x%
    srce1%=screen3%+80-x%
    srce2%=screen1%
    dest%=mainscreen1%
    FOR i%=0 TO 399
      BMOVE srce1%,dest%,x%
      BMOVE srce2%,dest%+x%,taille1%
      ADD srce1%,80
      ADD srce2%,80
      ADD dest%,80
    NEXT i%
  ENDSELECT
UNTIL quit%=1
~MFREE(screen1%)
~MFREE(screen2%)
~MFREE(mainscreen%)
EDIT


[LorenzYM]

thanks tomchi,
that's nice. after havin works for a look at your code, i tried something like that with Bitblit.

it's not verry sofisticated code, but maybe it's of some use for noobs like me...

this snippet lets you scroll through some inlined pics.
it works for moving to the right side, to the right there is some problem.

Code: Tout sélectionner

INLINE pic1%,32034
INLINE pic2%,32034
INLINE pic3%,32034
INLINE pic4%,32034
INLINE pic5%,32034
scr0%=XBIOS(2)                   ! physical screen address
scr1$=STRING$(32767,0)           ! reserve some space
scr1%=V:scr1$                    ! background screen address
blitter(-1)
' --------------------------------------------------------
DO
  IF z%<0
    z%=0
  ENDIF
  IF z%=0
    left%=pic1%
    right%=pic2%
  ENDIF
  IF z%=1
    left%=pic2%
    right%=pic3%
  ENDIF
  IF z%=2
    left%=pic3%
    right%=pic4%
  ENDIF
  IF z%=3
    left%=pic4%
    right%=pic5%
  ENDIF
  walk(left%,right%)
LOOP UNTIL MOUSEK=2
PRINT "END"
'
'
EDIT
' ==============================================================
PROCEDURE walk(padr1%,padr2%)
  IF rich%=0
    sx1%=0
    wsx1%=636
    dx1%=0
    sx2%=0
    wsx2%=3
    dx2%=636
  ENDIF
  IF rich%=1
    sx1%=636
    wsx1%=3
    dx1%=0
    sx2%=0
    wsx2%=636
    dx2%=3
  ENDIF
  DO
    a$=INKEY$
    SELECT a$
    CASE "l"
      IF dx2%>4
        SUB wsx1%,8
        ADD sx1%,8
        ADD wsx2%,8
        SUB dx2%,8
        '        GOSUB rc_copy(padr1%+34,sx1%,0,wsx1%,399,XBIOS(2),0,0,3)
        '       GOSUB rc_copy(padr2%+34,sx2%,0,wsx2%,399,XBIOS(2),dx2%,0,3)
      ENDIF
      IF dx2%=4
        INC z%
        rich%=0
      ENDIF
    CASE "j"
      IF dx2%=<636
        ADD wsx1%,8
        SUB sx1%,8
        SUB wsx2%,8
        ADD dx2%,8
      ENDIF
      IF dx2%<636
        '        GOSUB rc_copy(padr1%+34,sx1%,0,wsx1%,399,XBIOS(2),0,0,3)
        '       GOSUB rc_copy(padr2%+34,sx2%,0,wsx2%,399,XBIOS(2),dx2%,0,3)
      ENDIF
      IF dx2%>637
        DEC z%
        rich%=1
      ENDIF
    ENDSELECT
    GOSUB rc_copy(padr1%+34,sx1%,0,wsx1%,399,XBIOS(2),0,0,3)
    GOSUB rc_copy(padr2%+34,sx2%,0,wsx2%,399,XBIOS(2),dx2%,0,3)
    PRINT AT(1,1);z%
  LOOP UNTIL dx2%=<4 OR dx2%=644
RETURN
'
'
'
'
'
' =============================================================================
> PROCEDURE blitter(on!)
  ' *** Turns blitter on or off
  LOCAL status%
  status%=XBIOS(64,-1)
  IF BTST(status%,1)                    ! If a blitter is available
    IF on!
      status%=BSET(status%,0)           ! turn it on
    ELSE
      status%=BCLR(status%,0)           ! turn it off
    ENDIF
    ~XBIOS(64,status%)                  ! do it
  ENDIF
RETURN
'                           TRUE(-1)  /  FALSE(0)
' ===========================================================================
> PROCEDURE definition
  ' For those who wish to experiment with BITBLT, array definitions are:
  '
  ' *** p%(0) thru p%(3) contain source block coordinates:
  ' p%(0) is left x-coordinate of source block
  ' p%(1) is upper y-coordinate of source block
  ' p%(2) is right x-coordinate of source block
  ' p%(3) is lower y-coordinate of source block
  '
  ' *** p%(4) thru p%(7) contain destination block coordinates:
  ' p%(4) is left x-coordinate of destination block
  ' p%(5) is upper y-coordinate of destination block
  ' p%(6) is right x-coordinate of destination block
  ' p%(7) is lower y-coordinate of destination block
  '
  ' p%(8) is the graphics copy mode (3, 6, 7 or 13)
  ' *** 3 = Replace, 6 = XOR, 7 = Transparent, 13 = Inverse Transparent
  '
  ' *** s%() contains SMFDB (Source Memory Form Description Block)
  ' s%(0) is the source screen address
  ' s%(1) is the screen pixel width (must be divisible by 16)
  ' s%(2) is the screen pixel height
  ' s%(3) is the screen width in words (or number of pixels/16)
  ' s%(4) is reserved: always zero
  ' s%(5) is the number of bit planes: 1=high res, 2=med res, 4=low res
  '
  ' *** d%() contains DMFDB (Destination Memory Form Description Block)
  ' d%(0) is the destination screen address
  ' d%(1) is the screen pixel width (must be divisible by 16)
  ' d%(2) is the screen pixel height
  ' d%(3) is the screen width in words (or number of pixels/16)
  ' d%(4) is reserved: always zero
  ' d%(5) is the number of bit planes: 1=high res, 2=med res, 4=low res
  ' ===========================================================================
  '
RETURN
' ==============================================================
'
PROCEDURE rc_copy(s_adr%,sx%,sy%,sw%,sh%,d_adr%,dx%,dy%,mode%)
  DIM s%(5)
  DIM d%(5)
  DIM p%(8)
  s%(0)=s_adr%                    ! quell adresse
  s%(1)=SUCC(WORK_OUT(0))         ! breite in pixel
  s%(2)=SUCC(WORK_OUT(1))         ! hoehe in pixel
  s%(3)=SUCC(WORK_OUT(0)/16)      ! breite in word
  s%(4)=0 ! reserviert
  s%(5)=1                        !SQR(PRED(WORK_OUT(13)))
  d%(0)=d_adr% ! ziel adresse
  d%(1)=SUCC(WORK_OUT(0))           ! breite in pixel
  d%(2)=SUCC(WORK_OUT(1))             ! hoehe in pixel
  d%(3)=SUCC(WORK_OUT(0)/16)           ! breite in word
  d%(4)=0 ! reserviert
  d%(5)=1
  '
  p%(0)=sx%                         ! x1 des quellrasters
  p%(1)=sy%                       ! y1 des quellrasters
  p%(2)=ADD(sx%,sw%)           ! x2 des quellrasters
  p%(3)=ADD(sy%,sh%)             ! y2 des quellrasters
  p%(4)=dx%                      ! x1 des zielrasters
  p%(5)=dy%                      ! y1 des zielrasters
  p%(6)=ADD(dx%,sw%)              ! x2 des zielrasters
  p%(7)=ADD(dy%,sh%)               !  y2 des zielrasters
  p%(8)=mode%                       ! kopiermodus
  BITBLT s%(),d%(),p%() ! nun das eigentliche BLITTEN
  ERASE s%()
  ERASE d%()
  ERASE p%()
RETURN


as you can see, it uses a procedure which can be used same as the RC_COPY command. with the blitter turned on it's faster then RC_COPY.

Nevertheless, I'd like to see some Hardware scrolling in High-Rez on my Sm124.