I know a lot of you may have already seen this but this is a milestone in the history of Microsoft Flight Simulator now morphed into what we now know as Prepar3d. What an interesting read. I keep re reading it to try and have it make sense...i'm still re reading it, lol.
Quote from Rendering System Lead at Lockheed Martin on the Prepar3d team
"We have some good news to report. The rendering and physics developers got our heads together to brainstorm some ways to work on getting the simulation time and frame time to synchronize better. Some visual stutters can occur even when the FPS is fairly consistent if the physics simulation is out of synchronization. The user aircraft is allowed to update anywhere between 90-120 FPS (same was true in v1/FSX). If the fame time is longer than than the max, multiple iterations are needed and the system tries to find a value in the min/max range to avoid having remaining time that rolls over to the next visual frame. Your best bet is to keep frame-rates in one of the sweet spots where the math works out:
1. 120-90 FPS (8.333-11.111 ms) simulation and visual time delta is the same. no issues.
2. 60-45 FPS (16.66-22.222 ms) 2 steps at half the frame time will work out with no remainder
3. 40-30 FPS (25-33.333 ms) 3 steps works out with no remainder
4. 30-0 These should be fine
40-45, and 60-90 are problem ranges.
We found a bug hiding deep in the remainder calculation that has been around since at least FSX which ends up picking the worst case remainder instead of the best. This adds 5.7 ms of variance in simulation steps between frames in the 60-90 range and 11.4 in the 40-45. So if you're locked at 42fps, the simulation is jumping back and forth between roughly 30 and 60 fps.
I also noticed just tonight that our simulation timer steps at the beginning of the application frame but the flip/present call happens after file IO and simulation work is done. Thus while your actual frame time may be locked the simulation time may vary depending on the percentage of the frame spent doing file IO and simulation work.
I'm guessing these two issues combined where the variance caused by the mid-frame v-sync occasionally pushed the locked 30hz up into the 40-45 range where that bug caused one simulation frame to simulate at 60hz before things normalized.
Things seem much smoother with the rounding bug fixed. We haven't tried moving the timer or flip yet but will try this out soon and compare internal frame timing against fraps before and after. Once we have some conclusive results, we will let everyone know.
Also, just a side note. Using vsync when your system can't achieve the frame-rate consistently will cause large variations in the actual frame times because it will be clamped to one of the sync intervals 15, 20, 30, or 60. This article has more information on how vsync can help or hurt you with regards to stutters in games/sims, which explains why the half v-sync helps.http://www.pcper.com/reviews/Graphics-Card...formance-Tes-11
Rendering System Lead - Prepar3DÂ® Team"