[BUG] Systems affected by screen refresh rate (deltaTime)

[adenflorian]

Master tracking issue for things that get broken by FPS mods. Checked items have been identified and fixed.

• [ ] Self test takes longer than it should
• [ ] un-aligned PFD messages flash slower than they should
• [ ] Mode Change on ND is slow
• [ ] Brake Temp decay (Wheel Page) (will be fixed by a32nxcore changeS)

[UncleClapton]

I'm just going to write down some possible approaches to avoid the conflicts. IMO all of these are valid approaches, but no single approach should be used everywhere.

Calculate a "local" deltaTime

Since the fps mods just make the update loop run every "x" frame, we could calculate our own delta time where we need it so the time between updates is correct. Good for stuff like ECAM pages and smaller logic functions.

Use requestAnimationFrame() directly

We could just not hook into the main update loop and use our own. This would be viable for anything within the "core" files, but really shouldn't be used elsewhere.

Don't use update loop based timing at all

The game contains various time simvars we could look at to detect the passage of time. This is really only appropriate for stuff that is based off of in-game time to begin with (such as the chronometer).

[UncleClapton]

UPDATE 2020-09-18

The game has changed! (literally)

In the latest patch, Asobo implemented variable screen refresh rate. They achieve this the same way the original FPS mods did by forcing updates every X frame. Here's what we currently know about this change:

1. Screen refresh rate can now be controlled by the user, but the calculation of deltaTime has not been changed to account for this. Funny enough this could have been fixed by a single line change in the update loop code.
2. The screen refresh setting affects the update loop as follows (Thanks for testing and confirming this @2hwk)
   • High = updates every frame.
   • Medium = updates (frameCount % 2) === 0.
   • Low = updates (frameCount % 4) === 0.
3. To account for problems with the CDU and FCU, Asobo introduced an AlwaysUpdate flag (seen here), which forces the refresh rate to Quality.high for that instrument. Funny enough Quality.high is not the same High as stated above. Quality.high is the same as refresh rate medium. It's unclear if this is intentional.

Whats next?

a32nxcore files should probably be moved. Perhaps attach it to the CDU? Even after we move the core files we will want to make them keep their own time in a similar way the AP code in the CDU does. This will be easy for the core files since we can just modify the core class to calculate the delta for each module. Things that use deltaTime within the other instruments, though, is another problem. We will have to update all of those instances individually. I'm not sure what approach is best for each of those cases, though.

Other Notes

• For those following along at home... High, Medium, and Low in the game settings actually correspond to ultra, high, and medium in the BaseInsturment code. Yay for confusing things.

[shreyasmiraj]

Considering there isn't much in the a32nx core anyway, I suggest that people stop implementing core logic into js.(low key been doing so from the start xD)

The apu code is already redone under elec wasm and will be shifted to engines shortly. So I think I'll send in a PR with the wasm src files( can have a look here ) and let the ones who did the implementation redo it as a wasm system or I'll do so after finishing elec circuit mapping.