Why Flip for Frontbuffer()?

BlitzPlus Forums/BlitzPlus Programming/Why Flip for Frontbuffer()?

Imphenzia

(Posted 2003) [#1]

In B+ you now require a flip command after drawing to the frontbuffer, any idea why?

Edit:
Ah, after reading more carefully in the docs it's only there for compatibility and returns the same reference as backbuffer(). Hm, Can't say I understand why you would remove frontbuffer? I use it to update a progress bar when loading to save myself from flipping and keeping track of two buffers. It also killed my pixel screenfades that were writing black pixels to the frontbuffer to blank out.
I'll rethink.

Seldon

(Posted 2003) [#2]

I can agree with you, to draw directly to FrontBuffer() is something should be still allowed to programmers. Anyway, I tried the demo and there are still 2 buffers there. For the progress bar, you can use a splash window on desktop and then you open the full screen.

Richard Betson

(Posted 2003) [#3]

If I remember right Mark told me that B+ can not write to the FrontBuffer() the same as Blitz 2D/3D do to MS's DX. Apparently DX does not actually support it. :)

L8r,

Imphenzia

(Posted 2003) [#4]

Ok, fair enough if it's not actually DC supported =)

I worked around it with

VWait
Flip False
setbuffer backbuffer()
<do changes here>
Flip False

_Skully

(Posted 2003) [#5]

if you are going to do vwait and then flip false you might as well just do a flip true

Skully

Imphenzia

(Posted 2003) [#6]

I noticed that "Flip [True]" doesn't actually wait for the VSync if graphics cards are configured to High performance. In the DX setup on my Radeon card I set my settings slider to high performance to test and it doesn't wait for the VSync with Flip True =(

By writing:
VWait
Flip False
...instead of "Flip True" it will wait for the VSync despite any graphic card settings.

Stefan

skidracer

(Posted 2003) [#7]

What do you mean by doesn't actually wait, are you referring to the GPU or the CPU?

The True in Flip True tells the GPU to wait for vsync b4 flipping.

Vwait on the other hand commands the CPU to busy wait for vblank.

I wouldn't recomend VWait:Flip False, from my experience low end cards such as Matrox Milleniums will tear easily due to rendering still being performed by the GPU.

Imphenzia

(Posted 2003) [#8]

Ok, not sure how to get the best result then.

If I have a loop, like:

   Setbuffer backbuffer()
   <do stuff here that is required once per screen refresh>
   Flip True

..and my Direct3D settings have been configured for performance before quality (Radeon 9700), the "Wait for Vertical VSync" option is changed to "Always off" instead of "Application Preference". Unfortunately the 2D routine I make relies on the screen only being updated once per sync.

I suppose what I could do is to implement something that detects this. In a split second a loop can determine whether it's running much faster than the refresh rate and "VWait: Flip False" is used, but under normal circumstances "Flip True" is used.

Thanks for the info on VWait by the way.

Michael Reitzenstein

(Posted 2003) [#9]

2D over different refresh rates and different VSync modes is probably one of the toughest problems to crack. How can you have the game the same speed on 60hz as 85hz without it jerking everywhere?

With my engine (you can read about it in the worklogs), I have simply copied the 3D tweening system, updating the game at only 58.82fps (17 millisecs exactly), and then tweening object positions between that. It looks quite good on 60hz, and ok on 85hz (and anything else), and will run the same speed even if you are only getting 15fps.

Imphenzia

(Posted 2003) [#10]

Michael >> I agree, these problems are really bugging me but I realise that a good compromise has to be found. I am quite happy with the smoothness of my game now, it updates on every screen sync but the game also runs at the same rate as the frequency. I solve it by using a multiplier that will scale the movements appropriately with floats, it is not 100% perfect as some things may slightly differ in 60Hz vs 120Hz. I'd be interested to have a look at your engine anyway, just in case. How would your engine cope if vsync is forced off and the game effectively runs at something like 300fps?

So, at the moment, I think I can accept the smoothness vs different refreshrates... and I'll have to use that checker whether vsync is forced off or not on graphics cards.

Stefan