Comments on: V-Sync – Problematic in Practice

By: Murmur

Murmur — Sat, 15 Dec 2007 16:49:00 +0000

A good workaround would be to have a frame rate limiter allowing us users to set a MAX fps.

For example, setting it at say 40, would give steady 40 fps as long as the PC is able to sim&draw; at >=40 fps. It's certainly better than having "gummy" and stutterous fps travelling between, say, 90 and 40.

The new "flight model per fps" variable blends _perfectly_ with this concept, since it would allow to set a realistic "low" fps (e.g. 40 fps) and still retain a high flight model frequency.

Talked about this to Austin, he concluded it was a potentially good idea but would cause non expert users to set too low fps and then complain... But I saw several X-Plane users complaining about its "gumminess".

By: Benjamin Supnik

Benjamin Supnik — Sat, 15 Dec 2007 12:04:00 +0000

I'm not sure that there's a lot we can do. Consider this:
- We have to commit to how much time has advanced in the sim BEFORE we start the drawing process, e.g. we update the airplane's position, then start to re-emit the frame geometry.
- We cannot predict how long that frame will take...because the plane (and camera have moved) they may expose a different part of the scene graph, causing us to take longer or shorter.

Thus when we flip the frame, there is always the risk that the amount of time simulated and the amount of time elapsed will be different.

This is worst when the card is heavily overloaded and you're having glitching or stuttering due to too much traffic over the PCIe bus.

(I think what we would need would be a non-refresh deadline-based rendering API, that is, the ability to tell OpenGL, "draw this frame at this time, tell me if you're not fast enough". This also requires triple (or more) buffering to keep from under-running all the time - this is basicaly how professional video systems are engineered to maintain a locked 29.97 fps. If there is a driver API to do scheduled framebuffer swap, someone send me a link!

For vsync, or any timer changes, please discuss this with Austin directly ... the above is just my opinion.

By: Robert

Robert — Sat, 15 Dec 2007 11:26:00 +0000

Since beta_11 for me it is impossible to force Vsync to "always on" in the Geforce-driver. There is only the option "automatic on" but it doesn't
force the driver to use Vsync.

Before beta_11 I was flying with Vsync + TRIPLE-BUFFERING which gives you VERY SMOOTH and high framerates.
With triple-buffering you don't have to go from 60 fps to 30. But you get framerates inbetween.

The main problem of x-plane is the TIMER! (the time_ratio variable)
You get this "UNREGULAR STUTTERING" when this variable changes a lot.
Most games use another approach to timing games. They use a high-frequency-timer ("QueryHighPerformanceTimer" on Windows). They measure the elapsed time between two frames and multiply this elapsed time to all transformations, rotations, (and scaling).
I e-mailed Austin a few months ago. He wanted to implment this timer in the "next release" but maybe he forgot.

My System: Vista/NVIDIA