Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[adrazar]

I'm lost 

Thanks for letting me know! I think I understand what's unclear concerning both things you mention:

'do stuff
If Timer-T=0 Then Wait Vbl

Why for the heavens would you want to slow down artificially this routine by half to 25 pfs? 

Sometimes the "do stuff" part gets done within one vertical blank. If there were no artificially added wait between this and Screen Swap, the display would in these cases suddenly update at a 50 fps rate. This is undesirable as I want the game to run at a constant frame rate, hence the wait.

The example I showed you above works fluently at 50 fps and the change is seen... well, normally, as one would expect.

Frame:  Command:                   Offset:
1       Screen Offset 0,1,0       (0,0)
2       Screen Offset 0,2,0       (0,0)
3       Screen Offset 0,3,0       (1,0)
4       Screen Offset 0,4,0       (2,0)
5       Screen Offset 0,5,0       (3,0)
6       -                         (4,0)
7       -                         (5,0)
8       -                         (5,0)

This table illustrates the relation between calls to Screen Offset and what's being displayed on the screen for each of eight frames. The offset is lagging a frame behind what one would consider natural behaviour! Running 50 fps (like in the table) makes almost nothing out of this peculiarity, especially when scrolling at constant speed in one direction. But when trying to go 25 fps (like me), the change of buffer and change of offset happens on separate frames if this is not taken into account. A nasty shaking results. And of course it never occured to me that something like THIS could be the reason! That is, until I suddenly had a stroke of luck...

The program that put me on the right track was based on your example (most notably the Box):

Code: [Select]

Screen Open 0,640,200,16,Lowres
Screen Display 0,128,50,320,200
Flash Off : Curs Off : Cls 0
Box 0,0 To 319,199

Double Buffer : Autoback 0
For X=0 to 320
   Plot X,1
   Screen Offset 0,X,0
   Screen Swap : Wait Vbl
Next X
Isn't that point a litte far to the right...

[Umpal]

(...) I want the game to run at a constant frame rate, hence the wait.

That explains everything (in this matter  ). Well, eager to see your final product! Keep up the good work mate.

[Sidewinder]

@adrazar

Were you ever able to get this working?  I'm running into the same problem where screen offset seems to happen too late.  Did you ever find a solution?

[adrazar]

Were you ever able to get this working?  I'm running into the same problem where screen offset seems to happen too late.  Did you ever find a solution?

Well yes.. The solution I presented wasn't 100% consistent after all, still some frames would not have Screen Swap and Screen Offset happen simultaneously. Anyway, it was close enough to perfect for me to settle with it that way, at least for the time being.

But the story didn't really end there, though
A few months later I somehow discovered that the reason Screen Offset scrolls the screen without more ado is because of Auto View.. So I tried disabling it with Auto View Off and call View manually instead, and just like that: all the scrolling problems were gone!

It's bothered me a bit that I haven't shared this info here before, so thanks for asking!

[Sidewinder]

Awesome!  Did you have to call View in the game loop?  Thanks!

[adrazar]

Did you have to call View in the game loop?

That's right, Screen Offset won't scroll the screen unless it's coupled with a View instruction inside the game loop.

It was hard to understand the usage of View because the manual is a bit vague there. So to clarify: it updates the screen according to the changes made by Screen Open, Screen To Front/Back, Screen Hide/Show, Screen Display, Screen Offset (and Rainbow). None of these will do anything with the display until View is called at some later point in the program.

[Sidewinder]

Argh, I just can't seem to get this right.  There is always a noticeable flicker when the view is changed.  Even when I try to get it to change the view in the VBL interval, the flicker persists.  Maybe the view calculations need more time than a VBL?  Here is my loop, constructive criticism is welcome:

Code: [Select]

Auto View Off
Double Buffer
Autoback 0

Do
    ' All my calculations here

    Bob Clear
    Screen Offset 0,X,0
    Bob Draw
    Wait Vbl
    Screen Swap
    View
Loop


[SamuraiCrow]

If View generates the Copper lists, maybe it should be done before the Wait Vbl?  Just a suggestion....

[Sidewinder]

Thanks SamuraiCrow.  I just tried your suggestion.  It didn't work, there is still a skip.  And the bobs appear "fuzzy" also--like I'm seeing both buffers at the same time.

[adrazar]

I notice two things that might cause problems
It seems Bob Update is still On, which means that Bob Update (= Bob Clear, Bob Draw and Screen Swap in one go) is executed every VBL. I always turn it off before using Bob Clear/Bob Draw.
The second thing is that Wait Vbl should normally come after Screen Swap (because the buffers aren't actually swapped before the next VBL). I agree with SamuraiCrow that also View should be done before Wait Vbl (because the Copper list swapping mechanism works similarly, I think).