MSFS Drawing Gauges on the screen

[Ze-Nova]

It is No problem to draw anything to aircraft panel using C++ WASM and NanoVG (as basic way for 2020) - SDK already cover this and examples. But I just lost trying find the way to draw the same basic things (Font, Textures, Lines) directly to simulator window with some screen coordinates? Is some special Callback / Context exist for this? Or?

 

[B21-soaring]

MSFS 2020 "draw anything to aircraft panel" is overwhelmingly done with HTML/JS. C++/WASM is most useful if you are porting something from FSX and you can't spare the time to rewrite it in JS. The compromise is Asobo MSFS aircraft are 100% in HTML/JS so the C++/WASM support expertise will be mainly within companies porting legacy products.

 

[Quazzy]

MSFS 2020 "draw anything to aircraft panel" is overwhelmingly done with HTML/JS. C++/WASM is most useful if you are porting something from FSX and you can't spare the time to rewrite it in JS. The compromise is Asobo MSFS aircraft are 100% in HTML/JS so the C++/WASM support expertise will be mainly within companies porting legacy products.

Is the overwhelming switch to HTML/JS only because of the simplicity between languages? Is there any performance differences?

 

[Ze-Nova]

MSFS 2020 "draw anything to aircraft panel" is overwhelmingly done with HTML/JS. C++/WASM is most useful if you are porting something from FSX and you can't spare the time to rewrite it in JS. The compromise is Asobo MSFS aircraft are 100% in HTML/JS so the C++/WASM support expertise will be mainly within companies porting legacy products.

Thanks for the answer, but it looks like you haven't read the question.

 

[B21-soaring]

because of the simplicity between languages? Is there any performance differences?

Firstly it's entirely an Asobo design choice - IMHO the initial objectives were:

• move away from buggy FSX 3rd-party .exe and .dll add-ons being able to crash the entire sim
• protect the user from random downloadable executables that are a serious security problem
• reduce the complexity of Windows/FSX/add-on version dependencies between releases (i.e. the so-called DLL-hell)
• choose a language which more naturally supports asynchronous execution, so the main thread is less likely to block
• recognise that in-cockpit equipment has moved from steam gauges to complex flat panels since FS2004

(I'm not arguing whether these objectives were right or wrong, just my understanding from prevous Asobo Dev Updates).

The consequence of the fundamental design change is a huge amount of the functionality in the sim is moving into the Javascript class structure, e.g. in FSX the sim API was defined almost entirely via reading and writing SimVars. That's ok if you want the current airspeed but totally sucks if you want to do ANYTHING less basic, e.g. query the flight plan. The fs9gps 'api' dating back to FS2004 is a basket case where you set a SimVar saying which waypoint in the flight plan you want the data for, and some unspecified time later you can read another SimVar which hopefully will by then contain the latitude of that waypoint. The complexity isn't helped by the 'SimVar' API being designed for single-number answers (i.e. not structures or even strings). The vast bulk of FSX 'api' access is for single values, like airspeed or altitude, as essentially that is all that is provided, so it would be understandable if much of the development community would see nothing wrong with the FS2004 API so question the need to change it, or be slow on the uptake of the new API's provided.

In MSFS 2020 Javascript the ability to read/write SimVars is still there, with most of the SimVar names/meanings carried over from FSX, but there is a completely new framework in Javascript where you control how you connect to the 'Update' cycle in the sim and subscribe to SimVars or events, and a HUGE stack of Javascript classes which you can interact with in your code. The Flight Plan is possibly the best example - in MSFS 2020 the loaded flightplan is natively accessed via an asynchronous API call (something like Coherent.call('GET_FLIGHTPLAN').then( (response) => code to handle a detailed flightplan data structure)) where the 'then' part is executed only when the data is ready, so the update loop isn't blocked, and the 'response' is a highly structured data object containing everything MSFS knows about the flight plan (imagine trying to read that querying one variable at a time. The JS API also includes pre-defined classes FlightPlan and FlightPlanManager which you can sub-class in your code, and the Coherent.call() in this example is kind-of the lowest level you'd access the data (it's what FlightPlanManager does) so you can use FlightPlanManager instead and it will do all that for you. Personally I prefer to look in the Asobo classes (that's all we have for 'documentation') and do the low-level call.

If you are laying out modern information on a flat panel display, nothing compares to HTML/JS. Sure, if your display is fixed, showing a 2D or 3D vector graphic, you could compete with some drawing library in C++, but SVG in HTML has already replaced this in real-world adoption and if the display is intended to be flexible, i.e. have buttons to flip between pages, display maps, respond to user touch, etc, then HTML/JS is the only sensible choice.

In terms of performance, HTML/JS is natively surprisingly fast and CoherentGT does a good job rendering that in the sim - e.g. implementing an Attitude Indicator is pleasingly tidy (super easy, barely an inconvenience...) where you create a brown HTML rectangle for the bottom half, blue rectangle for the top half, and rotate those using CSS - all this is familiar to web developers but will be a foreign langauge to programmers that pre-date the internet and have avoided web programming.

For a specific HTML/JS performance example/comment - my gauges are unusually complex (up to 10,000 lines of JS), either doing realtime physics calculations or updating large flat-panels displays with information overlaid on a map. The physics calculations are EASY - modern CPU's love that kind of stuff. The potential CPU killer is anything you might want to do updating a large flat-panel display, particularly involving a moving map and it's associated graphics. Here there is a BIG cultural change required from FSX with its 'steam' gauges - in that case you can write a single block of code that updates the display, and call that block of code on each update cycle. With a large flat planel display, with hundreds of calculations of which 'soft buttons' should be highlighted, where needles should be drawn, where on-screen numbers should be updated, how a map should be panned/rotated etc, ALL of your code needs to keep track of when its particular detail was last updated, and only call the full update routine when it is sensible to update that item. E.g. it would be reasonable to update a map once-per-second - you don't need to call its update method on every 'Update()' call to your code, which would update the map 18 times per second. CoherentGT will 'diff' your displayed graphics and only update the changes, but that doesn't remove any redundant processing you were doing to produce those graphics in the first place.

My HTML/JS code typically takes 0.3 .. 3 milliseconds per frame update (i.e. it is nowhere near bottlenecking the FPS) - I am absolutely certain that the most common reason for any HTML/JS panel causing a frametrate hit will be naively-written code that just says 'completely refresh everything on every update cycle' (Asobo know this, so the settings include a value for HTML/JS refresh rate and that defaults lower on a low-end CPU)

HTML/JS in MSFS isn't entirely a bed of roses - the documentation of the API calls is non-existent & you have to wade through the Asobo JS code looking for examples. The decision to have the add-on code running within a JS protected environment (as in your browser) rather than allowing DLL/EXE access to the users desktop radically reduces the freedoms to look around the user PC to read/write data files (the 'strategic' solution is to use http access to get that info from a web server, but that's a big change).

 

[B21-soaring]

Thanks for the answer, but it looks like you haven't read the question.

Sorry Ze-Nova, I didn't mean to do that and my long answer above to Quazzy was written overlapping with your comment above, so it looks even more like I've hijacked your thread. Apologies.

If you're already committed to using C++/WASM to draw text/fonts my answer is clearly irrelevant.

 

[Ze-Nova]

Sorry Ze-Nova, I didn't mean to do that and my long answer above to Quazzy was written overlapping with your comment above, so it looks even more like I've hijacked your thread. Apologies.

If you're already committed to using C++/WASM to draw text/fonts my answer is clearly irrelevant.

no problem, but still wait ideas about main issue

 

[WarpD]

There are a few misconceptions regarding DLL style gauges in that post, but, not worth quibbling about.

The primary problem with HTML/JS... it's not protected. Not even remotely. No matter how much you "encrypt" something, someone will always find a way in and then share what they found.

 

[DragonflightDesign]

As Ed says... and before anyone says 'but you can reverse engineer dlls as well', yes you can, but you need some seriosuly expensive software to do it. Or a good eye for hex code

 

[WebSimConnect]

In terms of performance, HTML/JS is natively surprisingly fast and CoherentGT does a good job rendering that in the sim

I do not entirely agree with that statement because CoherentGT does not support WebGL which is a major showstopper for sophisticated instruments requiring fast rendering. Still CoherentGT implemented native accelerated html canvas rendering but that is not the same thing.

 

[B21-soaring]

CoherentGT does not support WebGL which is a major showstopper

Totally fair comment, & your WebSimConnect framework looks really impressive. I'm not attempting 3D rendering (I guess the main use case for that is the kind of holographic rendering of the external 3D view on the panel?). My "surprisingly fast" statement is from the JS update cycle is still only a couple of milliseconds in my AS33 with a relatively unusual 10,000 lines of JS (I was surprised, anyway).

 

[WebSimConnect]

sure, pure V8 javascript engine is pretty fast and allows to develop easy code, plus tons of JS libraries makes the work much easier and faster than c++ developments, specially for rendering. I always wondered why LM did not introduced that in P3D in the first place but played with ScaleForm an lua that almost nobody was using. With more and more glass cockpits in the real world, html for simulations was inevitable.