Quote from the LM P3D forum

 

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-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Tes-11

Beau Hollis
Rendering System Lead - Prepar3D® Team

 

Original thread (page 4): http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=3843.0

 

 

That is terrific news!

 

Sent from my Mobile thing

 

 

It's great to know that they are digging into the old code and fixing it!

It is really gratifying to see the LM team acting as not only a team but I really in-depth knowledgeable and concerned group of guys that want to produce the best product possible!

 

I'm impressed!

 

Thank you guys!!

 

And specifically... thank you Beau Hollis...so much, for understanding how critical and gratifying your updates are. They make us all feel like we have invested in a product with legs.

 

Well done Sir Beau!

 

Chas

Vape on!

Not that I understood a single, solitary thing he was saying, but I'm sure it's all positive stuff that can only be good for everyone.

It is really gratifying to see the LM team acting as not only a team but I really in-depth knowledgeable and concerned group of guys that want to produce the best product possible!

 

I'm impressed!

 

Thank you guys!!

 

And specifically... thank you Beau Hollis...so much, for understanding how critical and gratifying your updates are. They make us all feel like we have invested in a product with legs.

 

Well done Sir Beau!

 

Chas

Vape on!

I second that. I'd also like to add that its great to have the developers explain the challenges they are finding as well as the solutions in a manner that is understandable.

 

I may not ask for a refund afterall.. :rolleyes:

Awesome.. Well at least it tries to sync up. Another "simulator" I used to use had a similar problem depending on frame rates the in game clock and real time would be out of sync. You could have situations where for every two seconds that passed in real time only one and a half would pass in the simulator.

Great news! I wish this could get fixed in FSX too though.

 

 

 

We found a bug hiding deep in the remainder calculation that has been around since at least FSX

Really great news! :Applause:

That explains a lot. I had the impression, 20 locked felt smoother than 48 lockrd...Maybe its justme. Anyway its cool that they dig that deep and try to improof. May help those with SLI too. Thanks to all involved.

Guess my micostuuter posting and beta testing helped. I'll still wait until SP's are released before revisiting. Probably been in the code since FSX came out. I notice DX10 preview exhibiting the same scenerio. Always assumed it was a lack a vsync but seems it's much deeper than that. Good to know

 

 

Not that I understood a single, solitary thing he was saying, but I'm sure it's all positive stuff that can only be good for everyone

 

+1

 

Dave

Just read the post at LM. That is revolutionary. That bugs been around for 8 yrs...at least. Ye old microstutter that everyone attempted to fix with bufferpools, frame fractions, load etc.

Bravo to LM.....we would never in a million years have seen that post if Microsoft was still in charge!!!

 

K

If anyone needed a reason to support LM by purchasing P3D, this should be one of them.