Yes, the Working Title CJ4 can do everything IFR now, but it’s also taken us thousands of hours and many tens of thousands of lines of code to do so. And while our ProLine 21 simulation is now extremely deep and I think the most accurate on any platform, save the MilViz KA350, I would say there’s still a long way to go.
I would also say that complex plane development is measured in person-years. A high quality bizjet or glass GA plane can easily be a 5-10 person-years project, and a high quality airliner probably anywhere from 10 to 30 person-years, depending on the airliner.
Developing an airliner is about the same amount of effort as developing an entire indie game, at the levels that simulator fans expect.
I understand about airliners, however I was referring to simple GA plane models, ie a properly developed pa44. For which you may argue it’s still to early tho.
The game was so extremely hyped up for release. Remember MS sending out gift boxes with expensive hardware to game streamers? They played it once, on release day. Nobody watches you cruise along in a civilian aircraft… It’s boring. No action.
I don’t think WASM is just for porting legacy code. In some cases you need better performance than what Javescript can offer. WASM provides a means to have high performance code, for example generated using a C++ compiler, run in a web application. For some of the avionics Javascript would be just fine, but implementing a weather radar in Javascript? Probably too slow. This is the use-case for WASM.
From the perspective of 3rd party developer it makes perfect sense for them want to re-use their existing code base. Do you think there is anything wrong with that?
What if a 3rd party developer would port all of their C++ code to Javascript. It will be slower and it will take time before it is as bug free as the original C++ code.
P.S.: I use the phrase “existing code” iso “legacy code”, because C++ code does not have to be legacy code. It can be a recent development, it can also be 20 years old.
I wouldn’t say the use case so much as a use case. Performance in JS, especially computationally, is not really distinguishable from C++ these days. And, as it stands right now, canvas is fully hardware accelerated in on the JS side, so I don’t know that you’d really see a difference, in most cases. But that’s not to say that there are zero reasons. Whichever API you use, you’re going through a translation layer to DirectX calls no matter what anyhow.
I’ll repeat the previous mantra about performance here. I do agree that bug regressions are always a concern when changing platforms, though, yes.
It certainly can be new development. I think I was using the term “legacy” to refer to code built for the legacy sim platforms and not for the new APIs.
Just to be super clear, I’m definitely not trying to be on the bandwagon of “old is bad”. C++ is a robust language with a rich history and deep toolset, one that I have enjoyed working with when I had the chance both on open source projects and professionally. However, with the same care applied in either development situation, there aren’t really clear performance advantages either way, while there are clear tooling and dev time advantages on the JS side.
(1) How much easier it would be for 3rd party Developers, to code & debug MSFS code if it were not running in a sandbox, (or they could interface/debug that code, running in the Sandbox)
(2) Asobo do not have this issue, because they have the tools to work within the Sandbox.
(3) 3rd party developers “Could” also develop without the sandbox restrictions (like Asobo undoubtedly do), if they are given the ability to do so.
So why is Asobo holding back providing the tools to 3rd party Developers, to work in the Sandbox .? (The same tools they are no doubt using !!)
Could it be, that Asobo just do not realize, that those 3rd party developers have not been given the tools & information to do this !!!
The “sandbox” does not affect development time. It simply refers to the fact that C++ code is compiled to .wasm instead of .dll, so that addons will work on Xbox as well as PC.
There are no extra tools; they are not holding back anything. Third party developers, including us at FBW, have almost everything we need to make addons. A key point to remember, which Matt brought up above, is this: in general, making a good aircraft simulation takes a huge amount of work and time.
JS code is not part of the WASM sandbox. In fact, javascript has nothing to do with WASM at all. You can choose to make a plane completely in C++/XML like P3D, or completely in HTML/JS like the default aircraft, or any combination of both.
With the MSFS WebUI devkit, it’s extremely easy to see console output, run JS commands, inspect HTML, and hot-reload changes live. So debugging JS isn’t a problem if you choose to go that route.
Benchmarks are always tricky to compare, but if browse through the results you see that, for these programs, C++ is between 2 and 7 times faster. What I encounter regularly is than computionally intensive routines are written in a language like C++ and that the business logic around it is written in langauge like Python or JavaScript.
Granted, I would have thought that the difference would be bigger. Apparently a lot has indeed been done in optimizing JavaScript performance. Most notably it has moved from purely interpreted language to a compiled language. I found this interesting talk on the subject:
I’ve been looking at this lately and I’m not even sure it is so clearly separated, but I might be entirely wrong. It appears to me they are offering the WASM layer for porting or coding C++ code into the game, but the WASM byte code is translated to JS at runtime and the only layer is JS/HTML in the end.
If this is the case, it is convenient because you can use different languages for different purposes, benefit from each language strength, in a transparent and seamless way. However it would also mean there are a number of benefits you’d traditionally get in using the C++ language, like its ability to give access to close-to-the-metal resources and performances, which you couldn’t exploit anymore.
WASM compiles to a binary format that can be run by a virtual machine. It complements JS, in the sense that if you write your application in JS you can use WASM to implement performance critical pieces of your software. However it does not compile to JS.
In MSFS2020 WASM can also be used to integrate C++ legacy code as it is possible to compile C++ code to WASM.
What I’m saying is that FS2020 seems to be embedding a WASM → JS byte code trans-compiler. Which would mean the sole VM running is a JS one, regardless native JS source code or WASM compiled C++.
With this architecture, JS the the only VM running and JS/HTML the main layer for gauges. WASM would most likely be there “only” for porting legacy code, or for some specific uses which are non resolvable as-is in JS only.
You are right they might, and can if I’m not mistaken either, but I believe these could be 2 separate worlds in FS2020.
I’d guess JS/HTML support is embedded into CoherentGT as an internal VM, not as a FS2020 owned VM, and since running 2 VMs side-by-side is not optimal, and since both are strongly related contextually (gauges), it makes sense to feed the CGT VM with bytecode from WASM. It is possible JS and WASM bytecode are not the same (I’m looking into this low level aspect only recently) and there is a need to trans-compile one into the other in this case. My post above is just because in my research, I’ve found in the FS2020 binaries something which looks like that. It might be something used only for debugging and left there too.
Historically, the VM has been able to load only JavaScript. This has worked well for us as JavaScript is powerful enough to solve most problems people have on the Web today. We have run into performance problems, however, when trying to use JavaScript for more intensive use cases like 3D games, Virtual and Augmented Reality, computer vision, image/video editing, and a number of other domains that demand native performance (see WebAssembly use cases for more ideas).
and a little bit further:
With the advent of WebAssembly appearing in browsers, the virtual machine that we talked about earlier will now load and run two types of code — JavaScript AND WebAssembly.
I’m not an expert in this stuff, but this explanation suggests they share a common VM, which makes a lot of sense to me.
I have recently come to the realization that MSFS2020 is a GAME.
I do not mean its a Fight Simulator Game !!
Its far more an Adventure/Quest game, where players and developers are put into a world, developed by Asobo, with very little prior or current knowledge of that Asobo created world.
Their task is to go exploring, and mainly by Guesswork, and “Trail and Error”, complete the quest to understand this world they find themselves in.
To keep players and developers interested and encouraged, and not to give up on this Quest, there are regular CLUES given, in the form of minor SDK updates.
In this game, there are CLANS (developers), each competing for some form of dominance over the other Clans, and players … …
---- There are so many similarities –
GAME or Flight Simulator : its a FUN game to play (as long as your livelihood does not depend on it, or you do not become too addicted)
I have spent far more time “On the Quest”, and discovering the workings of the “Asobo World” than I have flying sim planes, and in the process of “The Quest”, met far more interestingly technical people, than I ever met just “FLYING” in "the Sim-
Its like getting a partially built “KIT Plane”, and having the fun of finishing it off yourself, and making it “your own”. – in fact, that describes the "MSFS 2020 “included planes” very well
— “Complete it yourself Kit Planes” (with missing assembly instructions)
It is not doing this. The only direct interaction that WASM gauges can have with Coherent itself is that individual frames of a WASM gauge (produced by graphics API’s such as GDI+) are rendered as images are in HTML, essentially.
There is no JavaScript transpiling taking place whatsoever. In fact, if you look in the “/Packages/a32nx” or “/Packages/aerosoft-crj” folder next to your Community folder, you will see that they both contain a .dll file. This is compiled from WASM to a native .DLL the first time you load in (which is why the Aerosoft CRJ can take up to 10 minutes on initial load - this native compilation is taking place).
But I love that game!