WebAssembly

[Dominique_K 10,133]

As the OP, I found this thread full of insights. Special thanks to Nick, SteveW, Warpd, Oliver and Matthew to bring some useful light on the issue to the non-programmers. Let me remind you though that this is not about the merits of WA in general . In their announcement, Asobo has framed the use of WA to allow the porting of native code to (our) platform.

Interesting if not entertaining when the « usual suspects » who never released any addon for flight simulator or game tell Asobo which is a successful game developer what they should do or not do.

 

 

 

 

Edited March 30, 2020 by domkle

[mSparks 2,086]

2 hours ago, MatthewS said:

Also, if your compiling to WASM there's no underlying speed advantage to C++

The speed difference is night and day.

WASM is run inside a javascript virtual machine (V8/Nashorn/GraalVM/dotnet 5) which has a ton of overhead, as a rule of thumb requiring twice the ram to run at half the speed. The javascript VMs as exist now run on a single thread, so even though you can compile "mutlithreaded" code, it will only ever run on one core, C++ has lots of hardware specific optimisations when compiled which can make use of all the crazy added to CPUs over the last 30 years, WASM does not.

WASM is very likely the future of javascript

https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript

and "as long" as you don't require any kind of performance or time guarantees (such as your code getting paused by the system for seconds at a time) its a good option for deploying software - especially into secure environments.

But:

no filesystem access (e.g. no access to user side Navigraph data without popping up an "open file" dialog everytime, only access to data the author has permission to sell/distribute)

no integration - one plugin can never share data with another plugin

Every library you want to use needs to be bundled into the VM instance, creating huge RAM requirements (and performance consequences for accessing huge amounts of ram) for anything that uses a complex library like the JDK (have to load the entire JDK into RAM)

No system access - e.g. the only graphics you can do is that provided by the VM, in the case of current WASM "WebGL".

54 minutes ago, domkle said:

allow the porting of native code to (our) platform.

This is going to stop at lua scripts, which can just about, maybe, be ported into WASM assuming it doesn't do any drawing, and losing about 95% of the performance of something like SASL.

Edited March 30, 2020 by mSparks

[WarpD 824]

8 hours ago, domkle said:

Let me remind you though that this is not about the merits of WA in general .

You might think that... however, as example.... the Citation X I did for Eaglesoft would not be possible in WASM.

[Dominique_K 10,133]

28 minutes ago, WarpD said:

You might think that... however, as example.... the Citation X I did for Eaglesoft would not be possible in WASM.

Ed

a naive question if the distinction makes sense : what you did couldn't be done with WA or what you did couldn't be transported with WA to a new plateform like FS20 ?

Edited March 30, 2020 by domkle

[Lorby_SI 2,036]

17 hours ago, MatthewS said:

They say legacy add-ons will still work

IMHO they didn't really say that. The only promises concerning compatibility were that the FSX flight model is still supported and that there will be the SimConnect API (which means that external programmatic addons might work as they used to - if SimConnect will be fleshed out to full spec and if the simulator supports those operations in the first place). WASM is probably not related to either, it sounds like it is the replacement for the "gauge.h", GDI+ etc. way of programming advanced aircraft instruments and the aircraft systems (which can include SimConnect, but doesn't have to). They may not be using WASM because they want to, but because they have to. Maybe their technology simply does not support the legacy/DLL way of making programmatic assets. That usually happens when just about everything else works differently too. There may not be any point in calling on Asobo to keep the "legacy way" alive. And it is not like the legacy techniques are the holy grail - I think that just about every seasoned simmer would disagree with that sentiment. A lot of people have been shouting for "the new", for breaking compatibility for good. And I am getting the feeling that this will indeed happen, that MSFS will not be a successor to FSX, but a replacement - on the same compatibility level as XPlane, DCS or Aerofly are.

Let us not lose sight of the fact that the WASM implementation in MSFS doesn't exist yet, they are still developing it. What, if, when, how everything fits together we will find out when it is ready. It also doesn't make a lot of sense to quote the spec at this point. Whatever Asobo will do with WASM, the result will probably be their very own brand - FSASM 😉.

Best regards

Edited March 30, 2020 by Lorby_SI

[GlideBy 324]

48 minutes ago, Lorby_SI said:

Let us not lose sight of the fact that the WASM implementation in MSFS doesn't exist yet, they are still developing it. What, if, when, how everything fits together we will find out when it is ready. It also doesn't make a lot of sense to quote the spec at this point. Whatever Asobo will do with WASM, the result will probably be their very own brand - FSASM 😉.

Very true.  People are assuming it will be the same, and have the same limitations as how it is used in a browser.

I want to remind people what they have said so far - "We also made lots of progress on WebAssembly support, which is the technology that will allow the porting of native code to our platform."

[GlideBy 324]

41 minutes ago, Rob_Ainscough said:

But it's a technology many of us don't want and/or can't use to accomplish our given tasks

How do you know in their implementation that you won't be able to accomplish what you need to do?  Remember, they don't have to use WASM inside a browser that is inside a flight sim.

They are listening.  So what exactly would you say Webassembly needs to be able to do what you are worried it won't be able to do?  Is it just local file access without embedding?  Assume Asobo reads this, what is your Webassembly wish list.  And saying don't use it, would not help as they have already started work on it.  But saying I need it to do X, might as they might realize they can't do X, so then drop it.

[MatthewS 761]

11 hours ago, mSparks said:

The speed difference is night and day.

No, I'm talking about no speed difference between C++ compiled to WASM or C# compiled to WASM, because it's all just WASM "byte code"....   Sure native C++ is going to be (slightly) faster than WASM.

Also I think your assumptions about WASM performance in the FS2020 embedding is too negative... Sure, the WASM embedding in Chromium/Firefox/Safari might be slightly less performant, but even in the Blazor world (.Net Core) the MS devs are claiming "near native" performance running WASM.

 

3 hours ago, WarpD said:

the Citation X I did for Eaglesoft would not be possible in WASM

Hmmm, I don't understand why.   Look at the glass cockpits in the default Asobo aircraft, very impressive and very smooth FPS from what I can see in the videos.

 

1 hour ago, GlideBy said:

People are assuming it will be the same, and have the same limitations as how it is used in a browser

Exactly, people assume the FS2020 "embedding" of WASM will be as restrictive as a browser "embedding" (which needs to sandbox WASM code that can be downloaded off any old website).... 

FS2020 doesn't need such extreme sandboxing IMO, add-ins are coming from "trusted" developers mostly, and Asobo will be able to strike a balance between performance and security (well that's my theory anyway).

 

50 minutes ago, Rob_Ainscough said:

The reason platform specific code exists is for performance, and MFS is going to NEED all the help it can get on that front ... and WASM is slow.

From what I've seen in the videos, performance is outstanding.... Presumably Asobo aircraft are using WASM compiled code too...  I don't think 3rd party devs have done glass cockpits that are more complex than what we've seen from Asobo...   Sure you might be using some 3rd party libraries, do you have the source, can't you just compile those libraries into WASM too.... If they are graphics libraries then I'm sure Asobo are providing similar "primitives"....  IDK maybe you need to write a wrapper around the API in your 3rd party libraries and reimplement it in WASM yourself (using the Asobo primitives).... Yes it's a lot of work, but surely a product that is 100% native WASM is better than some legacy sim-connect "Franken-plane".

[MatthewS 761]

18 minutes ago, GlideBy said:

Is it just local file access without embedding?

IMO, Asobo can easily add local file access to their WASM implementation. 

Even if they restrict to files under \\FS2020 rather than the entire O/S, that would still let add-ins access the files of other add-ins (and FS2020 itself).

Ideally though, add-ins would expose their own API, which allows other add-ins a formal way to use each other... Eg a Navigraph add-in could expose an API for retrieving charts and navdata from its database, a PMDG add-in could expose an API for refuelling, cargo, passengers etc that would let a GFX add-in refuel the aircraft... and so on.

Asobo should foster add-in interoperability by encouraging devs to expose APIs for their add-ins, IMHO.

Edited March 30, 2020 by MatthewS

[mSparks 2,086]

37 minutes ago, MatthewS said:

IMO, Asobo can easily add local file access to their WASM implementation. 

Lets be a little less abstract. WASM isn't some completely brand new never used piece of technology

e.g.

https://cdn.rawgit.com/vvanders/wasm_lua/d68f46a8/main.html

from

https://github.com/vvanders/wasm_lua

That should also give you an idea of the speed difference, takes over a second to display "Hello Lua".

If you change the spec you break the compatibility with all the existing tools.

Further the whole point of WASM is giving a place to developers to write code that runs without giving them access to local files.

If local files are a requirement, literally any other method of deployment is a better choice, even .net4/mono [shudders].

Edited March 30, 2020 by mSparks

[GlideBy 324]

23 minutes ago, Rob_Ainscough said:

Most of the issues have already been outlined and this is probably not the place to go into details.  Unfortunately I have developer mode and SDK, but was not provided access to the developer forum (which I have sent a request but no response).  This sort of discussion with this much "detail" probably should be done in the appropriate MS dev forum.

Cheers, Rob.

Fair enough.  Much better if you can bring up your issues more directly.  See this thread, and see if joachim can get you into the forums.  He is also active on a Discord server, if he doesn't respond here.  https://www.avsim.com/forums/topic/571164-msfs-forum-still-inaccessible/page/2/?tab=comments#comment-4191032

 

[mSparks 2,086]

11 hours ago, Rob_Ainscough said:

It's a game, not a gateway to the CIA or NSA agent database.

You may think that.

The truth is a lot grimmer.

https://www.theguardian.com/world/2013/dec/09/nsa-spies-online-games-world-warcraft-second-life

[WarpD 824]

19 hours ago, domkle said:

Ed

a naive question if the distinction makes sense : what you did couldn't be done with WA or what you did couldn't be transported with WA to a new plateform like FS20 ?

What I did requires a great deal more system access than WA allows.  WA is like a sandbox... a very, very limited sandbox..

 

15 hours ago, MatthewS said:

Hmmm, I don't understand why.   Look at the glass cockpits in the default Asobo aircraft, very impressive and very smooth FPS from what I can see in the videos.

I will agree... you don't understand why.  I can not discuss anything regarding what Asobo has done... except to state that what is in the G1000 they are offering is not even as complex as the one that came with FSX, and it doesn't even come close to the complexity of other G1000's available for purchase for FSX, et al.  Smooth FPS isn't enough for a high end addon.  There is a great deal more to making complex aircraft avionics than just having smooth FPS.  

[MatthewS 761]

5 hours ago, WarpD said:

I can not discuss anything regarding what Asobo has done

Hiding behind the NDA doesn't validate your argument.

Explain then, in general terms, why your "super duper" avionics cannot be reimplemented in a native "WASM" based aircraft.

I suspect you just don't want to go to the effort of rewriting your code to fit the new FS2020 paradigm, which I agree would be a PITA.

[GlideBy 324]

@Joachim  Can you help Rob?  (See the above two messages by him.)