I have about 1000 hours into MSFS2024 and am a mod for a streamer that has streamed many hours more.
The gamer perception of this implementation is NOT positive. It crashes all the time, has massive performance issues, and generally is super negatively received.
Is there evidence to support that it's the WASM Mod format that's the issue? Based on that page it's not like MSFS2024 is even running WASM, it's simply using WASM as an IL that is precompiled into a DLL on application startup.
My experience is now a few years old, but WASM binary we had ran less than 10% slower than C++ Clang compiled native binary from the same source. And that was for rendering code which is rather CPU intensive and benefits from optimisation.
I wonder if they made the same silly mistake I did and just used the 'runtime/engine name' as title of their crash report window. E.g. all games that were based on the Nebula3 engine displayed smth like "Nebula3 Assertion" in the popup window which is opened when an assert is hit or on a general crash.
It didn't take long after release that every crash in the game was because of that damn "Nebula3 Engine!?!!1", even though almost none of those crashes happened down in the engine code, but somewhere up in the game logic :)
In any case, opening up a game for modding means the game needs to be prepared for a flood of poorly written and optimized mods, no matter whether the mods are scripted via a scripting language like Lua, compiled to WASM or native code. At least (unlike directly loading native DLLs), WASM gives you all the tools to catch errors without crashing the entire game process. The tricky part is to design the plugin runtime system in a way that such errors are easily recoverable without having to restart the whole flight-sim session.
As far as I've seen, it's generally just the WASM modules that crash, and not a full sim crash to desktop (CTD). But considering the WASM modules are usually running all of the aircraft logic, systems, flight control computers, etc. then it tends to mean a complete flight loss since you can't... well... control the aircraft anymore. I'm not sure what kind of automatic restart logic exists for crashed WASM modules, if anything. It would be interesting to see if module crash recovery is possible.
Unless you want realistic scenery or an up to date g1000 implementation (I love X-Plane really but because of these two points I keep going back to MSFS - maybe there are some add-ons I haven’t tried?)
When did you last try it? The scenery and GPS/FMC has come a long way in the last 20 years I've been an X-Plane casual, but not so sure how much of that was in the last few.
I’m comparing X-Plane 12 to MSFS 24. MSFS 24 is a great aid and near picture perfect when preflying real world routes, with 3D buildings and everything, and the latest G1000 implementation is pretty complete too. But X-Plane still wins on physics realism and systems fidelity. I’d be happy if there was a way to combine the strengths of the two in one simulator somehow..
I don’t know much about MSFS plugin system so I don’t know if this is possible but you can easily extract data from X-Plane and then send over to MSFS. So that you use XP as physic and model engine, only MSFS as out-the-window view.
Basic things like latitude/longitude/altitude/heading should be straightforward. But then you might have problems with mismatch scenery, like missing airports/runway, different terrain heights, etc. And then the weather synchronization is another can of worms. Matching what you see with the physic model can be challenging.
Yeah ... by now 2020 reached a beta quality, still plenty of bugs left to squash but most of them are minor. 2024 on the other side ... is just transitioning from tech demo to alpha quality. It needs a few more years to reach beta and then by 2035 or so it might actually become a reliable product.
For me most of the performance issues with MSFS24 are now being VRAM limited. When they went to MSFS 2024 they rewrote for DX12 and while doing that upgraded a few things to look nicer. The texture management still seems to need some work.
This means that my 9800x3D/3080Ti 12GB sort of runs out of VRAM and pages when used in VR or 4K desktop. I'm in the position where the same visuals (scenery/aircraft etc) for MSFS2020 (using DX11) when compared to the newer MSFS2024 is just generally worse and a lower framerate. In VR a bad framerate makes things unplayable. For desktop use you have DLSS which helps a lot, but in VR that blurry movement really impacts clarity.
DLSS also blurs the cockpit displays quite badly when there's anything moving on them (airspeed/altitude tape, etc.). It looks like temporal blur, which is interesting because the same blur doesn't happen with their TAA (*temporal* anti-aliasing) implementation.
Yeah, DLSS looks great outside the window and for people enjoying GA and VFR it's all good. For airliners with digital displays it is harder to use, as like you said it blurs. They did talk about using some form of stencil/exclusion around cockpit displays but I think that didn't go anywhere as yet.
As a team they have a pretty tough job because the audience is all of the place for a title like that, as in people with 'I can see my house!' being made happy vs 'My pressurization gauge cross-bleed reading is below the Boeing B738 manual official figure, unplayable'.
That describes what I've seen. When I first compared 2020 and 2024 in as apples-to-apples a way as I could, it seemed like 2024's frame rate was about a third lower than 2020's. This was on a 7900 XTX with 24 gigs of VRAM.
I dunno, those look quite realistic and even a good thing for a plugin system that needs to run in a sandbox:
- The Windows API is not supported => would be a security nightmare if allowed
- C++ exceptions are not supported => not surprising, game code usually forbids exceptions anyway, along with RTTI
- C++ threads are not supported => really shouldn't be needed in a plugin system,
- The GDI+ wrapper is very incomplete => surprising that they even attempt to wrap GDI+
- The WebAssembly module must be compiled in Debug mode for C/C++ code for symbols to be visible while debugging => need to compile in debug mode in order to debug, doh.
In a "memory safe" programming language you would get a panic for an attempted out-of-range access. For the user it doesn't make a difference, it's a "crash" all the same.
The gamer perception of this implementation is NOT positive. It crashes all the time, has massive performance issues, and generally is super negatively received.