FPS The Neverending Story!

There’s lots of discussion about better multi-core support being possible after DX12, so I think that will help 3rd party addons. I think the heaviest ones are airliners like PMDG, etc with their more complex systems. Even 3rd party GPS like Flight1 or RealityXP weren’t very heavy in P3D because they communicated with the Garmin GPS training software which ran in a different process. :small_airplane: :smiley_cat:

1 Like

Yeah, I agree with you. Sadly We do not have a stable game yet to really tell how much 3rd party sceneries can push the limits. I believe right now this discussion is like putting a transatlantic ship on a swamp, you can’t tell how good the ship can perform. Just a clarification, MSFS is the swamp lol :smiley: cheers mate

1 Like

The PMDG thing, did you noticed how BAD the game performs with the glass cockpits? add that on top of the complex computations involved in a PMDG quality plane. :frowning: this is going to be bad brother

1 Like

MSFS glass? Yeah I turned the refresh for them down to medium and its nicer. So definitely room for improvement! :small_airplane: :smiley_cat:

Yes I have been experimenting with different graphics settings such as glass cockpit. I agree with you regarding PMDG due to system complexity , we have to wait and see once it’s launched . that is why
I am only addressing the scenery part.

1 Like

I thank you for mentioning this. It is partly true though and I’d just throw my 2 cents here:

It is recurrent an assumption in the community, complex aircraft are taking more resources because of the complexity of the systems simulation. I agree it could be the case if such systems simulation is badly coded or if they are using data structure and memory access in such a way it is taxing the CPU more than necessary and more than could be achieved.

What is really paramount to performance with 3rd party aircraft add-ons is first and foremost the graphics path. This is were 80% of your frame budget is spent if you carefully develop the systems simulation with high optimization techniques in mind.

The other performance problem with most 3rd party add-ons is the intricacies of the SDK from within. What I mean by this is what is the simulator doing internally with all the SDK structures 3rd party gauges are using, and how could 3rd party code be implemented so that it can maximize the throughput, minimize latency and effectively don’t do the same thing twice.

The later is very dependent on the SDK bugs as well and I’ll give you a practical example if you’re a little bit knowledgeable with the FSX SDK. This is bug dating back to FS9 at least and is still present in P3D5 (although partly depending on some conditions). Here is:

  1. The SDK is notifying gauges when it is their time slice to update. Usually gauges do their calculations upon such notification (PANEL_SERVICE_PRE_UPDATE)

  2. The SDK is notifying gauges when it is their time slice to display. Usually gauges draw themselves in a buffer which the simulator will later display on screen (PANEL_SERVICE_PRE_DRAW)

  3. Now make a basic gauge, jump in the aircraft in the 2D panel (remember this is from FSX), switch to virtual cockpit, then jump back to 2D panel. Your gauge will now receive double of some of these notifications…

Which begs some questions:

  • How many know about this and why it is doing it? (there is a valid reason if you put your shoes in the SDK side).
  • How many gauges are developed in such a way they won’t do the same thing twice, therefore, they won’t take unnecessary processing and unnecessary FPS?
  • is Asobo aware of this and aware of how some 3rd party developers are falling in this SDK trap, so that they don’t let this happen again or document it clearly?

I can assure you the Reality XP GNS and the Reality XP GTN are not having any significant impact to the FPS not because they are running an external program but because these products are implementing highly efficient inter-process communication system between the simulator and the trainers and because they are also re-coding the trainers live in memory so that they use the minimum resources necessary (compare the trainer memory working set running standalone and running with Reality XP for example).

But a significant reason of the Reality XP implementation performance is also because the part of the product which is running in the simulator space, the gauge, is designed with best practices and best intimate knowledge of the simulator internals and its SDK, thanks to nearly 20 years of expertise! Which in addition to performance gives you capabilities beyond the limitations of the SDK such as 32 bits high-definition graphics (even in FS9) which is not otherwise possible as-is. The Reality XP gauges are not even using any graphics hack but plain old FS SDK basic feature set for this, only they are exploiting what is already there but hidden in plain sight.

Having said this, most 3rd party vendors I know of are doing a great job and are very knowledgeable, but you have to also understand most 3rd party vendors can’t go beyond the boundaries set forth by the SDK. Most FSX area products having poor performances were most often suffering from having to use the XML gauge system for both the logic and the drawing parts. This is a neat approach for the simulator in the sense it is lowering the entry level for producing gauges for example, compared to C++, but it is also not the most effective way and every gauge using it is suffering from the tradeoff between convenience and performance.

Fast forward to FS2020 and the Javascript gauge ecosystem and the thousands of messages about how this is taking so much FPS and the dozens of discussions with a fix trying to make it a better experience. In this case it is true the JS gauge ecosystem is much better than the XML gauge ecosystem of the past and Asobo has expressed a strong desire to make this, in addition to the WASM ecosystem, performant enough.

This is no better with X-Plane. There is for example SASL which is a very good framework and which is offering the same lower level entry to plugin development on X-Plane as the XML ecosystem did for FSX. However whenever you’re using an aircraft which plugin is using SASL you can really feel a performance hit compared to another aircraft using C++ plugin (these are rare nowadays). The hit is even more pronounced in VR where it can make a perfectly capable computer running way above standard in 2D performing poorly in VR just because of the SASL layer and the way 3rd party plugins are using it. It is even easier to spot with XP11.50 which is now offering a new Plugin Admin tool with per-plugin performance in micro seconds and relative FPS hit.

But I digress and back to your comment, the most dramatic impact on FPS is a sound and low level SDK with direct access and control to the simulator internals, along with a very fast graphics path. P3D4 and 5 have these low level paths via the PDK, XP11 has always had it too natively, and we’re yet to know if we’ll get the same with FS2020 in the end. Maybe we won’t need any in the end?


Amazing details and analysis !!. It will take me some time to understand all that. :disappointed_relieved: :smile: So we need a better more advanced SDK & Gauges. Osobo please, roll up your sleeves and make MSFS2020 break the FPS sound barrier into the future. :rocket:

1 Like

i don’t have it, with my old cpu.
you just need to give more volt to cpu and you will have no more stutter

That is false and dangerous; someone could end up literally frying their CPU! :fire: :small_airplane: :smiley_cat:

i had low voltage and stutter, with 0.3 more stutter is gone.

Hey @Artax04 - I agree with @anon67824105. Suggest you edit your post to add a disclaimer that this is not to be done unless the user understand overclocking. Done irresponsibly could ruin a CPU. Thanks.

1 Like

ofc im talking about overclocking

overclock is necessary for this game, expetially with old cpu!
i got 12 - 15 fps boost from stock speed to 4,9 ghz

Overclocking is really an expert-level thing that people shouldn’t just jump into, especially with “just add volts”. :small_airplane: :smiley_cat:

1 Like

overclock it’s easy… we are in 2020 with tons of guide
and cpu got tons of safety, it’s really hard to blow a cpu

yesterday night i tried 5ghz, i had to put 1.5 LOOOL
after the delid barely reached 90c

ofc i did only for one flight, but was stable.

now i’m at 4,9 at 1,45 ( i know still high voltage, but i need to change pc so who cares XD)

This cpu is turned on by about 6 years, at 4,7 at 1,37
and it still rocks, OC is safe

Thank you for your kind words!

The FS2020 SDK is very limited at this time, and we’re yet to know which final direction it will take. However what is certain is that Asobo and Microsoft have chosen to lock down 3rd party add-ons developments in imposing a sandbox technology: WASM.

For those of you not knowing what this is, it is a technology which permits running “almost” native applications in a web page. In short, it is a virtual CPU running a virtual language which resemble machine code. This works in converting the compiled C++ code into bytes representing very low level operations and operands (like multiply a with 5, store result in b etc…). The web page side of it basically interprets and execute each of these sequentially.

However WASM is only as good as what they’ll allow running with it. If for example they don’t implement any “file” access function, gauges won’t be able to access any file. If they don’t implement any “threading” support, gauges will run on 1 thread as if running on a single CPU, etc…

It is clear to me this choice is not driven solely by technology. I understand the advantage of WASM is to virtualize the gauges so that whatever the real processor running the simulator, be it x86 today in PC, x86 or ARM in consoles tomorrow, the gauges will still run. But I’ve also listen to a podcast lately where they were expressing being circumspect of one danger of compiled C++ code running in FS2020: virus.

Its true technically but I must say FSX, P3D and XPlane are all allowing 3rd party C++ code running in their process space, and I’ve never seen any wild spread infection report in the community from 3rd party vendors or freeware products.

It is definitely hard to qualify “a better more advanced SDK & Gauges” but I believe there are different approaches which might complement each other:

  • The existing WASM+JS sandboxed environment which is fantastic because it is lowering the entry level for developers and is compatible with both the PC and the XBox.
  • Less restricted WASM+JS sandbox for 3rd party developers passing a certain “scrutiny” process eventually, or…
  • A low level C++ SDK with direct access to the simulator core internal components, which is allowing 3rd party code to also override internal simulation behavior and simulation data, which is available only on PC.

Having said this I wish they also look at what is working best in other simulators and loosen some of the FSX legacy heritage which is still very pregnant in FS2020, like this one I’ve commented on lately (a bug known since 2004):

As for the FPS, stutters and overclocking question, maybe this could help some of you:

Thank you !!
Now that is kind of Knowledge I am seeking!!.
It removed lots of mysteries and crave for knowing that it can be done, but for some reasons they have decided to restrict it !! :thinking: