Talks about perfect double-buffering for graphics.

Yesterday i talk with some guys on #aros channel, about how double-buffering must be works on amiga and amiga like oses (i mean double-buffering for graphics rendering, to make "smooth" feeling).

Let's not reffer to double buffering fucntions itslef (i mean how make 2 buffer, and how flip/swap beetwen) just let's concrete on making animation looks 'smooth'.

Before i used all the time functions like WaitTOF(); or WaitBOVP(&(screen)->ViewPort); after i swap the buffer. And everythink was ok when i use it (even on old and new monitors) , but on morphos i can see the differences. I.e. i have not 'smooth' animation, becouse some time it's 'stops a little'. On aos4.1 i have not these 'stops'.

So, i ask about it, and have answer, like: WaitTOF() and WaitBOVP broken by design. Never use it, it will stops your main task, and sometime you will see strange 'jerky' glitches (i think it's like i have these 'stops'). And that these WaitTOF fucntions wait for dunno what today, becouse it's in general old and rare.

Why it's not visibly on aos4 ? dunno. Maybe somethink added to these fucntions to make it works on modern monitors/etc ? Becouse as i know 'normally' these functions works only on very old aoses when everythink was 50hz and so on.

On morphos i have some stops, and i think it's becouse of old realisation of this functions. Somebody point me, that i must just use Wait() fucntion from exec.library, but i dunno how i can change for example WaitBOVP(&(screen)->ViewPort); on the Wait() (which is just different, and signal-related fucntions). How i will know when blitting is done in this case ? (before i not think about, i just use WaitTOF);

Also i think, maybe will be a good idea, to spawn a process and put in it WaitTOF, and when i will call to it from my main double-buffer fucntion it will not have stops and 'smoot' feeling will be ?

Why not use the intuition.library double buffering with AllocScreenBuffer(), ChangeScreenBuffer(), FreeScreenBuffer()? If you follow the Autodoc, you should have a much more compatible way of double buffering than the "old" way. These functions should make sure that the alignment and image format between buffers/bitmaps is compatible for the fastest possible swaps. The only reason to use the "old" double buffering is for compatibility with pre AmigaOS3.

See graphics.library/AllocDBufInfo().

[quote]
AllocScreenBuffer() also allocates a graphics.library DBufInfo
structure. The ScreenBuffer structure this call returns contains
a pointer to that DBufInfo structure, which is free for your use.
See graphics.library/AllocDBufInfo() for full details on using
this structure to achieve notification of when it is safe to
render into an old buffer and when it is right to switch again.
[/quote]

[quote]
dbi_SafeMessage and dbi_DispMessage are standard exec message structures
which may be used for synchronizing your animation with the screen update.
[/quote]

WaitTOF() waits for vertical blanking interrupt and on MorphOS it is always 50 Hz. I dont know how WaitBOVP() is implemented.

@mattey
As i pointed in 1st post, that no problems with double-buffering fucntions itself. I.e. i already use Alloc/Screen/Free fucntions from intution.library. But, this fucntions itself will not give you 'smooth' animation. By this fucntion you just flip buffer beetwen and it will be very fast, without any animation. So, for makin smooth animation always need some function which will be make this effect. In old days, it was WaitTOF() and WaitBOVP. Today, these fucntion not so good at all (looks like) and need to change it on some kind of replacement (as i think).

Usually, double-buffering routines (does not matter what you use for flipping and changing) looks like this:
1. draw to invisibly
2. flip the buffers
3. make smooth animation (to avoid fast flip, or just to avoid black screen (you will not see what happenes at all, fliiping will be madness fast) so it was WaitTOF();

And my question is it: how make the same double-buffer routines, but without WaitTOF fucntions.

So problem as i pointed before, not 'how flip buffers and by which fucntions' , but problem is - how make good smooth animation without 'jerkys' on morphos. And as additional question , why WaitTOF works fine on aos4 (what was added to it ?)

@itix, as i said problem not with double-buffering fucntions, but with WaitTOF itself. Henes said that WaitTOF stop programm when it works and 'it's broken by design'. I do not know why, becouse for me looks logical just implement WaitTOF with modern additional.
If WaitTOF on morphos refer to 50hz, so it looks like on old amiga -> nothink about 'stops' must be, correct ?

How you do this in PowerSDL ? I just dowload PowerSDL sources, and found nothink about any WaitTOF or WaitBOP functions. I see in SDL_cgxvideo.c you have Alloc/Free buffers . But nothink about ChangeScreenBuffer and any Wait(); ..

WaitBOVP() busyloops but WaitTOF() does not unless I remember wrong. Nevertheless both are deprecated. To replace WaitTOF() or WaitBOVP() you must use graphics.library DBuf functionality. This means using graphics.library/ChangeVPBitMap() or its high level counterpart intuition.library/ChangeScreenBuffer().

Generally you can use offscreen bitmap for rendering and use timer to blit bitmap to window at screen refresh rate. With todays fast graphics cards supported by MorphOS it works fine. With AGA it can not work of course.

Itix, i am already use ChangeScreenBuffers functions. And if i just remove WaitTOF from routine, i have nothink like 'smooth'. Just some static jumps, but no animation. Not need to make somethink like some wait based on somethink ?

Your CnahgeScreenBuffer() is incomplete without Wait().

You mean Wait() from exec.library (signal one) ? So, it mean that even with Alloc/Change/Freebuffers fucntions i must use somethink to wait. Before it was WaitTOF, so, now it must be just Wait();

But in generall i can't understand what i must to wait by Wait() (which signal?) and on which info it will be based to make smooth anim ? (i.e. when send signals, which one and by who? :)) )

I fiddled around with this problem quite a lot.
My solution: unfortunately, there is none that works on OS3, OS4 and MOS. :-(

The question kas1e is asking is about the timing, not the swaping of the bitmaps. There are also many ways how to do the swapping, one of them the the ChangeScreenBuffer method (which seems not to be the fastest, btw.).
But how to determine the actual time when you should make the switch so that you are switching at monitor refresh rate AND a point in time were you will not pass the raster-refresh while updating. This is importan, otherwise you wont get "smooth" animation, you will get ugly flickering.
The AutoDocs make you think that ChangeScreenBuffer also takes care about this sepcific moment when it is good to swap. However, it doesnt. Probably because it was sooo rarely used that almost no GFX drivers support this. Maybe OS4 does, but WinUAE.gfx and MOS look like they don't.

In Amiblitz3, I have implemented all ideas that came to my mind how to do a reasonable update. The best so far is either "Draw as fast as you can" or use the timer.device and calculate the Monitor Hz before. Both of them are only semi-smooth, as you see some glichtes here and there, because is is not really synchronized with the monitor refresh.

Let me know if anyone has a good solution for this.
If there is interesst, i can prepare a small demo with scrolling and some bouncing balls for each refresh method, and you can check out how it behaves on which machine.

As I said, under WinUAE non behaves 100% satisfiying.

@Wanderer
Yep! You are right about what i try to talk !

But must to say, on aos3,aos4 and even on aros , WaitTOF did the tricks ! It works smooth etc with all monitors (crt,tft,etc). Why - dunno, but it works. Nothink like 'flickering' on 'jerking stops sometimes'.

WaitTOF also works with Alloc/Change/Screenbuffers fucntions method (for fullscreen), as well as for just BlitBitmap (for window mode). On morphos, it also works fine/smooth in windowed mode! But not in fullscreen (for windowed mode as i said i use blit fucntions , for fullscreen Alloc/Change/Free). And for fullscreen i have these little stops.

It looks like just everythink works perfect and smooth for say .. 2-3 seconds. Then little stop (like somethink stop main taks or somethink over the flow somethink), and then again works smooth.

I will made a video later to show about i talk. Just in end can be possible that problem not becouse WaitTOF, but becouse some intutioin/idmp checks of main window.

But anyway, i am in interest to know deelpy differences of WaitTOF realisations, becouse many ppls said different, but in reality, the same code works fine on all oses exept mos (i just think that morphos can be too fast to do somethink, and becouse of it..)

Well, how i can see in other topic i start to talk with itix about the same thinks and he post some code from his mos's power_sdl, and this piece of code looks very interesting for me:
[csource]
// Wait for frame change
while (!GetMsg(hidden->SafePort))
Wait(1L << hidden->SafePort->mp_SigBit);
[/csource]

So, it looks like commutication by Wait call over the buffers. It's what mean other ppls when talk about "you must use Wait() call".

Will try to play with it. But really, can't think that this 2 strings can be called like "wait from frame change". I.e. it's good solution for WaitTOF(); (if it works of course :) )

Animation on a CRT monitor can NEVER be perfectly smooth unless it synchronized to the raster beam. Period. The End.

Since MOS has broken raster synchronization you will never succeed.

When Henes said "WaitTOF() is broken" he meant 'WaitTOF() is broken in MorphOS. WaitTOF() is obviously working perfectly in OS3 and OS4. It is also broken in certain P96/CGX/Elbox gfx card drivers such as S3 Virge.

WaitBOVP() is broken so never use it.

Solution: Ask Piru to fix the MOS WaitTOF().

Good luck with your endeavors. :)

Brokenness of WaitTOF() is that it does not specify which screen/viewport to wait.

@ChaosLord
What you say it's not solution :) I not refered to fixed somethink in the OS , it's problematic, take many time, unclear when will be next release, and users not have this update, and it will be bad to say user for updates becouse of somethink.

I do not know what you mean about NEVER on CRT. Maybe you jump too deep into details, and "perfect" for you mean somethink technical, but i mean "perfect from user side". And from user side even with WaitBOVP on aos3,aos4 and even on aros animation looks smooth (maybe it's not 60fps, but 40? dunno).

If itix's example works fine (i mean this one with Wait() ), then good for. And i think it must, becouse how you can explain then, these sdl ports of emulators, games and demos, which works fine and smooth ? (with 60fps and without any 'jerkys' on screen).

@itix
can you agree that WaitTOF() broken in Morphos ? I.e. it must to wait for specify screen/etc, but on morphos it's not ? (but it's do on os3/os4/aros?)

@kas1e

WaitTOF() is broken on every platform. For example if you have dual display setup (for example AGA and BVision on old Amigas, or two graphics cards on newer Amigas) it does not know which screen to wait. This is what MorphOS developers refer as broken in WaitTOF() and it is the same everywhere.

Only on old Amiga chipset WaitTOF() can work right.

@Itix
So, in other words brokenless of WaitTOF only becouse of problem with 2 gfx card ? But who in reality use 2gfx cards at time on amigas ? I think 1-2 man from 1000 ?:)

And other think it's that these Waits are busy-loops ? Becouse if WaitTOF must works for 1gfx card on computer, and it's not busy-loops, then it must be works just fine. Correct ?

An Animation is only smooth - or let's say without artefacts - if it matches exactly the Monitor refresh rate or an integer fraction of it.
Plus, second condition, the Buffer must be exchanged at a very certain time in the frame when the raster-ray (or whatever is the equivalent on LDC) is not somewere in the middle of the screen so we don't pass it (or it passes us, depending on the memory speed).

In all other cases, we have situations where we see one frame on the top and the next screen at the bottom, making especially scrolling look ugly, kind of cutted-in-half in the middle of the screen.

ChangeScreenBuffer() uses a Message port to tell you when it is ok to do the next swap. This might be what people told you with "Wait". This enables you to non-busy-wait for the next swap once you are done with your GFX drawings, leaving some CPU cycles for , hmm.. waitever.
However, also ChangeScreenBuffer() does this not reliable. Most systems wait either for 50Hz (which looks completely crap on 60Hz) or dont wait at all (which looks ok if the framerate rises up to 300 or so, but looks crappy at something around your monitor FPS.)

So I dont have a good solution. At least I tried...

Technically, all Classic users have 2 GFX cards, the AGA (or ECS/OCS) Chipset and the GFX Card. The same holds for WinUAE users.

I tried the following swapping methods:
[csource]
#flip_scrollvp = 0 ; use ScrollVP()
#flip_bltbmap = 1 ; blit 2 BitMaps via BltBmapRastPort()
#flip_none = 2 ; no dbl at all
#flip_smart = 3 ; use seletive blit bia BltBmapRastPort and a queue
#flip_changebmap= 4 ; use ChangeVPBitMap()
#flip_scrbuff = 5 ; use ChangeScreenBuffer()
[/csource]

and I used the following sync methods:

[csource]
;/ 1...250 : the desired FPS you want in Hz (timer.device)
;/ #dbl_fps_free = 0 : no timing, pass every frame as fast as possible
;/ #dbl_fps_vbeam = -1 : use VBeam via WaitBOVP_() for timing (usually the monitors FPS)
;/ #dbl_fps_monitor = -2 : calculated Hz from screenModeID (timer.device)
;/ #dbl_fps_vblank = -3 : use VBlank via WaitTOF_() for timing (usually 50Hz or monitors FPS)
[/csource]

The only thing that ever worked was WaitBOVP_() under Amithlon IIRC. The fastest was BltBmapRastport, if you use the "ScreenHack".
This means, you allocate a screen of twice the visible height, and use BltBmapRastport to swap the invisible area (where you paint on) to the visible area. This is much much (much!) faster (on Classic) than allocating a friend bitmap and use a nromal screen, because Picasso96 has a very very stupid swapping behaviour.
This was the only way I was able to achieve ~60FPS in a game using 640x480x16. All other methods break down to ~10FPS or less. (on Classic).
WinUAE machines are fast enough whatever you do, and I guess OS4 and MOS too.

@Itix

Kas1e has only 1 display on his MorphOS machine, so WaitTOF() should work for him.



WaitTOF() does not busy wait on AmigaOS!

WaitTOF() might busy wait on MorphOS or OS4 or AmikitOS or AmigaSysOS, I donno.

WaitTOF() does busy wait when using certain (lame & buggy) "drivers" under P96OS (S3 Virge). That was many years ago when I tested it. Maybe they have finally fixed it now? I doubt it :)

On October 26, 2008 I read that Toni Wilen fixed WinUAE (finally) so that WaitTOF() would not busy wait on the custom WinUAE P96OS "driver".

If you want to say that all Amigas have 2 display screens at the same time, AGA + P96 gfx card, ok. But only 1 screen is in front at any time. The frontmost screen's refresh rate should be used for vertical blank interrupts and WaitTOF() should work perfectly. I know it does not work in real life due to bugs in the P96OS.

I was under the impression that vertical blank related things did in fact work on P96OS Voodoo 3 and ElboxOS Voodoo 3 hackdrivers. This is just the impression I got from vague reports of playtesters who reported "everything works great" with their voodoo 3.

@Wanderer

Just to be clear:
Do you recommend your patented screen of twice the visible height trick(tm)(R)(c) :)

On MorphOS?
On OS4?
On plain OS3.x AGA?
On P96OS 68030 + random gfx card?

As far as I know, my ScreenHack™ doesn't hurt on any system, it gives a little speedup even on WinUAE with 64MB GFX RAM.
For Classic (or any other machine that has a slow datatransfer to GFX card), it is a MUST. Otherwise you spend 90% of the time with data transfer, and the rest is free for your game.
For maximum speed on classic, allocate even tripple or quad size, and put the playfield background and sprite sheet on it too.
Sadly, this is the only way to "force" Picasso96 to keep this Bitmaps in VRAM. Otherwise, Picasso is permanently swapping, even if there was enough VRAM.
Note that a blit done from VRAM => VRAM is 10-100x times faster than a blit from RAM=>VRAM on a classic. Remember, ZorroII makes 2-4MB/sec, while a Cyberision 64 3D can blitsomething like 200MB/sec.

DISCLAIMER:
I recommend the ScreenHack™ only for typical 2D Games. As soon as you start Alphablitting or Full-Screen-Updates (like in a 3D Engine), the benefit of drawing in VRAM turns to be a disadvantage. In that case, a RAM buffer and a WritePixelArray() is recommended.
Also on Chipset, the ScreenHack™ has no big impact since the datatransfer is not the bottleneck, rather the Amiga Blitter itself.
It will even look ugly, because unlike a GFX Card you will see a part of the "invisble" area because the screenmode will start to "overscan".

Conclusion:
Use ScreenHack™ if you are writing a 2D Games for RTG.
Don't use ScreenHack™ if you are writing a 3D Game (or anything that does a Full-Screen-Update) or if you target ChipSet.

For ChipSet, you need direct hardware programming to get decend speed. You can't serve all systems with one doublebuffer method, therefor the technique behind is too different.

@kas1e

[quote]
And other think it's that these Waits are busy-loops ? Becouse if WaitTOF must works for 1gfx card on computer, and it's not busy-loops, then it must be works just fine. Correct ?
[/quote]

It should work relatively fine. WaitTOF() is driver specific (CGX/P96) and in MorphOS WaitTOF() waits for the frontmost screen. So it should be fine if the driver just supports it.

@ChaosLord

[quote]
If you want to say that all Amigas have 2 display screens at the same time, AGA + P96 gfx card, ok. But only 1 screen is in front at any time.
[/quote]

Both can be displayed at the same time.

@Wanderer
Very intersting to read, but i am no so understand, why then for me, WaitBOVP() always make a trick (smooth anim) on all monitors, over Aos3, over aos4 , over Winuae (!) and over aros ? I also have smooth anim with morphos also, but it's just 'jerkys' sometime.

I.e. i mean that WaitBOVP() for all oses works in reality good. I do not know why, but it is. For morphos, i think example which show a itix must be works ? (you said that ChangeScreenBuffer must wait, but it's not , so becouse of it we can you Wait() ). So, it's not a solution for morphos ? (it is, no ?) And for other oses just WaitTOF (let's be no WaitBOVP()) will be ok at all. No ?

Just check this.

Here 4 videos of our diskmag which works over warp3d + using of ChangeScreenBuffer + WaitBOVP() (which all of you said that is broken, and unposible with it make a 'smooth' animation).

On videos:
-A1200 with mediator/Voodoo3 and 060/50.
-A4000 with Grex/Voodoo3 and 060/50.
-A1200 with Bvision and 040/25.
-mA1 with Radeon7000 and G3/750.

See 'scrolling' of articles. Of course becouse of capture devices unpossible to see how smooth is it, but nothink about 'jerkys' or kind of. Even on 040 cpu with 25 mhz (!) it's more or less ok. Why it works then, if fucntion broken (i talk not about WaitTOF right now, but about WaitTOVP() ).

In general, ChangeScreenBuffer + Wait() - can be a solution for us ?

@Wanderer

[quote]
Sadly, this is the only way to "force" Picasso96 to keep this Bitmaps in VRAM. Otherwise, Picasso is permanently swapping, even if there was enough VRAM.
[/quote]

Did you try BMF_DISPLAYABLE flag?

[quote]
It will even look ugly, because unlike a GFX Card you will see a part of the "invisble" area because the screenmode will start to "overscan".
[/quote]

You can define displayable area to be smaller than bitmap attached to a screen. At least it is possible from the graphics.library side, not sure how well it manages with Intuition.

I am a bit stuck with Wait()..

So, i need to make a fucntions, which will be only flip buffers and wait for make it smooth. So, i try to do:

[csource]

struct MsgPort *ports[2];
struct DBufInfo *myDBI;

void SwithDisplay(void)
{

myDBI->dbi_SafeMessage.mn_ReplyPort=ports[0];
myDBI->dbi_DispMessage.mn_ReplyPort=ports[1];

while(! GetMsg(ports[1])) Wait(1l<<(ports[1]->mp_SigBit));
ChangeScreenBuffer(screen,buffer[drawBuffer]);
drawBuffer ^=1;

}

[/csource]

In this example ports will never know about mp_SigBit, i think i need send it somehow ? Or for sending signals i must use somethink different (not ChangeScreenBuffer), which can send these necessary signals ?

@itix
Of course I tried. Doesnt matter. Picasso will swap it, unless you really force it by attaching it to a screen. It looks like Picasso tries to keep all Bitmaps out of VRAM unless they are attached to a screen.

@Kas1e
The reason WaitBOVP() is bad is because it busy-waits. It "works" but it wastes cpu time that should be used for generating the next buffer, or playing music, or running TCP/IP or by SFS or MUI or input.device or AHI etc. etc. etc.

@ChaosLoard
WaitBOVP() busy loops for all the os, or only for current task which use it ? Just in interest how many CPU time this function got if compare with WaitTOF(); ? Maybe it's got so small CPU time, that it's just does not matter ?

Little update:

Right now i try to use the same routines (old ones, with WaitTOF() ), on the window on morphos. And it's works smooth! The same routines works 'jetkys' when i open my own screen. So, i check, and found, that my ambient screens are:
1280x1024 x 58.94hz
1440x1024 x 65.04hz

for boch modes , WaitTOF() works smooth and it explain why i have no 'jerkys' into window mode. But for example for this modes:
1024x768 x x24 - 70.34hz
640x480 x 24 - 75.19hz
640x480 x 16 - 73.07 hz

I have 'jerkys'.

So, just looks like on modes from 50hz to the 65hz, WaitTOF() works good. For modes more that it, WaitTOF(); is broken.

Then i tested the same routines over os4.1 on the same monitor, with really different resolutions, like:

1024x768x32 - 91hz
640x480x32 - 60hz

in all case, WaitTOF() did the trick, and it works smooth. I see how it changes if i use 60hz, or 91hz, (it's start to be more smooth on 91hz). So, looks like it works fine on os4. But at moment, some problems i occur with window mode (looks like that for window mode, WaitTOF on os4, broken as well, or just need some more boring with code to solve that).

All of this, make me think, that usage of WaitTOF() it's bad idea, and it must be replaced at all on Wait();. Dunno will it helps, or not (i hope it will). Can somebody a bit help me with writing of this routine ?

I just do not understand how and by which fucntion i must send signals to make While(wait signal from port) works. And how connect these ports normally to my buffers which i change by ChangeScreenBuffer fucntion.