This is great news for WASM, and looks like the Microsoft team really put in a lot of effort!
> In order to [move the addons API to WASM] without requiring a full rewrite of existing add-ons, a new platform toolset was designed for Visual Studio (...)
Because this idea has been done multiple times throughout the years with different kinds of bytecodes and VMs, since UNCOL in 1958, the WebAssembly folks just pretend they are always the first at something.
I feel like everyone is trying to do things in the most inefficient way possible and it is starting to make me a little bit batty.
WASM is awesome, but if I'm reading this right, they're choosing not to write DLLs so that they can create WASM modules which are recompiled into DLLs prior to runtime.
I think our entire industry has taken banned-by-the-Geneva-Conventions, weapons-grade Stupid Pills.
The only reason I can think of to do this, is so that you can't have arbitrarily malevolent code running in the DLLs that mod authors write. But we can't run the whole game in a sandbox such as a VM because of Nvidia GPU licensing disallowing virtual GPUs in consumer grade GPUs.
If that's why this work is being done, some serious muscle needs to be used to twist Nvidias arm so that they stop being knobheads and start being part of the solution to security issues, instead of part of the problem.
If I pay for that GPU, I should be able to issue work to it however I please. I should be able to split it up among VMs all day long without concern for anything Nvidia wants.
WASM provides a secure sandbox with predictable performance across platforms while giving Microsoft the ability to maintain compatibility if they port to Xbox, cloud, or other platforms without requiring developers to recompile their add-ons.
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.
I dunno, I think I would've preferred Lua bytecode as a deliverable executable target, rather than WebAssembly. The tooling would be simpler, more efficient, and would allow a far wider ranger of interoperability with other engines.
19 comments
[ 3.0 ms ] story [ 39.0 ms ] thread> In order to [move the addons API to WASM] without requiring a full rewrite of existing add-ons, a new platform toolset was designed for Visual Studio (...)
It could become a competitor for a lot of existing technologies. Some examples:
* embedded script languages (e.g.: Python in Blender and Gimp, Lua in games, VBScript in MS applications).
* add-on modules (e.g. COM on Microsoft platforms or COM-like for non-MS)
* finally, a run-anywhere platform? (what the JVM and .Net always wanted to be)
WASM is awesome, but if I'm reading this right, they're choosing not to write DLLs so that they can create WASM modules which are recompiled into DLLs prior to runtime.
I think our entire industry has taken banned-by-the-Geneva-Conventions, weapons-grade Stupid Pills.
The only reason I can think of to do this, is so that you can't have arbitrarily malevolent code running in the DLLs that mod authors write. But we can't run the whole game in a sandbox such as a VM because of Nvidia GPU licensing disallowing virtual GPUs in consumer grade GPUs.
If that's why this work is being done, some serious muscle needs to be used to twist Nvidias arm so that they stop being knobheads and start being part of the solution to security issues, instead of part of the problem.
If I pay for that GPU, I should be able to issue work to it however I please. I should be able to split it up among VMs all day long without concern for anything Nvidia wants.
Is it for future proofing it in case MS wants to release the game in a different platform that is not windows ?
The gamer perception of this implementation is NOT positive. It crashes all the time, has massive performance issues, and generally is super negatively received.
edit: i might be thinking of this talk? https://www.destroyallsoftware.com/talks/the-birth-and-death...
* some functions like fsRenderCreate return 0 or 1 depending on the operation result;
* some like fsMapViewCreate say that a value less than 0 is returned on error;
* fsIOOpen says you should also consult with the fsIOGetLastError function on failure.
Hope somebody considers adding the errno.
I think there's a good argument for Flight Simulator to be in the top 100.
At any rate with their budget Asobo are underperforming with this thing. 2024 in particular is enshittification 101.