Microstutter FBW

Stable, dev and exp, same problem

Any of you have tried running with only the aircraft in the Community folder?

This includes unrelated addons and liveries.

Remember that the problem is observed only with the FBW.

To elaborate a bit further on how our optimisation has been going on;

As time goes on we inevitably add a ton of features to the plane. Those features often have a lot of complexity, and while most of the time they do not incur a performance impact, there is an aspect of the development of our aircraft that affects performance very much: legacy code.

In MSFS, aircraft can carry code in two worlds: JavaScript and WASM. While those two are tightly integrrated on the browser, in MSFS WASM is used differently - itā€™s the only way to run native code in your addon without resorting to external solutions. Native code, as opposed to interpreted code, can be much faster, up to orders of magnitude - but the reality is a bit more complicated than that. In MSFS the JavaScript code is executed in another thread, in parallel to the main thread. WASM on the other hand always runs on the main thread. This means that the performance difference between JS and native code isnā€™t necessarily the only part of optimisation you have to care about.

The aircraft as everyone knows started its life as a mod of the default A320. That plane only used JS for its avionics and FMS, and relegated the system simulation to the simā€™s integrated systems.

The A32NX nowadays is a far cry from that. Two main things have happened that are of interest to us:


First: All displays have been rewritten from the ground up (except the MCDU display layer) using the React JS library. It was assumed initially that most of the performance loss associated with the displays was due to excessive rendering. This turned out to be partially wrong as React turned out to stress the engineā€™s garbage collector (a little program that reclaims unused memory - something that you have to manually do in native code) to a point where very long frametimes would be common - causing a stutter. If every frame for the past 10 seconds lasts 5ms, and the next one lasts 25ms, you will feel a stutter on your screen. Since garbage collection runs periodically, this was a big issue.

Later, Working Title came out with the MSFS Avionics Framework, an alternative approach to React which is optimized to not stress the parts of the engine that React is famous for slowing down.

We took notice and started by porting our PFD (primary flight display) to this framework with good results.

We do plan to port more displays to this framework, however, it is a lot of work as our displays are rather complex, and when rewrites are done we try to avoid other rewrites by correcting mistakes we did initially. Over the past few months I have been porting the ND (navigation display) to the same framework and have been seeing good results - however the work has also involved porting a lot of ā€œsimplifiedā€ avionics logic to be more true to life using the ARINC429 protocol, and reworking the ND map rendering to be more accurate to the real plane. I hope to start previewing this in experimental sooner rather than later.


Second: we have introduced a host of systems based on the WASM format instead of JS. The first addition using WASM was the custom FBW and autopilot systems, which were a multi-year endeavor to develop an extremely accurate fly-by-wire and autopilot system in a completely new platform - we were in fact the first third-party developer to introduce a custom AP in MSFS, as far as I know.

This has continued on with the advent of our Rust-based systems simulation module, providing realtime physical simulation of the electrical, hydraulic and air conditioning systems of the aircraft.

Those systems run really fast - in fact we have not really ever worried too much about their performance since Rust is a language with good performance characteristics, and MSFS converts WASM modules to native CPU machine code before starting the plane to not have overhead (this is why the plane takes a long time to load after an update).

And the good news here is - we are porting systems that currently reside in JS to the WASM modules - an example of this being the FWC (Flight Warning Computer), which is going to gradually be removed from the JS world and entirely ported to the WASM side, except for a thin display layer to interact with the JS displays. This reduces the amount of JS code to run, reduces the length of GC pauses, and leaves more space for the avionics code to run without causing a stutter.


In conclusion - we care very much about performance, and we really want this aircraft to be one of the smoothest and highest FPS we can bring it to. Itā€™s just a really complicated process to do, and normally not something that is done during the Alpha stage of development (which we are in).

8 Likes

Iā€™m aware, this has been specified. Iā€™m not asking those questions because I want to shift the blame - but software is complex, conflicts do happen, and we need to eliminate possible causes.

2 Likes

Hi there, just wanted to let people in this thread know that I have tried the FBW A320 with SU10 and the micro-stutters are still there, whereas the Asobo A320 runs very smoothly with the same settings and circumstances. My base configuration is DX11, DLSS Quality, Mostly High settings and a couple of Medium and Ultra, and FPS capped at 30. All other aircraft are very smooth when taxiing, the FBW A320 still stutters irregularly and for brief moments. I tried it without any other add-ons and with the lowest settings possible, ie LOW option and LOD at 10 and the stutters persist so I think it cant be my hardware (RTX 2060, i7-9700F, 32Gb, 100Mbps). Such a pity to not be able to enjoy it fully ā€¦

2 Likes

The problem is fbw, FENIX AND PMDG ARE OKAY!

Same here, A320x FBW need to be fixed. Worse performance in SU10

something broke with the FWB after SU10-beta #2/3 ā€“ was ultra smooth DX12/11 and then something changed

Note: DX12 is not supported at all in the A32NX, so it shouldnā€™t be used for testing this.

Can any of you provide screenshots of the MSFS FPS counter whenever this happens? A bit difficult to know whatā€™s going on otherwise.

1 Like

I think it would be more beneficial for you with short videos as opposed to screenshots, hence the micro-stutters happen so randomly and so briefly to the point where i donā€™t think a screenshot can capture the moment it happens.

Unfortunately i cannot do that hence i uninstalled the A32NX because of this same issueā€¦but i encourage everyone who participated in this thread to help you with your testing.

I will be sending relevant screenshots later today (just woke up now itā€™s 0723 here). My stutters definitely happen while taxiing at the moment the ECAM display changes to show what is armed and what needs to be set before take-off (calls etc) and perhaps also at the moment - usually earlier - the alignment happens and the course comes out on the ND, but these are not the only instances. The pics I will post in a while weā€™re in fact taken before the two events took place.

Here are the screenshots, same instance of the stutter. The drop is from 30 (cap through the Vsync option in-game ; 60Hz, 50%)
fps_stutter_1
fps_stutter_2

Thanks for the tests.

The upcoming rewritten ND should significantly improve things. I also plan to re-do the EWD (upper ECAM) at some point as well.

I donā€™t know yet when weā€™ll be ready to have the new ND in testing, because there are some features missing like ROSE LS mode, ADF pointers and TERR. But itā€™s getting closer.

Those spikes are generally caused by what we call a GC pause, which is, in simple terms, the engine running the code having to stop and discard unused things generated while the code was running. You can kind of compare it to a traffic slowdown caused by a garbage truck picking up bins :smile:

The goal with those rewrites is to avoid generating this garbage in the first place, reducing the duration and amount of those stops to a minimum. Past some point, it is able to do it without any slowdown (stutter) at all.

4 Likes

This would be great. In case you need more tests as you progress please let me know. It is going to make me very happy if I can taxi this great thing you guys have built without these annoying mini freezes. Cheers.

1 Like

Hello, I did a test this morning (Dev version / DX11 TAA / cpu 5800x3D / gpu : 3080 ti) : I have from time to time sutters with the A32nx. Then I used the A320neo from Asobo and I donā€™t encounter any sutter.

Hi, yes this is the same with me. I hope it is fixed as per holland786s most helpful replies above.
After installing the new NVIDIA Game Ready Driver, my DX12 works maybe better than DX11 so I am going to try the FBW A320 in that scenario as well (so far I had been using only DX11).

After the latest updates Experimental version (sept 28th and 29th) the stutters disappears. Smooth as butter as PMDG
Good job.
Thankyou FBW

2 Likes

Iā€™m inclined to try the experimental version as well =)
now on dev model.

Fbw is the problem. With fenix and pmdg 0 problems