waiting for the screen... (v-sync)

Started by
5 comments, last by g 21 years, 6 months ago
How can I avoid wasting time waiting for the vertical retrace before flipping my primary and back-buffer? I can''t seem to find much material on this topic around the web, but some of the possiblities appear to be: * Don''t wait for retrace; this may result in ''tearing'' artifacts which I''d rather avoid. Does anyone know if there are any other problems with this approach? * Triple-buffering. I can start to render the next frame before dispatching the current one, but this may introduce unnecessary lag between the game world and what is visible on the screen, and the program may be so busy rendering ahead that it actually misses a retrace. * Run a seperate thread which handles waiting for the vertical retrace and page flipping, perhaps combined with triple-buffering. This seems very messy to me, and I don''t know how reliably thread timing can be done anyway.
Advertisement
What is the problem with wasting time? If your app can do the whole frame in less than a vblank, then what is left to do that you want to use the wasted time for. Just give it back to the OS to do other stuff like checking for e-mails etc.
quote:Original post by DBX
If your app can do the whole frame in less than a vblank, then what is left to do that you want to use the wasted time for.


OK, say my screen refreshes at 90 Hz. If rendering takes less than 1/90 of a second then you''re quite right, I might as well give up the extra time to a more worthy cause. However, what if rendering takes, say, just a fraction over 1/90 of a second. Now instead of getting nearly 90 FPS, I will get about half that, since we just miss each retrace and don''t continue until the next.

Admittedly, 45 FPS is still pretty good, but what if rendering takes, say just over 4/90 of a second. Then instead of getting around 90/4 = 22.5 FPS I will get about 90/5 = 18. That''s quite an important difference, I think.
I understand what you''re saying there, if rendering takes your over one frame then the framerate will half. To stop it doing that you will have to render quicker - i.e. less than a frame.
I''m not entirely sure what your question is in that case.
Well, I can''t really control my rendering time that precisely as objects will be continuously coming into and out of view.

I''m beginning to think that triple-buffering is my solution - but I need a way to catch the vsync when it occurs so that I can seize the opportunity to flip. Does anyone have any suggestions, or else where can I hope to find out more? (tried google, and gamedev resources, not much luck)
http://www.mvps.org/directx/articles/using_a_blit_queue.htm ?

It''s DirectDraw specific, but maybe it''ll help.
Thanks for the interesting link. It seems to suggest that I can basically do any processing that doesn''t involve actually drawing, as long as I keep checking for vsync with some regularity.

This topic is closed to new replies.

Advertisement