Print

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

[adrazar]

Hi,
I have a double buffered screen which I scroll using Screen Offset. The problem is that I can't seem to switch buffer AND change offset within a single vertical blank. I've tried rearranging the order of the commands, even introducing amal to do the offset (which actually worked quite well, until I tried to enforce a frame rate reduction). Then I've tried thinking instead of just experimenting, and this is what I figured would be the lay of the land:

* Screen Offset redefines what part of the bitmap is to be considered the upper left corner of the display. Calling Screen Offset in the middle of a screen rendering does not disturb the subsequent part of the current display. There are two possible reasons for this: either amos delays updating the offset-variable until next vertical blank OR the only time this variable is read is once during each vertical blank. I do not know which is true, but I have more faith in the latter.

* Screen Swap changes the bitmap starting pointer to the other buffer. Calling Screen Swap in the middle of a screen rendering will, like Screen Offset, leave the subsequent parts of the display undisturbed. Hence the bitmap starting pointer is treated the same way as the offset variable.

Now, the conclusion I draw from this is that writing
"Screen Offset N,X,Y : Screen Swap : Wait Vbl" or
"Screen Swap : Screen Offset N,X,Y : Wait Vbl"
should work equally well, but it turns out neither does. The most obvious explanation to this disagreement between theory and practice is that my reasoning is flawed or incomplete. I don't know if anyone here knows more about this stuff than I do, but here you go.


[A few words on the problem I'm experiencing: I'm having the player (a bob) move on top of a background scrolling at constant speed. Ideally the bob should appear fixed on the screen while the background rolls underneath, but as default the bob seems to prefer being a shaky blur instead.

I need the player object to be a bob in order to achieve a special colour-mixing effect, thus converting it to a sprite would not be the answer I seek.]

[SamuraiCrow]

Screen offset should come before Screen Swap because it is supposed to affect the logical screen, though both commands really just affect the Copper list.  What settings are you doing at the beginning of the code?  (Particularly regarding Bob redraws and autoback.)

[adrazar]

Bob Update Off, Synchro Off, Autoback 0. I use Synchro to move the bobs and Bob Clear/Bob Draw to redraw them.

[SamuraiCrow]

Hmmm...  That's not the culprit.

[adrazar]

I have created a minimal example showing what I'm talking about (download the attatchment or type it into amos):

Code: [Select]

Bob Update Off
Screen Open 0,640,200,16,Lowres
Screen Display 0,128,50,320,200

Get Bob 1,0,0 To 16,16
Cls 0

Double Buffer : Autoback 0

Repeat
   Bob 0,X+160,100,1
   Bob Clear : Bob Draw
   Wait 50
   Screen Offset 0,X,0
   Screen Swap
   Wait Vbl
   Add X,4,0 To 319
Until Mouse Click

The bob clearly jumps to the right. This indicates that screen swap happens first, then one frame later the offset is changed.

Screen offset should come before Screen Swap because it is supposed to affect the logical screen, though both commands really just affect the Copper list.

I know almost nothing about what a regular Copper list actually does.. What I know is that it is possible to change colours quite often during a single screen rendering by filling it with instructions manipulating "the colour registers". I guess there are other registers, but which are the relevant ones in this context?

[Umpal]

This way works like a charm at 50 fps:

Code: [Select]

Screen Open 0,640,200,16,Lowres
Screen Display 0,128,50,320,200
Flash Off : Curs Off

Pen 1
Box 0,0 To 15,15
Get Bob 1,0,0 To 16,16
Cls 9
Box 0,0 To 319,199

Double Buffer : Autoback 0 : Bob Update Off

Repeat

   Bob 0,160+X#,100,1
   Bob Clear : Bob Draw

   Screen Swap
   Screen Offset 0,X,0
   Wait Vbl

   Inc X : X#=X#+0.5
   If X=319 Then X=0

Until Mouse Click
The most important steps are:

1.   Screen Swap
2.   Screen Offset #,X,Y
3.   Wait Vbl

Enjoy

[adrazar]

Thanks Umpal, delightful to finally see a new reply 

I have only read (not tried) your program, but think you are right it will run smoothly. After all, removing Wait 50 from my own example gives a similar result. What I still haven't figured out is why things starts acting odd from 25 fps and down, and how to fix the oddities.

Currently I'm working on what I've read about the Copper here: http://ada.evergreen.edu/~tc_nik/files/AmigaHardRefManual.pdf. My hope is it can be used to solve this problem, but I have no regrets spending time on it even if it doesn't. 

[Umpal]

Thanks Umpal, delightful to finally see a new reply 

You're welcome mate.

What I still haven't figured out is why things starts acting odd from 25 fps and down, and how to fix the oddities.

Hard to say when I can't see the code (at least the main display part). If you keep the number and size of your Bobs within a reasonable limit there should be no significant drop-down fps.

My hope is it can be used to solve this problem, but I have no regrets spending time on it even if it doesn't. 

Very interesting documentation and surly worth of reading. However AMOS is very specific so unless you test over and over again different methods then you won't achieve any good results. But from my own experience it's possible to surprise yourself and others if one is not giving up and is looking for the best solution.
I don't know how are your skills but if they are above average I recommend you to switch to manual mode completely. I mean no Bob Clear/Draw/Update/Off and stuff. For me it's the best mode and the only way to go with AMOS. In case you wonder what I mean, I explain: I use all the time and without a single exception Screen Copy and Screen Swap. That is all I need (and in my opinion every decent programmer needs no more). It's true that it requires a lot of manual calculating and precision but only this gives me the best and satisfactory result (keeping in mind that AMOS is a high level BASIC oriented programming environment so no miracles here  )

[adrazar]

I don't know how are your skills but if they are above average I recommend you to switch to manual mode completely. I mean no Bob Clear/Draw/Update/Off and stuff. For me it's the best mode and the only way to go with AMOS. In case you wonder what I mean, I explain: I use all the time and without a single exception Screen Copy and Screen Swap.

Wow, that's something to think about! In fact I've been missing a simple way to draw and clear only a subset of the defined Bobs at a given time. I already know what my first attempt in dealing with this will be: find a way to modify the "active bitplanes" of Bobs as I wish regardless of Set Bob being uncooperative. Throwing Bobs out the window altogether is definitely another possibility I might take into consideration.

If you keep the number and size of your Bobs within a reasonable limit there should be no significant drop-down fps.

Given how the game performs so far I've more or less dismissed the possibility that it can run 50 fps on the heaviest sequences. Thus I figured the best solution would be to reduce the framerate such that it becomes constant throughout the game.

[Umpal]

Wow, that's something to think about! In fact I've been missing a simple way to draw and clear only a subset of the defined Bobs at a given time. I already know what my first attempt in dealing with this will be: find a way to modify the "active bitplanes" of Bobs as I wish regardless of Set Bob being uncooperative. Throwing Bobs out the window altogether is definitely another possibility I might take into consideration.

I was having a very difficult time trying to figure out why AMOS behaved so strangely while all was 'according to the book'. Turned out that some automated function, like mentioned above, do NOT work as intended. Well, most of the time and without much expectations they DO (that's why you see from far and conclude: IT'S DEFINITELY AN AMOS PRODUCTION! ). But not when you're a perfectionist. I wasn't pleased with super-duper-frustrating-blinking Bobs effect suddenly coming from nowhere so I decided to switch to 'extreme' mode: the manual one  . Since then all is finally under control. But a word of advice: Always use alongside your code a clear and logic diagram to be aware when, where and how you call Screen Copy (as whole screen as well as regions of course), Screen Swap and Wait Vbl.

Given how the game performs so far I've more or less dismissed the possibility that it can run 50 fps on the heaviest sequences. Thus I figured the best solution would be to reduce the framerate such that it becomes constant throughout the game.

I say keep it steady at 25 and you'll be a winner  (or keep it 20, but constant twenty and the impression will still be very positive).

[adrazar]

Is it possible to examine and modify the next Copper list without turning the Copper off? It seems to me that Cop Logic only holds the previous Copper list, not the next.

[Umpal]

Is it possible to examine and modify the next Copper list without turning the Copper off? It seems to me that Cop Logic only holds the previous Copper list, not the next.

I know very little about copper so I won't help (at least at this stage of my knowledge). For instance, Samurai Crow or Uncle Bruce seem to have a proper one (but I bet there are others as well). Where are you guys? 

[SamuraiCrow]

I think WinUAE has a copper list monitor but I have never used it.

Sent from my Prism II using Tapatalk

[adrazar]

Ok, so it turns out I finally stumbled across the root of the problem: a call to Screen Offset NEVER changes the offset of the immediate next frame! One would have to wait an additional frame before its effect can be seen.

This loop works (25 fps):

Code: [Select]

Do
   T=Timer
   Screen Offset N,X,Y
   'do stuff
   If Timer-T=0 Then Wait Vbl
   Screen Swap : Wait Vbl
Loop


[Umpal]

If Timer-T=0 Then Wait Vbl
(...)
One would have to wait an additional frame before its effect can be seen.

This loop works (25 fps):

Why for the heavens would you want to slow down artificially this routine by half to 25 pfs? 
The example I showed you above works fluently at 50 fps and the change is seen... well, normally, as one would expect. I'm lost