To those who have sent performance info: thank you, but you probably won’t hear for me for a week. I’m up to my eyeballs in reports and it’s going to take a while to get through them.
I finally found the code that allows X-Plane to turn off V-Sync. This should help nVidia users who are having framerate problems.
The basic idea is this:
- X-Plane tells the graphics card to draw a lot of stuff.
- The video card accumulates this “todo” list and works on it while X-Plane runs.
- X-Plane indicates that the entire frame to be seen is done and tells the card to show the results.
- Eventually some time later the card finishes the todo list and then shows it to the user.
V-Sync relates to the question of when this last step happens. When V-Sync (vertical sync) is off, the card shows the results as soon as it is done drawing.
But when V-Sync is on, when the card finishes drawing the world, it then waits until the monitor is done drawing its frame, and then shows the results. Without V-Sync we can have a situation where the top half of the monitor is showing a new frame and the bottom half is showing an old frame. (This is called “tearing”.)
So normally V-Sync is good because it prevents tearing. But the problem with V-Sync is that a frame can only be shown when the monitor refreshes. The video card has to wait until this happens, and this slows our framerate down.
In particular, most users have their monitors set to 60 hz. If X-Plane can only produce frames at 50 hz, the video card will have to further slow the framerate down to30 hz (one x-plane frame for every two monitor refreshes). If X-Plane falls below 30 hz, we end up with 20 hz (one X-Plane frame for three monitor refreshes), and if X-Plane goes below 20 hz, we would clamp at 15.
So when monitor refresh is on, there can be large framerate hits for small losses of performance in the sim, and a real risk of getting locked around 20 fps.
(The minimum framerate in X-Plane is intentionally set to 19 so that we won’t fog up if the video card clamps us at 20 fps.)
So when beta 11 comes out, you may get some framerate back if you haven’t already hacked your graphics card’s control panel settings. If you still want v-sync, you can always set it this way in the control panel. But most users I’ve talked to are happy to have it off.
In an only vaguely related note, one of the reasons to have high frame rate is to have a smooth flight model. But Austin has now put a new setting in the operations-and-warnings dialog box: you can pick how many times per graphics frame the physics run. The normal ratio is 1:1, but for fighter and acrobatic pilots, you might find that you can get a nice feel at lower fps (20-30) by setting a higher ratio.
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
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.
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”.