Talks about perfect double-buffering for graphics.

Itix, i copmpletelly do not understand at moment nothink :)) You mean which Wait i loose ? I have 2 wait in the fucntion (for safe and for disp).

I looked up my old notes from the 1990's about double-buffering.
Context: I was writing 100% AmigaOS friendly multitasking games on my
ECS A3000 25Mhz 030.

Here are the old notes I found:

[quote]
The only way I know to stop the flicker of the pentagrams is to either:
A: Figure out a way to do double-buffering that really works.
B: Move the pentagrams to the bottom of the screen. (this is just a work
around)
C: Make the game require OS 3.0 and use those double-buffering routines.


* INVESTIGATED the following examples of double buffering from Aminet.
These are all that I could find:

dbuffer.lha dev/e 3K 95+Easy double buffering of screens
DBuff.lzh dev/src 12K 321+double buffering demo w/source
doublbuf.lha dev/src 7K 171+Eg. of fast OS-friendly double buffering
NBuff.lha dev/src 19K 277+Double bufferung routines example. V2.2

All these examples SUCK because:
1. They don't allocate their bitmaps properly. They use that icky
scatterload approach.
2. They use the slow RethinkDisplay(); technique.
3. The ones that don't use RethinkDisplay(); require OS 3.0+. And since I
am making the game compatible with all OS's it is useless to me.

* DOUBLE-BUFFERING of rastports/bitmaps implemented for pentagrams
(finally!). Now they are rock solid, _except_ for during high CPU load
times (like while downloading from the internet on standard serial port)
During high cpu load they flicker a bit sometimes on my A3000 25Mhz 030.
I haven't tested it on A500 yet.

...

* PROBLEM: The "about" screen with the pentagrams hashes sometimes. It
hashes a lot and looks utterly terrible under heavy CPU load. NOW FIXED
by increasing the taskpri to 100 during the doublebuffer switching.

* PROBLEM: The credits scrolling is not 100% smooth and is very jerky
under heavy CPU load. NOW FIXED by increasing taskpri to 100 during
the doublebuffer switching.

...

* 5: 64-bit aligned the double-buffering of the rotating pentagrams. DONE.

[/quote]

[quote]
BOOL wait_me = FALSE;

void SwitchDisplayText(W3D_Context *context,struct Screen *screen)
{
ports[0]=buffer[drawBuffer]->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort ;
ports[1]=buffer[drawBuffer]->sb_DBufInfo->dbi_DispMessage.mn_ReplyPort ;

if (wait_me)
{
while(! GetMsg(ports[1])) Wait(1l<<(ports[1]->mp_SigBit));
}

while(!ChangeScreenBuffer(screen,buffer[drawBuffer]));

wait_me = TRUE;

while(! GetMsg(ports[0])) Wait(1l<<(ports[0]->mp_SigBit));
drawBuffer ^=1;
W3D_SetDrawRegion(context, buffer[drawBuffer]->sb_BitMap,0, &SwiDisp);
}
[/quote]

Itix, thanks for help already, but i just put latest example to code, then when must be happenes Swith, then task freeze, and by 'escape' i have "task midatiion, abort?"

ps. maybe you will in interest and have some time just to check little source which i do for you (just fade effect, which in loop do SwithDisplay of picture over warp3d).

I just have default SwithDisplay function (to show you how it works), and your ones, which is 'meditation task". Also if you will in interest to compile it, i put warp3d includes for vbcc to. Binary into example archive with WaitTOF() swithdisplay (to show what i want to do without WaitTOF(); )

little example
w3d vbcc includes for morphos

example are very simply done (notthink about huge whiles, or kind of) and easy to understand.

example.c - main one: just open w3d library, got w3d request for modes, create a screen/window , create w3d context, set some states and draw image (draw + SwitchDisplay in loop).

vague_logo.h - warp3d based stuff (loading file to ram, assign to buffers, draw function).

other_funcs.h - 2 fucntions: swithdisplay and check on mouse for exit.

values.h - necessary values

Dunno what can be wrong with it to make app 'meditation'.

Yesterday henes give me a point that only change SwithDisplay will not enough. For first need allocated ports, etc. Before i think that
[csource]
struct MsgPort *ports[2];
buffer[drawBuffer]->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort =ports[0] ;
buffer[drawBuffer]->sb_DBufInfo->dbi_DispMessage.mn_ReplyPort =ports[1]; ;
[/csource]
are enough, but looks like i need add CreateMsgPort before ?

I just put these strings into main part of code:

[csource]
for (i=0;i<2;i++) {
ports[i] = CreateMsgPort();
if (!ports[i]) {
fprintf(stderr,"Failed to allocate message port\n");
return 0;
}
}
[/csource]

The same freeze. Maybe i need filled somethink more for ports ? (freeze mean "task freeze", not whole system).

ps2. Itix, i am put printfs in your code after every string, and found, that 'freeze' happenes when code going into if (wait_me) {}.. So, for first wait_me in False, then everythink ok, works. Then for second time wait_me True already, and this (wait_me) loop never recieved signal.

And more than that, i just make SwithDisplay() like this (for tests):
[csource]
void SwitchDisplayText(W3D_Context *context,struct Screen *screen)
{
drawBuffer = 0;
buffer[drawBuffer]->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort =ports[0] ;
buffer[drawBuffer]->sb_DBufInfo->dbi_DispMessage.mn_ReplyPort =ports[1] ;

printf("wait1 begin\n");

ChangeScreenBuffer(screen,buffer[drawBuffer]);

//check, it's safe for write ?
While(!GetMsg(ports[0])) {
Wait(1l << (ports[0]->mp_SigBit));
}

printf("wait1 finished\n");
}
[/csource]

And i just not have words "Wait1 finished". It's just stop on the wait even without any loops,etc. I am also change drawBuffer value from 0 to 1 (just to be sure), and have the same halt on Wait.

All of this make me think, that for some reassons DispMessage for port[1] never happenes. I just try to put ChangeScreenBuffer as first fucntion (just for tests again) and even with it i never recieve signal for port[1].

I just tryed many combnations, just to sure that somehow wait for port[1] is happened, but is not at moment .. Maybe i must setup somethink for screen when i open it, to make all of this works ?

Here are some code fragments (Amiblitz3):

This is the engine Struct:

[csource]
NEWTYPE.dbl
*bmap_0.BitMap ; bitmap 0
*bmap_1.BitMap ; bitmap 1

*scrbuff_0.ScreenBuffer
*scrbuff_1.ScreenBuffer

*mp_safe.MsgPort
*mp_disp.MsgPort

safeToChange.l ; remember our state
safeToWrite.l

*scr_db.DBufInfo

db.l ; which is the current buffer, 0 or 1

*scr.Screen ; the screen we are operating on

End NEWTYPE
[/csource]


This is the free method:

[csource]
Statement dbl_Free {}

If \safeToChange=False AND \mp_disp><0
While (GetMsg_(\mp_disp)=0)
Wait_(1 LSL \mp_disp\mp_SigBit)
Wend
End If

If \safeToWrite=False AND \mp_safe><0
While (GetMsg_(\mp_safe)=0)
Wait_(1 LSL \mp_safe\mp_SigBit)
Wend
End If

\safeToWrite = True
\safeToChange = True

If \scrbuff_0 Then FreeScreenBuffer_ \scr,\scrbuff_0: \bmap_0 = 0 :\scrbuff_0=0
If \scrbuff_1 Then FreeScreenBuffer_ \scr,\scrbuff_1: \bmap_1 = 0 :\scrbuff_1=0 ; bitmap 1 goes with the buffer !

If Peek.l(Addr Screen(0)) Then CloseScreen 0 : \bmap_0 = 0 ; bitmap 0 goes with the screen!

If \mp_safe Then DeleteMsgPort_ \mp_safe : \mp_safe = 0
If \mp_disp Then DeleteMsgPort_ \mp_disp : \mp_disp = 0

End Statement
[/csource]


This is the init part of screenbuffer:
[csource]
\scr = ... open the screen

\scrbuff_0 = AllocScreenBuffer_(\scr,0,#SB_SCREEN_BITMAP)
\scrbuff_1 = AllocScreenBuffer_(\scr,0,#SB_COPY_BITMAP)
If (\scrbuff_0 ><NULL AND \scrbuff_1><NULL)
\bmap_0 = \scrbuff_0\sb_BitMap
\bmap_1 = \scrbuff_1\sb_BitMap
If \scrbuff_0\sb_DBufInfo><0 AND \scrbuff_1\sb_DBufInfo><0
\scrbuff_0\sb_DBufInfo\dbi_UserData1 = 0
\scrbuff_1\sb_DBufInfo\dbi_UserData1 = 1
\scr_db=\scrbuff_0\sb_DBufInfo
\mp_safe = CreateMsgPort_()
\mp_disp = CreateMsgPort_()
\scrbuff_0\sb_DBufInfo\dbi_SafeMessage\mn_ReplyPort = \mp_safe
\scrbuff_0\sb_DBufInfo\dbi_DispMessage\mn_ReplyPort = \mp_disp
\scrbuff_1\sb_DBufInfo\dbi_SafeMessage\mn_ReplyPort = \mp_safe
\scrbuff_1\sb_DBufInfo\dbi_DispMessage\mn_ReplyPort = \mp_disp
End If
End If
[/csource]

This is the relevant part of the switch function

[csource]

If \safeToChange=False
While (GetMsg_(\mp_disp)=0)
Wait_(1 LSL \mp_disp\mp_SigBit)
Wend
End If

\safeToChange = True
;WaitBlit_ ; dunno if that helps

If \db
succ.l = ChangeScreenBuffer_ (\scr,\scrbuff_1)
Else
succ.l = ChangeScreenBuffer_ (\scr,\scrbuff_0)
End If

If succ
\db=1-\db
\safeToChange=False
\safeToWrite=False

If \safeToWrite=False
While (GetMsg_(\mp_safe)=0)
Wait_(1 LSL \mp_safe\mp_SigBit)
Wend
End If
\safeToWrite = True

[/csource]

@Wandarer

It's necessary to use dbi_UserData1 and dbi_UserData2 fields ? Autodocs say somethink like:
[quote]
The dbi_UserData1 and dbi_UserData2 fields, which are stored after each
message, are for your application to stuff any data into that it may need
to examine when looking at the reply coming into the ReplyPort for either
of the embedded Message structures.
[/quote]

What i totally do not understand for what i need (or not) to use it in real live.

At moment i completely stuck with all this Wait/Port boredom .. I just do:

[csource]

struct ScreenBuffer* buffer[2];
int drawBuffer;
struct MsgPort *ports[2];

// open screen
// open window


//alloc screen buffers
buffer[0] = AllocScreenBuffer(screen,NULL, SB_SCREEN_BITMAP);
buffer[1] = AllocScreenBuffer(screen,NULL, SB_COPY_BITMAP);//0);

// bitmap
bm = screen->RastPort.BitMap;


//create 2 msg ports

for (i=0;i<2;i++) {
ports[i] = CreateMsgPort();
if (!ports[i]) {
fprintf(stderr,"Failed to allocate message port\n");
return 0;
}
}


// draw image to bitmap.
draw_pict_logo(context,1.0f);

//assgin DBuinfo messages staff to ports
printf("before dbi=ports[]\n");
buffer[drawBuffer]->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort=ports[0] ;
buffer[drawBuffer]->sb_DBufInfo->dbi_DispMessage.mn_ReplyPort=ports[1] ;
printf("after dbi=portsp[]\n");

//Flip the fucking buffers!
printf("before CBS()\n");
while(!ChangeScreenBuffer(screen,buffer[drawBuffer]));
printf("after CBS()\n");


// Wait for SAFE signal.
printf("before wait on ports[0]\n");
while(! GetMsg(ports[0])) {
Wait(1l<<(ports[0]->mp_SigBit));
};
printf("after wait on porsts[0]\n");
[/csource]

And just have deadlock on Wait. But when i do ChangeScreenBuffer, i must recieve some singnal from which said "you are save to write again to bitmap", not ?

You need ALL of the above i have written, except the user data thing, that's why it is called user data. This field is for your own purposes. You can ignore it, set it to 12345 or whatever you like.
I set it to 0 and 1, to be able to read out later which buffer is ment. However, this is not necessary. There are other ways to keep track of which buffer is the next one.

The scr_db field for the DBInfo is not needed, too. But all the rest is.

@Wanderer
well, all about you have written related to DBuinfo it's only ports. (safe/disp). I have it already in my code too.

Looks like i am totaly not understand way of working with Signals.
For me, it looks like: i do ChangeScreenBuffer, then i can Wait for signal becouse i already do ChangeSCreenBuffer. But i am never recieve this signal.

Henes said me that it becouse "the buffer 0 is still displayed so you will never receive its safemessage. you must not wait for safemessage of the buffer you just sent to display using changescreenbuffer"

And i am totally messed all in head already. I not must wait ? For what then i need these Waits ? Can somebody please explain all of this more deeply and make a some strings of code, which only 1 time wait for first Safe message with using ChangeScreenBuffer?

I fixed your broken code: example_w3d.lha.

You were not allocating message ports (eh) and you were not freeing screen buffers (another eh).

Itix, here is couply of interesting mistakes !

For first, you are right about broken code (it's not create ports before, etc). But it was yesarday, so, today from begining of day i put all this necessary stuff and start boring. All tests today i do on WINUAE, have dedalock and deadlock when it must be not !

After i am boring becouse i do all correct, i just swith to morphos just to be sure, and holy crap - on morphos it just works !! I tryed it as 68k binary, and as mos native. Works ok with all cases. I also tryed the same for os4 - works too !

So, then i just swith back to aos3/winuae/warp3d(quarktex) and just try the same 68k binary -> lockup about i talk here many times.

So, as result , winuae with quarktex handle in wrong way signals from w3d buffers (or it becouse of bad writed quarktex, maybe for os3 need somethink different, maybe i have some strange seetings for winuae).

Thanks for help and for example, i will test all of this more deeply today/tommorow.


ps. Itix, just recompile your example as 68k binary, and try on winaue = deadlock :) On morphos/aos4 - works

If it crashes in WinUAE then it must be P96 driver bug. I dont have WinUAE here so I can not check it out but I am sure it would work with AGA on WinUAE.

But it is possible there is just some bugs left. Not all error conditions are taken into account (i.e. if ChangeScreenBuffer() fails).

It works on WinUAE. So the bug must be in your code.

But I repeat my self: This will still not give you smooth animation :-(

>All tests today i do on WINUAE, have dedalock and deadlock >when it must be not !

i think i know whats wrong, opengl on winuae is done in windows code.windows side have no access to amiga screenchange functions and dont need them,because the wait for vsync and buffering is done in windows code and depend on the setting in your windows 3d driver setting.here you can set vsync always on, vsync application select and vsync off.YOu can also set to triple buffer.
best is when you set always on, if you like smooth graphic.

in winuae prefs page ram you can set
what you want.Chipset sync to amiga chipset, real sync to refresh rate, or choose some values (60, 70)

if you get problems with unsmooth you can try real sync or use a fixed value 60 70 hz.

i dont know what 3d card yoiur windows system have.

@Wanderer
if be honest, i just not undertand what you mean "not smooth in winuae". For me, on every monitor , winuae always smooth with just WaitTOF(); Winuae itself also have options for display "Fullscreen+Vsync". Maybe it's did a trick, i do not know (becouse i tryed setup FullScreen without Vsync, still smooth).

Wandarer, i think it can be different use cbs/wait for w3d window/screen, and use cbs/wait for p96/system window/screen.

Maybe it happenes becouse all warp3d code, it's just render to OpenGL code of windows dlls. Maybe (just an idea), author of QuarkTex (warp3d wrapper) already put into his code when w3d call migrate to ogl calls somethink like "OGL Sync ON", and after that windows driver works with it.

I will try what bernd_aga said too, just to check if it winuae-setting solution. Anyway, i remember that for first time, for me nothink like "Smooth" was for winuae with WaitTOF() (it was jumping/jerking), after i setup Winuae more, i have smooth animation. Just can't remember what exactly it was , will try what bernd_afa said.

In any case, if CBS/Wait works fine for mos/aos4 => it's a good solution. Becouse for winuae just can be WaitTOF() + correct setting (just write in readme that for smooth work with winuae, you must setup these setting to these values). I also will try the same code with Wazp3d (it's also warp3d wrapper, but done in 'software' mode, so, nothink about windows code).

Ok, good/bad news:

- csb/wait not works with QuarkTex
- csb/wait works with Wazp3d.

I.e. the same code works on os4,mos and on winuae_with_wazp3d
But not works with winuae_with_QuarkTex. So.. it's explain all my deadlocks which i recieve always and everythere when try to test it with QuarkTex.

@bernd_afa
Can you please expling where you found these settings ? Can't found it at moment :)

It is not smooth. I dont know about openGL and stuff, i am talking about a simple screen you are drawing on. It is acceptable if you are only moving objects, but try 2D scrolling! I will prepare a demo for you.

Wandarer. yep, demo will be good to see.
As you can see on video, i use 2d scrolling very much. For moving pictures, for scrolling articles, for changes sprites, etc. All of this based on 2d scrolling. But to be sure, please, make a demo, maybe w3d/ogl do somethink different and becouse of it..

All you ever need for smooth double buffering is WaitTOF();

All you ever need for smooth double buffering is WaitTOF();

All you ever need for smooth double buffering is WaitTOF();

Double buffering is really really really easy.
1. Draw some gfx on back screen
2. WaitBlit()
3. WaitTOF();
4. ScreenToFront()
5. Goto 1

If WaitTOF() does not work on some OSes that claim to be AmigaOS compatible then that is the manufacturer's problem not yours.

@ChaosLord
I have big discussion 2 days ago, about "why" WaitTOF(); it's bad. WaitTOF bad becouse for first, it's not 'atomic', becouse AOS are multitasking. When you do WaitTOF(), nothjink like "lock before VBL done", when you do WaitTOF and if your OS heavily loaded, then very possible that you will not have right VBL.

Indeed, at moment, everythere where i try, WaitTOF() did the trick, but if, with it, you will heavy loaded your OS by somethink which every time will do somethink , WaitTOF can works wrong. I rmember that one time, i noticed somethink like this problem , when tester said about "it's working slow". Becouse he used at backgorund some programm which stop your.

Of course can be solution just said: reboot, then run. But, OSes growing up, and someday it's possible to have inside OS somethink which will break WaitTOF() usage.

Becouse of it, WaitTOF() need to change on Wait(); It will be same almost everythere, but will avoid some problems which can happenes (not so offten, but still, and for future).


Rigth now i add tryplu buffering to morphos version , and must to say it's 1:1 the same as WaitTOF(); and my "stops" related no to bad "sync" , but to somethink wrong with cheking of intuition messages (ituiticks, etc). It's works fine over all oses, but on morphos it's not at moment. Will see which problem cause a such interestng bug which based on HZ of modes. (as henes said "if it's input related, such thing is usually caused by too long bitmap locks...(W3D_LockSomething))" . So, maybe becouse of somethink wrong in cheking/keys/code, i have such strange bug which visually can be detect not at all modes. But must to say, it's happenes on morphos only.

> If WaitTOF() does not work on some OSes that claim to be AmigaOS
> compatible then that is the manufacturer's problem not yours.
Yes, but this is true for 1000nds of other problems too, and the manufactures won't fix it (because they are dead/insolvent/lazy).
And if you want your software to run on more machines than yours, you have to face the truth that these problems exist, and do a workaround. Otherwise nobody will be able to play your game.

Your suggestion has already a huge disadvantage: ScreenToFront is damn slow once the OS starts to swap the VRAM. So unless you are ok with 4FPS, do something else than ChaosLords suggests.

Believe me, I spend many many ours on this topic.

ScreenToFront() on AmigaOS happens instantly at 60 fps no problem.

If P96OS has broken ScreenToFront() then that is a bug in P96OS that needs to be fixed (along with all the others).

If ScreenToFront() runs at only 4fps on a 1000 Mhz MorphOS machine then that is a tremendously serious bug that should be fixed immediately.

Maybe it has been fixed in OS4?


[quote]
And if you want your software to run on more machines than yours, you have to face the truth that these problems exist, and do a workaround. Otherwise nobody will be able to play your game.
[/quote]
I learned all that the hard way many times already :(
I have spent many many hours rewriting code to port my game to AmikitOS, and many more hours to port it to WinUAE. Life sux then u die.

Does WaitTOF() work on AROS?

> ScreenToFront() on AmigaOS happens instantly at 60 fps no problem.
This heavily depends were your backscreen is located. If it is in VRAM, even a Classic with Cybervision 64 3D can do >100FPS.
But what matters is what you do inbetween. If you do heavy blitting action, Picasso96 tends to swap out the backscreen. => 4FPS on Classic, I didnt mean MOS etc. Those machines are powerful enough that you wont notice it immediately. But a speedloss will be there.

@ChaosLord
All what i said before and later, all of this mean: i want make stuff works fine on all amiga and amiga like oses. It mean: os3,os4,mos and aros. Solution llike "let's they fix that and that", look like you are not in amiga world :) No one will fix nothink, even if it serius bug. It's a present situation with amiga and amiga like stuff. Even if you will found a bug , you will need explain why it's a bug (but author of morphos, or aros, or any os will move these problems away from himself and said - functions broken, we can't do it becouse it suck, we will not do it becouse we have many other works and so on, i am not about WaitTOF of course, becouse this fucntion indeed pretty bad idea to use in 'end' code if you want make "good" system-friendly app, i am about in general).

So, becouse of it, asnwers of this kind looks like like you just do not boring about make user happy, but you just already tired, and not want to found solutions. I am personally in interest to make my app works on all amiga and amiga like oses with CURRENT oses.

Even if you will said to someone - fix somethnk, you will wait 2-3 years before. And i am not sure that it will done. It's hard reality, and we all know about it, and do not need to stuck on it every time, just need to think with more 'opening' mind, and do all what we can do. Becouse of it we talk here. Not becouse said to someone - your os crap, fix that and that. Everythink more deeply and harder if you want to do somehtink normal.

Even if ScreenToFront works on morphos, it will be just slow like hell on AOS3. Becouse i am use reall true-color graphics with normal resolutions like 1024x768. Not sucking 256colors, not old and rare AGA only. And becouse of it, these solution with slow fucntions like Screen2Front, or WritePixelArray for me just make no sense.

Of course, we can said: make this and this for os3, make this and this for morphos, make this and this for aos4 - but rewriting 1megabyte of sources its huge task, and not sure that i want give up becouse of thinks which 100% can be done, just at moment not.

On AROS WaitTOF(); works for me. But again, i do not know how good it works and how it done on AROS. If it done like the same os3 fucntion 1:1, then someday/sometime some problems will be with it (but at moment it's better than nothink). There is a video from AROs of our mag with WaitTOF:
aros diskmag video

At moment AROS just not have ChangeScreenBuffer fucntion (i.e. it's empty, becouse DBUinfo/etc fucntion not done on it), so, for AROS i just do BlitBlit copy of bitmaps + WaitTOF();

Strange that the same code works fine on os3,os4,aros , but a bit stops on scrolling for morphos. I can think of course, that it can be possible that somethink wrong with morphos ITUITICKS, or warp3d ported badly (long lockups) or anythink else, but i need a solution anyway :)

In end want to said, that WaitTOF() works everythere and do what must to do (if of course you not loaded system heavy, and you do not use somethink heavy in backgorund, or your OS in 'clear' state).
So using of WaitTOF() can be possible for tests, or if coder not want boring about good compatibility and so on. And when you use WaitTOF() even for fast-tests, you must have in mind, that if somethink going wrong with speed/animation, pretty possible that somethink wrong going becouse of WaitTOF() usage.

My "stops" (as i understand at moment) was becouse of
case INTUITICKS:
dunno at moment why it's do it, before i use it like for detect "when happenes nothink", just to put scrolling routine to it whyle user press button and still hold it.

>i am not about WaitTOF of course, becouse this fucntion indeed >pretty bad idea to use in 'end' code if you want make "good" >system-friendly app, i am about in general).

to check if waittof work good, you can do that
loop
waittof();
goto loop

when you now look what cpu load your system get, and it is more than 10% then waittof work bad.

on winuae first was problem, because there need a add mesage driven code in P96 driver for vsynvc.Toni have add this then.

then waittof is same as a seperate msg port that wait for data.
The driver send a message and waitof end.if the driver does not support this, p96 do polling and the testprog above use near 100% cpu load

on winue quarktex its not possible to get this intuiton screenswap method working, best is here deactivate that code and use only single buffer.also waittof is maybe not need and only slow down

the waittof and double or triple buffer all is handled by windows opengl.

there are 2 threads in opengl, the renderer display preparsed data when a buffer is free.

and the other thread (winuae) can put data in the renderpipeline, if the next frame need precalc.

@Bernd_afa

As i understand at moment:

"badly think" of WaitTOF() not becouse it's loaded or not loaded CPU (as i kwnow it's not). The bad think, that WaitTOF() is not "Atomic" fucntion. I.e. it's not lock the totaly AOS whyle wait. You can 'fix' that just by added Permit/Forbit(), but we all know that is hell-bad idea. And becouse of it (in theory, on practic it's not so often happenes think), when WaitTOF works, some programm which heavyle loaded OS can broken WaitTOF waiting and your app will glitches.

IT's of course about 'perfect' programm. WaitTOF can be usable for test, and if you just give a fuck about other programms, and OS itself - well, solution too (anyway i use it for Aros, and will for Winaue, becouse of diferent factors), but for os4/mos/ and aos3 on normal hardware (not emulated ones) i will use Wait() from exec.

For winuae double-buffering with WaitTOF(); works fine over QuarkTex (already do it). Looks like only "signal" problem (or maybe need add somethink to code to make Wait() method works).

ps. with help of Henes fixed already these "Stops" on morphos. It was caused becose for first buggy code from me (wrong work with messages) (dunno why it works on os3/os4/aros before, just some random luck was), and becouse some timing related bug (i just remove from loop checking on INTUITICKS and move the scroll routines to other loop which solve the problem).

>when WaitTOF works, some programm which heavyle loaded OS >can broken WaitTOF waiting and your app will glitches.

that depend on task pri.what i mean, when P96 driver support no vsync messaging, then waittof code look like this

again
move.l isvsync,d0
bne again

if driver support vsync waittof is more nice

wait(.)
GetMsg(.)

and how it works can see when do this testcode

loop:
waittof()
goto loop

on mew winuae this loop does not show any CPU load

when you try older winuae (1.3) with that code you get 100% cpu load

Here are the promised test demos:

http://www.hd-rec.de/Archive/dbl_test.lha


Would be very interesting to know how it performs on your systems...

Readme:

This archive contains several test executables that
display a scrolling background and 3 bouncing balls.
It shows the current FPS and the currently used
sync method:

1 : 50Hz uses timer.device at 50Hz
2 : Monitor Calculated: uses timer.device, Hz is calculated from DisplayInfo
3 : WaitBVOP : uses AmigaOS function WaitBVOP() before flipping the buffers
4 : WaitTOF : uses AmigaOS function WaitTOF() before flipping the buffers
5 : no sync - buffers are instantly flipped when ready

Executables:

dbl_BltBitmap
Uses BltBitmap to blit the off-screen Bitmap to the visible screen.
ScreenHack(tm) is activated. This is the most compatible solution
across different systems.

dbl_ChangeScreenBuffer
Uses the AmigaOS function ChangeScreenBuffer.
Result is questionaly. The sync method should be "no sync", since
ChangeScreenBuffer seems to sync itself.

dbl_ChangeVPBitmap
Same like ChangeScreenBuffer, only with low level API of AmigaOS.

dbl_ScrollVP
Uses AmigaOS function ScrollVP() to exchange the buffers.
Uses ScreenHack too, and is the fastest of WinUAE.

dbl_Window
Runs the whole thing in a window - this is slower than fullscreen,
and uses BltBitmap for upated the Window.

On a LCD Screen the FPS should be ~60-70Hz if the scrolling should
be smooth. Check without sync (#5) what is the maximum framerate.
On my WinUAE, I get about 250-400 FPS at maximum, depending on the
double buffering method.

- Der Wanderer

a4k/csppc060/voodoo3/p96:

dbl_BltBitmap:
1:50fps
2:72fps
3:72fps
4:72fps
5:ca130fps

dbl_ChangeScreenBuffer:
1:50fps
2:72fps
3:36fps
4:36fps
5:72fps

dbl_ChangeVPBitmap:
1:50fps
2:72fps
3:36fps
4:36fps
5:72fps

dbl_ScrollVP:
1:50fps
2:72fps
3:72fps
4:72fps
5:72fps

the 640x480 mode is 72hz obviously

dbl_Window(1680x1050x16rgb,60hz):
1:50fps
2:60fps
3:60fps
4:60fps
5:150-160fps
on 24 bit workbench only the last value is different:
5:ca128fps
on32bit:
5: still around 100fps

i can measure on a4k/p4 too if need be

edit: funny enough - i tried tu reduce the resolution to see if it is going to be faster but the result under 1440x900 was always around 136fps. the 150-160fps i get above the balls are looking a little jerky (a little like interlaced) but the background scrolls smooth.