Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualHodgman

Posted 04 April 2013 - 08:56 PM

That fraps article was interesting reading, but using fraps to capture all the images that come out of the app is still valid, which lets you spot some stuttering issues (like my duplicate frames problem).
At my last job, we used external HDMI capture and high speed video of a CRT to help diagnose other timing issues as well.

With regards to predicting future timing, you can't *in general*.
If you're vsync'ing, and you're always under your frame-time budget, then you can... But if you start missing vsync intervals, your timing won't be perfect around those points in time. E.g you might have advanced the simulation 16.6ms, but displayed that image 33.3ms later, so the animation will be 16.6ms back in time from where it should be.
Also, whether your CPU or GPU (or both) is over it's frame time budget makes a big difference as to whether stuttering can be absorbed by buffering.

On the last console game that I shipped, we sync'ed to a 30Hz refresh, but in some scenes it was possible for us to miss that window. If a frame was late, we'd temporarily disable vsync (and get tearing at ~30-20Hz) while also reducing the internal rendering resolution in the hopes of getting GPU frame time back down to 33ms... So sometimes it would be possible for us to get perfect timing, but other times we had all the issues of a variable frame rate game :(

#2Hodgman

Posted 04 April 2013 - 08:53 PM

That fraps article was interesting reading, but using fraps to capture all the images that come out of the app is still valid, which lets you spot some stuttering issues (like my duplicate frames problem).
At my last job, we used external HDMI capture and high speed video of a CRT to help diagnose other timing issues as well.

With regards to predicting future timing, you can't *in general*.
If you're vsync'ing, and you're always under your frame-time budget, then you can... But if you start missing vsync intervals, your timing won't be perfect around those points in time. E.g you might have advanced the simulation 16.6ms, but displayed that image 33.3ms later, so the animation will be 16.6ms back in time from where it should be.

On the last console game that I shipped, we sync'ed to a 30Hz refresh, but in some scenes it was possible for us to miss that window. If a frame was late, we'd temporarily disable vsync (and get tearing at ~30-20Hz) while also reducing the internal rendering resolution in the hopes of getting GPU frame time back down to 33ms... So sometimes it would be possible for us to get perfect timing, but other times we had all the issues of a variable frame rate game :(

#1Hodgman

Posted 04 April 2013 - 08:51 PM

That traps article was interesting reading, but using traps to capture all the images that come out of the app is still valid, which lets you spot some stuttering issues (like my duplicate frames problem).
At my last job, we also used external HDMI capture and high speed video of a CRT to help diagnose issues as well.

With regards to predicting future timing, you can't *in general*.
If you're vsync'ing, and you're always under your frame-time budget, then you can... But if you start missing vsync intervals, your timing won't be perfect around those points in time. E.g you might have advanced the simulation 16.6ms, but displayed that image 33.3ms later, so the animation will be 16.6ms back in time from where it should be.

On the last console game that I shipped, we sync'ed to a 30Hz refresh, but in some scenes it was possible for us to miss that window. If a frame was late, we'd temporarily disable vsync (and get tearing at ~30-20Hz) while also reducing the internal rendering resolution in the hopes of getting GPU frame time back down to 33ms... So sometimes it would be possible for us to get perfect timing, but other times we had all the issues of a variable frame rate game :(

PARTNERS