SDK Q&A Stream Feedback

Discussion Hub General Discussion
3

@Jummivana
Thank you again for a great Q&A! It is great you’re also letting us discovering new team members!

My initial feedback:

There was a lot of great new information for 3rd party devs and this is appreciated. On top of my mind:

  • New people in the team
  • New Q&A platform (around May 3rd)
  • New “performance measuring” tools (mem profiler)
  • New JS dev tool (Coherent debugger)

There was also a certain number of set backs:

  • No SimConnect on Xbox
  • The justifications for sandboxing add-ons
  • They don’t want we override the flight model

There was also some hints about DX12:

  • “DX12 won’t change anything for the Xbox and later on for the PC”, which I read as: "we’ll get DX12 on the PC version after the Xbox release, not at the same time, not prior either.

There were some topics which weren’t specifically covered:

  • Gauges and system SDK evolution and direction.

And maybe a misunderstanding (I might have misunderstood):

  • When Eric was talking about the enhancements to come in the SDK, there was a chat question about “roadmap” and the answer IIRC was about “feedback snapshot”. However I believe the purpose of the question was not about the simulator roadmap but the SDK roadmap, i.e. when will such feature be added, what other features will be added and when, what is the direction the SDK team is leading the SDK toward, etc…

About “the justification for sandboxing add-ons” when asked for DLLs

Eric was saying what sandboxing is good for:

  • DLLs can carry unsafe code and they can’t have unsafe code in add-ons in the Market Place. Sandboxing is good for having safe add-ons in the Microsoft store.

  • Sandboxing is also a good way to port legacy addons in C++

I agree with the first one:

Sandboxing is ensuring you can only have safe code in the market place.

Nevertheless, what about add-ons which are not sold on the market place and why not opening up the SDK and offering DLL and low level support/access to the simulator for these addons then? (IIRC this was already requested as early as when the alpha started and was probably among the first questions from 3rd party vendors)

As for the 2nd one:

It seems to me they might have had “some” input from “some” 3rd party vendors they are closely working with in order to get this “overall” picture of what it is 3rd party vendors are doing in C++ with their “legacy” gauges.
I’ve been working exclusively in this industry for the last 20 years and the truth is radically different to me.

This is why I’d like to share this feedback so that it might help Asobo getting a clearer picture that 3rd party vendors are not just like this, and they are not all just doing simple XML gauges or EFIS screens in GDI+.

In effect, I don’t know what C++ gauges and modules Eric is referring to, but to me I don’t see how sandboxing is a good way to port legacy addons:

  • All C++ coded add-ons I know of (and I’m not talking about Reality XP own products) are in one way or another accessing the simulator in a low level which is no longer possible today with sandboxing.

  • Many of them are using 3rd party libs (other DLLs or .lib) they can’t use anymore.

  • Some of them need to also access other files on the computer and data sources (navdata, online services, etc…)

  • Sanboxing is further reducing performance for some of the most cleverly coded C++ gauges and modules. For example we do care about cache line size and do optimize our memory accesses, lock free and wait free programing, optimizations we can get with poisoned pointers, and many more low level C++ stuff no longer possible with WASM.

  • Sandboxing is also preventing clever use of SSE optimizations (not the auto-vectorized code by the compiler, but the hand-crafted SSE2/3/4 and AVX code we’re also implementing).

  • The WASM sandbox and the SimConnect conduit are not offering any latency guarantees, whereas our own IPC based lock-free/wait-free MPMC queues are offering these, and on top of that are running nearly at the same speed as a memcpy (this is why you get nearly no latency on the Reality XP GTN when touching the screen).

The above is just scratching the surface of why sandboxing is good for the market place, no doubt about this, but certainly not as good for 3rd party vendors in general, but only if you’re coding gauge and system in C++ like you’d do with any high level language or JS, without exploiting the benefit of C++ to-the-metal optimization opportunities.

Nevertheless, sandboxing the code running in the simulator wouldn’t be as much a problem if only there would be low level mechanisms to ensure fast inter-process communication (aka shared-mem based IPC) and additional socket based communications mechanisms (the latter not in lieu of, but complementary to the former). But even this seems to be totally ignored (IPC) and not planned (sockets).

I remain available and open to discuss any of this directly with Eric and Alyzée of course, and I’m French so there shouldn’t be any language barrier either.

PS: I’d be pleased to share with them any relevant source code as well, which will certainly also help them having a first-hand experience on some of the most advanced gauges available ( some of the most advanced from a gauge sdk standpoint, and not just from a simulation or Garmin standpoint: www.reality-xp.com ).

17 Likes