Talks about perfect double-buffering for graphics.

a4k/p4 (p96):

dbl_BltBitmap:
1:26.x fps
2:25.x fps
3:23.9 fps
4:23.9 fps
5:26.x fps

dbl_ChangeScreenBuffer:
1:5.5 fps
2:5.5 fps
3:5.2 fps
4:5.2 fps
5:5.5 fps

dbl_ChangeVPBitmap:
1:5.5 fps
2:5.5 fps
3:5.1 fps
4:5.1 fps
5:5.5 fps

dbl_ScrollVP:
1:23-34fps (the value fluctuates, output is a little jerky at some intervals, strange)
2:as above
3:as above
4:as above
5:as above

dbl_Window(1152x900x16rgb):
1:26.x fps
2:26.x fps
3:19 fps
4:19 fps
5:26.x fps

now, thats it. i wonder only why unarc on this machine extracts executables as projects. annoying. have to look into it..

Pegasos II G4/MorphOS 2.2/Radeon 8500LE

dbl_BltBitmap:
1: 50 fps
2: 75 fps
3: 75 fps
4: 75 fps
5: 400 fps

dbl_ChangeScreenBuffer:
1: 25 fps
2: 25 fps
3: 19 fps
4: 19 fps
5: 25 fps

dbl_ChangeVPBitmap:
1: 25 fps
2: 25 fps
3: 19 fps
4: 19 fps
5: 25 fps

dbl_ScrollVP:
1: 50 fps
2: 75 fps
3: 75 fps
4: 75 fps
5: 549 fps

dbl_Window(1920x1200x32, 3D layers):
1: 30 fps
2: 29 fps
3: 25 fps
4: 25 fps
5: 31 fps

In windowed mode all graphics were missing. ChangeVPBitMap executable crashed on exit. ChangeVPBitMap and ChangeScreenBuffer demos have got no background gfx and max fps is 25 and cpu usage is constantly at 100%.

Edit: dbl_Window throws some notes from graphics.library:

planar blits with rgb source only supported for dX=dY=0 and minterm 0xC0 yet
sbm 23946e94 sX 0 sY 18 dbm 2394cbbc dX 634 dY 478 w 6 h 2 minterm c0 mask ff

Edit2: dbl_ChangeScreenBuffer is also throwing notes from graphics.library:

planar blits with rgb source only supported for dX=dY=0 and minterm 0xC0 yet
sbm 25f6b00c sX 0 sY 94 dbm 23825134 dX 0 dY 478 w 128 h 2 minterm c0 mask ff

Looks like BMF_MINPLANES was not set.

And all demos are throwing Cyberguard hit on exit (harmless):
Exception 3 <Illegal Data Access at fffffffe DSISR 40000000, Load from a not existing Page>

Thank you for your detailed analysis.
I guess I ouw you now a FPS analysis from my WinUAE.

However, wawa's Voodoo system performs exectly like exspected.
His P4 system is a bit too slow for 24bit, but would still give decend performance on 16bit, this is significantly faster. I know this from my Cybervision 64, its more than twice as fast on 16bit than on 24bit, dont know why.
The Peg system performs a little bit strange.

@ChaosLord
From the analysis you can see now that you would not get far with ScreenToFront. The ScreenHack(tm) really pays off (present in BltBitmap and ScrollVP). As soon as you allow P96 swapping (ChangeScreenBuffer/Bitmap), it sucks. (5.5fps vs. 26.0fps)
Well at least if you a short in VRAM.

Edit: Itix, you are right. I forgot the BMF_MINPLANES. I added it now. Will prepare an update.

Edit2: BTW, the fps is one thing, but those demos are not intended to be a speed test in the first place and are not optimized at all.
The question is, if any of those Flip/Timing methods look smooth wihtout jerky gfx. e.g. 72Hz can look smooth and 73Hz looks jerky, if your monitor has 72Hz.

Edit3: I found out, that if I set in WinUAE (1.6) under RAM "refresh rate = Chipset", the scrolling looks significantly better. However, not perfect yet, I have some horizontal jerks on top of the screen, but they are not moving anymore across the window.

[quote]
From the analysis you can see now that you would not get far with ScreenToFront.
[/quote]

1. You didn't even try WaitTOF(); ScreenToFront() technique.

2. I already tested all above methods many years ago. WaitTOF(); ScreenToFront() is the correct technique on AmigaOS 3.x

3. I don't see any test results for AmigaOS 3.x

I see test results for MorphOS (not AmigaOS) and P96OS (not AmigaOS). As you well know, MorphOS, CyberGrafxOS, Picasso96OS, ElboxOS and OS4 each have various broken functions.


On AmigaOS it is very very easy to do double buffering and smooth scrolling. It is very very easy to do smooth scrolling without double buffering. It only gets complicated on OSes which flatly refuse to comply with AmigaOS API.

[quote]
2. I already tested all above methods many years ago. WaitTOF(); ScreenToFront() is the correct technique on AmigaOS 3.x
[/quote]

You dont understand that CGX and P96 are moving non-displayed screens from VMEM to the fast ram. This must be done because the Workbench screen alone could eat most of your VMEM leaving next to nothing for your game.

> 1. You didn't even try WaitTOF(); ScreenToFront() technique.
No, but this boils down to WaitTOF() ScrollVP() without screenhack. (only more overheaded)
I could easily implement it, but I know the result already.

> 2. I already tested all above methods many years ago.
> WaitTOF(); ScreenToFront() is the correct technique on AmigaOS 3.x
It is ok as long as no bitmaps are swapped.
But ScrolllVP() should be ok too.

> 3. I don't see any test results for AmigaOS 3.x
It seems like you create missunderstanding in purpose.

What you call "AmigaOS3.x" is AmigaOS3.x using OCS/AGA.
But the thing here is, we want to program games that run on ALL platforms, preferably using GFX card. Using AGA/OCS is a solved problem, and if such a machine is a mandatory requirement, I wouldnt even use AmigaOS to improve performance.
But we have 2009, and it would be nice to take advantage of GFX cards and to write something that works if no Custom Chips are present in the system. And this is not a sovled problem, that is why we have the discussion here.

Ok, here is an update. Should fix MOS problems with MINPLANES.

I am still curious if there are other hits/bugs...
(this is the RTG doublebuffering engine of Ambiltiz3)

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

@wanderer: i do not get no hits on both the machines in question. running memtracker, muforce,sashimi and all that stuff now by default i would have noticed i believe.

what does look smooth? well not the hardcoded 50hz thats for sure, and not maxspeed. best results are when sync is adjusted to the monitor refresh, as expected, id say. but have to look again.

anyways i have not noticed much tearing on any of the test, in fact mostly none at all.

WinUAE Fullscreen+VSync (Vista, Core2Duo 1.8 GHz Laptop, 1600x1200x32 WB Screen, 60Hz Screen)

dbl_BltBitmap:
1:50 fps (fix 50Hz, as expected)
2:60 fps (calculated 60Hz, as expected)
3:58 fps (WaitTOF, very jittery, why <60HZ!?)
4:58 fps (WaitBOVP behaves identical to WaitTOF())
5:300 fps (only CPU is the limit, as expected)

dbl_ChangeScreenBuffer:
1:48 fps (50Hz timer + WaitTOF() in ChangeScrBuff() = jerk)
2:58 fps (60Hz timer + WaitTOF() in ChangeScrBuff() = jerk)
3:29 fps (WaitTOF() + WaitTOF() in ChangeScrBuff() = half speed)
4:29 fps (WaitBVOP() + WaitTOF() in ChangeScrBuff() = half speed)
5:58 fps (WaitTOF() in ChangeScrBuff() ony, why the hell<60Hz and jittery!?)

dbl_ChangeVPBitmap:
=> like ChangeScreenBuffer

dbl_ScrollVP:
1:50 fps (50Hz, as expected ...)
2:60 fps (60Hz, as expected ...)
3:58 fps ??
4:58 fps ??
5:300 fps (as expected ...)

dbl_Window(1152x900x16rgb):
1:50 fps (50Hz, as expected ...)
2:60 fps (60Hz, as expected ...)
3:49 fps ??
4:50 fps ??
5:135 fps (as expected, could be faster somehow)

All are kind of jerky, non looks really smooth, especially WaitTOF and WaitBVOP look very jittery. Even though I set CPU IDLE to the left most position.
The ones that run constantly at 60Hz look acceptable, but not 100% correct.
(still horizontal artefacts)

@itix

mabye your results look different with the fixed version of the test.

The window FPS are not acceptable, regarding how fast the machine can be fullscreen (500FPS...)

@wanderer: what horizontal artefacts? tearing?

@wawa
Yes, tearing is the correct term. Thanks.

on voodoo tearing is marginal for what i would expect. mostly i do not see it at all.
for all tests monitor calculated gives best effect, waittof is slightly better on window mode i believe and works best for most examples if not for dbl_ChangeScreenBuffer and dbl_ChangeVPBitmap where it halves the effective framerate. but where it works well the difference between calculated and waittof is still next to nothing.

the new dbl_none gives inacceptable output. sprites and text flicker or disaperar for seconds. some tearing on scrolling bacground too.

according to idle68k my cpu load on neither example nor mode ever exceeds 50%, actually it varies around 40 (its an060 of course). so i dont think waittof looks problematic. what i wonder is, what actually limits max speed if not cpu performance, it must be due to maximal refresh rate of gfx card or something.. am i wrong?

If you limit the FPS, the CPU has always some Idle time unless it is not able to render the frames in time.
Anyway, looks like the Voodoo driver works nicely.

> dbl_ChangeScreenBuffer and dbl_ChangeVPBitmap where it halves the effective framerate.
It havles the framerate because those functions do WaitTOF() internally, so at the end I have two WaitTOF()'s, and therefore wait 2 frames for an update => halve FPS!

Those two functions do not requite external syncing, and should be therfore used in mode 5 (=no sync).

The voodoo driver seems to take a little care about refresh, otherwise you had terrible tearing using the "calculated" timer mode. Because the calculated timing can never match 100% the screen, only 99.999% :-/
The dbl_None demo is just for completeness, but obviously looks bad (that's why we try to do double buffering!)

[quote]If you limit the FPS, the CPU has always some Idle time unless it is not able to render the frames in time.
Anyway, looks like the Voodoo driver works nicely. [/quote]
no, i mean max speed isnt causing significant additional load at all, even with 160fps. isnt that strange? btw i just updated my picasso96 setup following elbox advice lately. it delivers correct results to bestmodeid now which was the problem before if you recall. maybe there are other fixes as well, im not aware, but all in all voodoo works nicely now.

Pegasos II G4/MorphOS 2.2/Radeon 8500LE, dbl_test2:

dbl_BltBitmap:
1: 50 fps
2: 75 fps (flickers)
3: 75 fps
4: 75 fps
5: 400 fps

dbl_ChangeScreenBuffer:
1: 50 fps
2: 75 fps
3: 37 fps
4: 37 fps
5: 75 fps

dbl_ChangeVPBitmap:
-> like dbl_ChangeScreenBuffer

dbl_ScrollVP:
-> like dbl_Test1

dbl_Window (1920x1200x32, 3D layers):
1: 50 fps
2: 75 fps (incorrect, should be 60 Hz)
3: 60 fps
4: 60 fps
5: 335 fps

dbl_None:
1: 50 fps
2: 75 fps (flickers)
3: 75 fps
4: 75 fps
5: 605 fps

WaitBOVP() causes 100% CPU load but not in dbl_Window where it is identical with WaitTOF().

Edit: even though bg render is smooth balls are slightly jumpy always. I dont know if it is just algorithm or my TFT.

Aos4.1 / pegasos2 g4/1ghz / radeon9200pro on dbl_test2. Monitor : Flatron l192ws LG.

dbl_Bitmap: 1 - 50, 2 - 75.2, 3 - 74.6, 4 - 74,6. 5 = 300
dbl_ChangeScreenBuffer: 1 - 50, 2 - 74,6, 3 - 37,3. 4 - 37.3, 5 - 74,6
dbl_ChangeVPBitmap the same as dbl_ChangeScreenBuffer
dbl_ScrollVP: 1 - 50, 2 - 74.6 , 3 - 74,6, 4- 74,6 , 5 - 74.6
dbl_Window: 1 -50, 2 - 91, 3 - 64,6, 4 - 64,6 , 5 - 186
dbl_None: 1 - 50 , 2 - 75,2 , 3 - not visibly text, 4 - not visibly text, 5 - 410

@itix

[quote]It wouldnt help with MorphOS. There vertical blanking interrupt is static 50 Hz timer not linked to gfx card vertical sync[/quote]

Now that just seems silly. What does it do on a Pegasos USA system? Where in fact it should generate 60Hz.

@kas1e

[quote]omg, one more soltuion which is pretty hard for me to implement i think :) Have any work-live example without refering to autdocs ?:)[/quote]

Yes, at the end.

[quote]At moment i give up, need wait some hourse .. But i really want to say "for what the hell this MUST BE think not implement in all oses like it's done right now in OS4". But ok, let's be patient and try to make it works :)[/quote]

Yeah, that does make it hard. I womder how the system does it.

[quote]Hypex, i also think, than on AOS4 it can be good for you just becouse you put somethere WaitTOF(), you sure that you not ?[/quote]

Nah, it's all in AddIntServer(). Check for yourself below, it's written in AmigaE. :-)

[csource]-> TrapIntTest.e

MODULE 'exec/interrupts',
'exec/nodes',
'exec/tasks',
'exec/memory',
'hardware/intbits',
'dos/dos'

OBJECT data
task
data
ENDOBJECT

PROC main()
DEF trapis:PTR TO is, data:data, flags, running=TRUE, fps

data.task:=FindTask(NIL)
data.data:=0

trapis:=NewM(SIZEOF is,MEMF_PUBLIC OR MEMF_CLEAR)
trapis.ln.name:='TrapInt'
trapis.ln.pri:=0
trapis.ln.type:=NT_INTERRUPT
trapis.data:=data
trapis.code:={trapInt}

WriteF('Counting FPS...')
AddIntServer(INTB_VERTB,trapis)
Delay(50)
fps:=data.data
PrintF('approx \d\n\n',fps)
PrintF('Monitoring VBLanks...Ctrl-C to break\n')
data.data:=0

REPEAT
flags:=Wait(SIGF_SINGLE OR SIGBREAKF_CTRL_C)
IF (flags=SIGF_SINGLE) THEN PrintF('Exception caught! \d\n\c',data.data,11)
UNTIL (flags=SIGBREAKF_CTRL_C)

RemIntServer(INTB_VERTB,trapis)

PrintF('\n\d times!\n',data.data)
ENDPROC

trapInt:
ADDQ.L #1,4(A1)
MOVE.L (A1),A1
MOVE.L #SIGF_SINGLE,D0
MOVE.L 4,A6
JSR Signal(A6)
exit:
MOVEQ #0,D0
RTS
[/csource]

@Itix

will be safe , just do somethink like this on exit stage:

[csource]
Delay(10);
FreeScreenBuffer(screen,buffer[0]);
FreeScreenBuffer(screen,buffer[1]);
[/csource]

I.e., without any signal handlers. Just wait a bit for making sure that everythink is done, then free it. Or will be problems with buffer which at moment was "last" ?


@hypex
I am already found (you can read in last posts), that WaitTOF() it's not broken on Morphos. Everythink ok with it. Problem was a bit different.

@kas1e

It works but it is not done right. If you are afraid of infinite Wait()s it is better implement simple timeout loop:

[quote]
for (i = 0; i < 100; i++)
{
if (GetMsg(myport))
break;

Delay(1);
}
[/quote]

Personally I prefer making it right without Delay()s.

Itix, it's all just becouse over winuae/quarktex Wait(); not works,so, i must use WaitTOF() .. (and becouse of it i have no ports, and just think about how to do it with more-or-less "ok").

Cool demo! I can verify wawa's P96 Mediator results. Everything except the dbl_None is super smooth. I tested with the newer demos...

AmigaOS 3.9, 68060@75MHz, Mediator with Voodoo4, latest P96.

BlitBitmap 50,104,97,97,112
ChangeScreenBuffer 50,103,52,52,103
ChangeVPBitmap 50,103,52,52,103
ScrollVP 50,102,101,101,102
None 50,104,?,?,120
Window 800x600x16 50,101,100,100,197
Window 1600x1200x24 50,78,77,77,120

Want up this thread becouse of somethink new. Do not will be a solutin to make the software interrupt based on actual Hz of current mode + calculate the smooth fps, etc ? In general it must be works the same on os3/os4/mos/winuae. Just check this thread about interrupts (in end i post code which fully emulate vblank kind interrupt).

a little ot: is there some solution to use vsync on 68k sdl? im affraid not, but if yes i would be grateful for any help. i have ported nice little demo with acceptable framerate but there is terrible tearing on fullscreen due to much movement.