That might be true. C++ is used because there is existing code for the planes we will see in the near future and the developers already know it.
But i guess also because the code is not compiled and would be easy to just copy the plain JS code.
We will see in the future and im looking forward what you can do with it in terms of optimisation, i hope a lot.
But right now, its not fun to use all this advanced G3000 and the FBWA320 for me personally, because the performance is subpar. Even with a decent system and very optimised settings.
Also, i GUESS (not sure on this one) that WASM is not accesible plain code so its not so easy to just copy the custom code. That might be another reason that payware-developers will not use JS/HTML. But if im wrong on that, feel free to correct me.
Exactly. Itsthe heavy CPU usage that is causing this stutters, no matter if one locks FPS.
As long as we are mostly bound to only using one single CPU core, theres no way around, unless the code of the systems get optimised, as Matt mentioned, or ASOBO can make better use out of multicore CPUs.
Note that WebAssembly can be easily disassembled, reassembled, have code added to it, etc using developer tools. You won’t get back the original C++ code but if you really wanted to do some hacks on something it would be possible. And it would be trivially easy to just lift an entire module.
WebAssembly does not provide any kind of copy protection, and it was never meant to.
Im not really talking about copy protection to avoid piracy. Im more talking about the custom code that could easily be copied from other developers. But with WASM this wouldnt be possible. Atleast not just with copy/paste, if at all.
In one of the last dev Q&As they mentioned they’re moving the JS execution for the glass cockpits to a separate thread in order to reduce the load from the main thread. This will very likely get rid of most of the stutters specific to the airliners and for aircraft using the WorkingTitle G1000/G3000 mods.