Archived

This topic is now archived and is closed to further replies.

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

This topic is 5538 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites