So you hope he's going to do that hard work for you? ;-)
The tearing is based on copying/blitting the backbuffer to the front buffer which is part of the visible screen - and the blit getting overtaken by the vertical refresh/beam of the display. Is there any kind of tearing present in fullscreen mode?
You could try implementing your own `Flip` routine. In OpenGL at least, you can set the read and write buffers and probably can copy the backbuffer to the front buffer by yourself. This would also preserve the backbuffer which might be handy for some games. Maybe you can then split up the copy into sections, maybe do one half at a certain time in the loop and the other half later or something, so that you avoid the tearing region? Just an idea.. might not help.
I think you would only get tearing where the refresh rate of the display is faster or slower than the rate at which the backbuffer is blitted into view - ie the memory transfer rate. Even if you synchronize the flip with the vertical blank, you can't be sure that the data copy is going to be fast enough not to get overtaken by the refresh beam. Any form of copying data to the visible display is prone to becoming torn, unless it's able to always be `ahead` of the oncoming beam/refresh.
What you have is two competing refreshes and the tearing is the overlap. You need to make sure you are blitting the backbuffer to the front buffer BEFORE and always ahead of the refresh beam, but the blit must also not catch up to the beam. Ideally you need them to be about half-a-cycle/frame offset from each other. Doing the flip AT the vertical blank point is not a good idea because you're only going to have a short space of time between the beam being at the bottom of the display and starting to refresh at the top, to be ahead of the beam and have it not catch up.
You need to wait for half-a-frame prior to the vwait, and flip at that point. That would give you immediate update of the current frame. Otherwise you could wait for the vertical blank, THEN wait half a frame, then blit the backbuffer to the front, but this update would then not show until half a frame later, so slightly late.
You can find out what half a frame is by measuring the millisecs that each frame takes, or computing it.
Another option is do organize your code so that it flips halfway through a vertical refresh period .. ie, if you can't modify the flip code and you have to use Flip 1, and it is vblank synchronized, then maybe you can somehow have it draw half of the next frame, Flip 1, finish the second half of the previous frame and start the first half of the next.
This is where triple buffering becomes beneficial, which really is probably what you need for perfect refreshes.
I know that OpenGL *sometimes* has support for auxiliary buffers, which could be used as a second backbuffer.
I have a question though .... if you are going to be worried about synchronizing with the vertical blank, and you are looking to update things at the vertical blank, then if possible you could sort all your drawing operations into vertical order, and just draw then straight to the front buffer in order. Might have the same effect as a double or triple buffer since the user doesn't SEE the visible display until the refresh passes over it. This also removes the need to blit the whole display into view which means the game runs faster. But I know some games by design can't very easily do things in vertical order.
Just some ideas. Sorry to get off-topic.
The tearing is based on copying/blitting the backbuffer to the front buffer which is part of the visible screen - and the blit getting overtaken by the vertical refresh/beam of the display. Is there any kind of tearing present in fullscreen mode?
You could try implementing your own `Flip` routine. In OpenGL at least, you can set the read and write buffers and probably can copy the backbuffer to the front buffer by yourself. This would also preserve the backbuffer which might be handy for some games. Maybe you can then split up the copy into sections, maybe do one half at a certain time in the loop and the other half later or something, so that you avoid the tearing region? Just an idea.. might not help.
I think you would only get tearing where the refresh rate of the display is faster or slower than the rate at which the backbuffer is blitted into view - ie the memory transfer rate. Even if you synchronize the flip with the vertical blank, you can't be sure that the data copy is going to be fast enough not to get overtaken by the refresh beam. Any form of copying data to the visible display is prone to becoming torn, unless it's able to always be `ahead` of the oncoming beam/refresh.
What you have is two competing refreshes and the tearing is the overlap. You need to make sure you are blitting the backbuffer to the front buffer BEFORE and always ahead of the refresh beam, but the blit must also not catch up to the beam. Ideally you need them to be about half-a-cycle/frame offset from each other. Doing the flip AT the vertical blank point is not a good idea because you're only going to have a short space of time between the beam being at the bottom of the display and starting to refresh at the top, to be ahead of the beam and have it not catch up.
You need to wait for half-a-frame prior to the vwait, and flip at that point. That would give you immediate update of the current frame. Otherwise you could wait for the vertical blank, THEN wait half a frame, then blit the backbuffer to the front, but this update would then not show until half a frame later, so slightly late.
You can find out what half a frame is by measuring the millisecs that each frame takes, or computing it.
Another option is do organize your code so that it flips halfway through a vertical refresh period .. ie, if you can't modify the flip code and you have to use Flip 1, and it is vblank synchronized, then maybe you can somehow have it draw half of the next frame, Flip 1, finish the second half of the previous frame and start the first half of the next.
This is where triple buffering becomes beneficial, which really is probably what you need for perfect refreshes.
I know that OpenGL *sometimes* has support for auxiliary buffers, which could be used as a second backbuffer.
I have a question though .... if you are going to be worried about synchronizing with the vertical blank, and you are looking to update things at the vertical blank, then if possible you could sort all your drawing operations into vertical order, and just draw then straight to the front buffer in order. Might have the same effect as a double or triple buffer since the user doesn't SEE the visible display until the refresh passes over it. This also removes the need to blit the whole display into view which means the game runs faster. But I know some games by design can't very easily do things in vertical order.
Just some ideas. Sorry to get off-topic.