[RTG] Need help with double/triple buffering to avoid tearing in RTG modes..

[mateusz_s]

Hello,
I successfuly used triple buffering to avoid screen tearing on my FPS raycaster engine... but it works only below certain fps like 200 fps in 320x200x32

The Emu68 was able to run much above 200 fps in some moments but then the tearing was noticable. I tried on V1200 (when floor was turned off) and I got like 170-180 fps and no tearing effect. So let say that below that value triple buffering is enought.

I tried many different approaches. Right now I am using this one:
http://eab.abime.net/showthread.php?t=109186
(I changed it from double to triple buffering)

Do you know any better way? or how to correct this double buffering code?
Please note that when I run the orginal double buffered code I got tearing in 60-80 fps so that was not enough. I got rid of it making triple buffering. But again its not enought for higher rates.

this is example of tearing in over 200 fps (about 0:14s)
as you can see when resolution is higher the fps drops
so no tearing is visible no more:
[ Show youtube player ]

[Samurai_Crow]

P96 has a bug when allocating multiple buffers in early releases, I think. Try allocating a triple-tall buffer and scroll the view super-bitmap style to access the buffers stacked vertically.

[mateusz_s]

Originally Posted by Samurai_Crow

P96 has a bug when allocating multiple buffers in early releases, I think. Try allocating a triple-tall buffer and scroll the view super-bitmap style to access the buffers stacked vertically.

Do you mean problems with AllocScreenBuffers? I noticed that its not allocating them ( only if it connected with screen bitmap).. but thats no problem, because after AllocScreenBufeer i am allocating nitmaps myself and then switching the pointer in screenbuffer structure. So I am Ok with that.

The double or triple buffering works overall.. the problem is with switching buffers sync.

For example the Payback game (Amiga 3d GTA clone) works ultra fast in 320x200 or 640x400 and no tearing occurs

[Thomas Richter]

Originally Posted by mateusz_s

Hello,
I successfuly used triple buffering to avoid screen tearing on my FPS raycaster engine... but it works only below certain fps like 200 fps in 320x200x32

There is none, or none that works in general. To avoid tearing, you need to synchronize to the vertical sync of the screen, which would limit you to the vertical refresh frequency of the screen. It does obviously not make sense to refresh the screen more often because the result would not be visible anyhow.


The typical approach of syncing to vertical sync is either WaitTOF() or WaitBOVP(), both in the graphics.library. WaitTOF() has unfortunately the issue that it waits for a vertical raster interrupt of the corresponding VGA chip that drives the graphics, but not all RTG cards have this interrupt connected, so it does not work in all cases. For cards that cannot generate interupts, WaitTOF() falls back to the system WaitTOF(), i.e. it waits for the vertical retrace of the native chipset then.


WaitBOVP() works always, but it is a busy-wait, by continuously polling the vertical scan position of the RTG chipset, and returning only at the end of the display. This means that it burns a lot of CPU time.

[mateusz_s]

Originally Posted by Thomas Richter

There is none, or none that works in general. To avoid tearing, you need to synchronize to the vertical sync of the screen, which would limit you to the vertical refresh frequency of the screen. It does obviously not make sense to refresh the screen more often because the result would not be visible anyhow.


The typical approach of syncing to vertical sync is either WaitTOF() or WaitBOVP(), both in the graphics.library. WaitTOF() has unfortunately the issue that it waits for a vertical raster interrupt of the corresponding VGA chip that drives the graphics, but not all RTG cards have this interrupt connected, so it does not work in all cases. For cards that cannot generate interupts, WaitTOF() falls back to the system WaitTOF(), i.e. it waits for the vertical retrace of the native chipset then.


WaitBOVP() works always, but it is a busy-wait, by continuously polling the vertical scan position of the RTG chipset, and returning only at the end of the display. This means that it burns a lot of CPU time.

Thanks for help. I didnt Try but Maybe putting WaitBOVP() in separate task would not affect the main loop.

[aros-sg]

Originally Posted by Thomas Richter

WaitBOVP() works always, but it is a busy-wait, by continuously polling the vertical scan position of the RTG chipset, and returning only at the end of the display. This means that it burns a lot of CPU time.

Why can't WaitBOVP() poll position once, calculate how much time is left until end of display and then wait using timer.device?

[Samurai_Crow]

Originally Posted by aros-sg

Why can't WaitBOVP() poll position once, calculate how much time is left until end of display and then wait using timer.device?

Because timer.device doesn't support the timing resolution needed. You could try using a CIA timer to do that though.

[Thomas Richter]

Well, there is a timer.device unit that supplies below-frame resolution, because it is actually based on the CIA timers. That is timer.device unit 1.

But, all that aside, it doesn't solve the problem. Just because main thread waits does not save you from burning CPU time in a side thread, CPU time that is not available for anything else. We only have a single CPU core, and this is with the suggested design simply busy by polling the VGA registers - either in a separate thread, or in the main thread.

[aros-sg]

No, no. That's not what I mean. If WaitBOVP() polls scan position once, shouldn't it be able to figure out how much time will need to pass until scan position will reach bottom of viewport and then just wait that amount of time using timer.device. So for example if the polled scan position indicates that you are on line number 200, and you know that bottom of viewport is line number "x" (for example 400) and that one frame lasts time "t" (and how much time one line lasts), do the math to calculate how much time will need to pass until that point in time. And then just wait this amount of time. No busy polling.

[hooverphonique]

Originally Posted by aros-sg

Why can't WaitBOVP() poll position once, calculate how much time is left until end of display and then wait using timer.device?

Well, I think you should be able to eliminate a great deal of busy-waiting by delaying until close to BOVP, then busy-wait for the rest to get an exact result.

[Thomas Richter]

Originally Posted by aros-sg

No, no. That's not what I mean. If WaitBOVP() polls scan position once, shouldn't it be able to figure out how much time will need to pass until scan position will reach bottom of viewport and then just wait that amount of time using timer.device.

The problem with this approach is that there is no publicly available API to request the current scan position. I could add one the Picasso96API.library, though, as in principle this information is available at driver level. Well, almost always, the pre-3.1.0 CVision3D driver did not supply this information for Zorro-II due to some idiocracies of the card. But this will probably not happen before the 3.3.0 release of P96, and that's a bit away. I'm currently only making bug fixes and do not add features, too late for 3.2.0.

[aros-sg]

Originally Posted by Thomas Richter

The problem with this approach is that there is no publicly available API to request the current scan position.

Why does it need to be public? The poll-scan-position-once-then-calc-delay-then-wait-with-timerdevice-thing only needs to be done internally inside the WaitBOVP() function (and maybe inside WaitTOF()) too), for gfx cards where interrupt does not work. Not by apps themselves.

You said "WaitBOVP() works always, but it is a busy-wait, by continuously polling the vertical scan position of the RTG chipset", so WaitBOVP() already has the means to request the current scan position.