According to @ExpressTomato52 they have been rewriting many things from scratch and little remains. He has certainly some privileged insights nearly all other 3rd party devs don’t have to be so affirmative and I believe this.
To me the FS2020 Gauges SDK is looking like the FSX Gauges SDK only because it is a bridge (a combination of typical Facade, Adapter, Mediator, Bridge GoF patterns or similar) which purpose is mostly to ease porting existing 3rd party code to FS2020.
However I believe it is shielding 3rd party devs too much from the real potential of the platform and I just hope this will not overall impair creativity in the long run in adding technical debt to an already flawed FSX SDK just to make a select few releasing their aircraft faster to the market place.
An example is the effort they are putting in reimplementing GDI+, on top of NanoVG, on top of their own low level blitter & path drawing api. I mean any 3rd party can do its own GDI+ bridge to ease porting his own FSX code so what is the reason behind Asobo allocating dev resources to re-implementing GDI+ if not making it faster for 3rd party devs?
The problem is in doing so it is also not thinking outside the box of why is it nearly all 3rd party are using GDI+ to get started with, except Reality XP which has implemented its own faster technology since the Meridian in 2004. In effect, most are using GDI+ because there was nothing else readily available to directly draw AA vectors into the HDC provided by FSX SDK.
Because of this technological choice, all GDI+ gauges were coded with the GDI+ way of coding graphics and path drawing. The GDI+ fundamentals are therefore imposing themselves upon the gauge implementation and this can sometimes be limiting the implementation in certain ways you wouldn’t if you’d be using a different, and lower level graphics API instead (like the low level one included in the FS2020 SDK upon which they implement NVG and GDI+).
Hopefully in this case most vector drawing API are similar so this shouldn’t be an issue at all isn’t it? Well yes it is. For example because GDI+ was used for AA vector drawing and because GDI+ can only bind to the gauge HDC, it was chosen as an easy way to get better looking graphics (but with lower fps because GDI+ takes lots of CPU). Therefore it forces gauges to using the HDC, which is the slow bridge offered in the FSX SDK for the GDI drawing API initially. Rather, Reality XP is directly working with the underlying gauge surfaces (which are exposed via the SDK) and the RXP products are not at all suffering from the GDI/HDC bottleneck and memory bloat.
On the other hand, Reality XP gauges can do things no other gauges can do, like 32 bits high DPI graphics (from FS9 to P3D5), displaying many popup windows with different sizes and the virtual cockpit all displaying the same GTN gauge without any fps loss (unlike most others displaying either the VC or 1 popup but not both at the same time) and many other things too long to describe here. These are possible because RXP gauges are using the FSX SDK in fully understanding how the SDK elements are relating to the underlying graphics engine internals. Doing some of the most renown gauges for 20 years gives you some expertise in this field.
Fast forward today, there is no longer any need for GDI+ then. Therefore, how much of the FSX SDK technological constraints are imposing themselves upon creativity and what do 3rd party developers have been doing to circumvent these? In general nothing. Nothing otherwise you break forward compatibility and you have to re-implement all the workarounds with any new flight simulator update. In turn, because you’re more or less forced to stay in the box, in having the same FSX principles forced upon us in the FS2020 SDK, you’re staying in the same limited box you’ve had for the last 20 years.
Now the topic question is nonetheless raising some good points.
Re: the 10 degs OBS bug
What I find amazing is this is a very old bug well known since FS9. For example, a quick search and you find posts about this dating back from 2004!
More recent posts (2010):