Jump to content
  • Advertisement
Sign in to follow this  
bencelot

OpenGL Time between VSync'd frames alternates dramatically ..

This topic is 2953 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

Hey all!

Ok, basically here's what's happening. I've got my game running with VSync on my very fast computer at 60 FPS. I'm using C++, Opengl (GLFW) and Visual Studio EE 2010 in Debug mode.

I'm working on my timestep and recording the delta time for each frame. Normally it will be a nice clean expected 16.67ms per frame. But every so often it will start to alternate dramatically between 3 numbers that add up to ~50ms (16.67*3) but are way apart. For example: 6ms, then 10ms, then 33ms. Then it'll keep repeating that pattern for about a second or so and then return to a nice healthy 16.67ms again. So on average it's maintaining an FPS of 60, but each frame isn't always going to be 16.67ms.

Now.. is this normal? Is this just the way certain monitors behave.. like a hardware limitation, perhaps? I guess I always assumed that each frame would be exactly 1/60th of a second apart.. but maybe it's only on average.

It's kinda screwing up my timestepping, but I can work around that. I just want to know if this is an unavoidable fact of monitors and vsync that can't be avoided.


Cheers,
Ben.

Share this post


Link to post
Share on other sites
Advertisement
Ok, with more testing I can confirm that it always happens over a span of 3 frames, and the last is always 33ms (ie, the length of 2 frames). So it's as if it's rendering 2 frames in the first 16.67ms, and then skips the next frame to make up for it, resulting in a 33ms wait. The time between the first 2 frames can be any combination that adds up to 16.67ms.. though whatever the combination is, it remains the same through the 'spurt' of irregular activity.

It's really strange. Anyone noticed this before? I never did because I was using a varying timestep and have only just converted to a fixed one (with an accumulator). I'm wondering if it's a problem with the GLFW swap function, or the monitor..

Share this post


Link to post
Share on other sites
Do you use an ATI video card? In my current OpenGL project I'm experiencing a similar Vsync issue with frame times alternating between something under 16.6ms, exactly 16.6 ms and 33.3 ms. That same project runs perfectly smooth using Vsync on a laptop using a Nvidia card.

I don't know what causes this but have read about this kind of problem a few times. I'm using GLFW to set up an OpenGL window, so wrong window code is a little unlikely.

Share this post


Link to post
Share on other sites
Nah, I'm using a GeForce GTX 275. Haven't tested it on other computers yet.

It seems that your thing is doing exactly what mine is.. very weird. Maybe my gfx card is acting strange too. I've tried to find some more info about it but haven't had much luck. If you know of any links please share.

Also, did you mean to say that you're not using GLFW? Because if you were, if anything wouldn't that suggest that GLFW is more likely to be the common cause?


Anyway, I was thinking of a way to combat this.. seeing as it has a predictable pattern of x, 16.67, 33.3ms every time, if every frame you add the previous delta time with the current delta time and notice that they're close to 16.67, then you can predict that the NEXT frame is going to be skipped and will result in an ugly and jittery 33ms gap.

So what I'm about to test right now is upon this detection, temporarily disable vsync for the next 32ms or so using glfwSwapInterval(0). Provided that the computer is fast enough, it will fill in the blanks of that 33ms gap and when the timer runs out, reenable vsync with glfwSwapInterval(1). Obviously you'll only want to do this is the average FPS is =~ 60 though, because it's pointless if the computer is any slower.

Now, if it is indeed a physical limitation of the monitor or the gfx card is screwing up then this isn't going to do an extra RENDER in that 33ms gap.. but what it will do is allow your physics and game logic to calculate more smoothly. This is good if you have a variable timestep in your game as the delta time will remain more consistent. I don't have a variable timestep anymore but a fixed one (http://gafferongames.com/game-physics/fix-your-timestep/).. but this is still useful as my game is multiplayer and the 33ms gap screws up the synchronization between the server and client. Occassionally the user inputs would be sent 16.67ms later than they were meant to, and as a result JUST miss out on the next tick on the server, etc.. this should fix that.

And who knows, if it IS a bug in the GLFW swap buffer code, then this should get around that too :D

Share this post


Link to post
Share on other sites
Is your driver doing triple buffering? In that case you can fill up two buffers in a row until a v-sync actually limits your speed.
Note that (from an application standpoint) you can not prevent the driver from doing triple buffering.

Share this post


Link to post
Share on other sites
I meant to say that I AM using GLFW and that Glfw is unlikely to be the cause as it has been tested by a LOT of users and this bug seems to be rare.

However, the problem only occured in windowed mode, not fullscreen. My solution was, just to deactivate Vsync in debug builds as release build will be fullscreen anyway.

The temporary workaround still exists, though: When Vsync is active, there's an idle loop after glfwSwapBuffers waiting until frame time 16.66 ms is reached and putting the thread to sleep for at least one ms, if there's more than 12 ms to go. It prevents the zero-frames and if the problem is still there, you can even deactivate the drivers Vsync to let yours jump in. You might experience tearing then, but the timing problem will be gone. Just a workaround, though.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!