Are you sure about what you’re writing here?
Didn’t Asobo and Microsoft told us in the very first videos and/or PR published materials, they were building FS2020 from the FSX code base:
They are keeping what is good in FSX because there are things working well in FSX, and they are reworking the other things which are not good ‘enough’
Please understand FSX is built upon FS9, built upon FS8, etc… Look at the FS2020 SDK and you still get the FS4 area gauge and system SDK structures and principles…
Given the PR statements and the reality of the gauges and system SDK, you might believe therefore these antiquated and creativity limiting constructs of a Pascal/C area might still be considered good enough for FS2020 because they are kept as-is.
In my opinion, the reason X-Plane is vastly superior to any other FSX, FS2020 or Prepar3d simulator in the gauges and system department is simply because:
-
XP11 is exposing dozen of thousands low level fine grained data points, whereas FS is exposing a mere couple thousand pre-digested pre-filtered values. The former is the equivalent of low level data probes from within the very core of all these systems simulations, the later is equivalent to what is needed to drive gauge needles and lights in a cockpit only.
-
XP11 is not limiting creativity in giving direct access to the Video Card silicon right in the context of the rendering loop, FS is shielding the add-ons from the rendering loop and from the hardware therefore with lower perfs.
-
XP11 is not imposing a graphics API but the core video card OpenGL layer, FS is only giving add-ons a software based blit function (most likely a memcpy to a RAM backing store for a VRAM texture) and a bunch of path drawing APIs we don’t know anything about their latency, resources and performance impact.
-
XP11 is letting add-ons being called back on the frame, the simulation, the panel, the rendering update loops, FS is limiting add-ons to whatever it is it limits add-ons to with no latency guarantee when using SimConnect
-
XP11 data and event system is based on a comprehensive override and callback system (which would make the 10deg increment bug a no question at all) whereas FS is not letting any add-on interposing in the middle, which is directly depraving FS customers from a certain number of add-on types, and/or a certain number of add-on features.
-
Prepar3D 4 and 5 at least, are offering lower level access to some core internal simulator architectural elements and data, but is still suffering from the same FS4 area SDK heritage regarding simvars and APIs.
-
FS9 to P3D5 are not sandboxing the add-ons and can therefore be augmented with all the missing features. The Reality XP GNS and Reality XP GTN are examples of products augmenting all these simulator versions with a complete simvar override system, autopilot override system, and much more. This is mandatory in order to make these products available in the “Flight Simulator” type of simulators, whereas the same Reality XP products are implemented solely on the XP11 SDK with no hacks whatsoever.
-
FS9 to P3D5 and XP9 to XP11 are all running add-ons in the process address space and experience shows professional add-ons developers are doing it right and poses no risk to the simulator stability whatsoever in general. FS2020 sandboxing for stability argument is questionable therefore.
I can make the list way longer but the truth of the matter is that XP11, P3D5, FS2020 (to list only the latest) are not much different for many aspects, but XP11 has a clear differentiator in terms of SDK and I believe it is all rooted in a very simple explanation which shows clearly when you’ve been working in this industry for ages like me:
-
The FS SDK originate from the internal private headers ACE studio (and maybe even before them) developers were using for developing the stock aircraft. The only need therefore was having access to pre-digested events and variable suitable to binding with a 3D animation or a panel gauge element. The first public SDK was just the same header files “sanitized” from internal private things. The idea most likely was if this was good for us building our own aircraft, it is good for 3rd parties building theirs. And today’s is not different: if this is good for Aerosoft building the CRJ, it is good for all developers (Jorg’s comment 2 Q&As ago).
-
The X-Plane SDK originate from the same need to build aircraft but it was thought first and foremost for 3rd party developers, in a way which is not shielding the developer form the internal core simulation. Over time it has grown larger and bigger with an increasing number of simvars but few more API functions because of the simple reason there is no need for more: in giving access to low level API and constructs form the get go, there is no need for XPlane devs to provide add-ons developers with new functions anytime there is a need for something new, because the low level access already in place gives you access to this directly.
Please understand I’m not saying XP11 is superior to FS2020 or P3D, I’m just saying the SDK is superior because it lets developers doing what they do best: create new stuff the simulation developers can’t envision nor provision in advance for you. And in this department, at least for gauges and systems, I’m afraid to say FS2020 is a giant step back from P3D let alone XP11.
Having said this, it is also important to note Asobo did a marvelous job with the gauge and system “interface” in the form of the JS/HTML layer. I still don’t understand why they are not just documenting and solely focusing on this layer* instead of trying to build the legacy SDK bridges to WASM, with a pseudo GDI+ on top of NanoVG on top of their own bare bone (but sufficient) path tracing API. Fundamentally what is needed is simple:
-
JS/HTML for everything presentation
-
JS and/or WASM for everything computation
-
JS <=> WASM pipe for communication between the two
-
Overriding and interposing any event and data
-
SIM (JS and/or WASM) <=> External apps
.
.Simconnect, why not, but no guarantee to latency or throughput.
.
.Better letting 3rd party build their own transport too if they need/want (needing ShareMemory and/or Sockets) -
Getting rid of most, if not all, ancient SDK concepts:
.
.Enums for vars instead of plain text really? see the last SDK update the mess it is causing with enums and how this is limiting the expansion
.
.User events using number ranges which makes them non usable in any add-on because you never know if another addon is using the same range as you?
.
.Etc…
I’m not trying to let you think I’m any “authority” about these matters. I’m just sharing my expertise and knowledge so that you understand these questions, what matters to some 3rd party developers, and how the topic is much more complex than what it seems if you’re just listening to what is said in the Q&A…
[update] I’ve just posted the following which didn’t occur to me before, but there are some other aspect of FS2020 which are more “game” than “simulator” (please vote! Stars are useful for navigating sometimes): Stars too close?
*I’m putting these in bold because although the points I’m listing above are conceptual, it doesn’t diminish at all the great work done with the JS/HTML implementation and I want to make it clear: the FS2020 Gauges and Systems SDK is just the same as in FSX with less possibilities for 3rd party developers because of sandboxing. But the FS2020 Gauges and Systems JS/HTML Interface is the modern foundation I’d expect they document and I’d like they focus on with the 3rd party vendors. This new foundation is still however based on a certain vision of the 3rd party developer needs and methods which is still strongly infused by old FSX standards and there is not much to do to open this to more capabilities. There are notably a few core concepts needing slight changes, not hard to implement nor disruptive to the whole, which would radically help breaking some of the hard-limits 3rd parties are struggling with since FS9 at least. I’ve no doubt they are actively working everyday with a select few developers but the lack of transparency is in my opinion really hurting a lot of other 3rd party developers eager to help contributing to the franchise success.