I see a lot of references on these forums to FSX and, in particular, references along the lines of “why did they take X away when that’s been in the sim since FSX?”, or “feature X used to work like this in FSX, why did they change it?”
Given FSX was written ages ago and MSFS seems to be an entirely new Internet/ online based ecosystem with live weather, live traffic, multiplayer, streaming scenery and photogrammetry etc, this surprises me.
My assumption, on the basis of no other information, is that MSFS will have been written from scratch and probably in a different, more up to date, programming language. If true, the concept of features or code somehow carrying over from FSX wouldn’t make any sense.
I’m wondering if the devs have somewhere says that they have built on the FSX code base or something. Just curious.
Little remain from FSX from sim base structure, many thing have been rewriting from scratch, hence no compatibility and unfinished SDK, graphics engine is Asobo propriety, most data are new, with new module from current generation game industry, the new fx noddle particle system will be added in near feature, will end for good the old ancient fsx\p3d fx system.
The ATC interface was definitely inspired by if not copied from FSX. It just feels clunky in general and doesn’t feel like it was overhauled like other aspects of the sim were compared to FSX
I think the point that many are making is the comparison between the two versions. Rather than a ‘why did they take it out’ I take the comment to be ‘It worked well in FSX, so why wasn’t it replicated’.
I think there are some unfair comparisons however as some have used FSX for a great many years there will undoubtedly be some level of comparison made.
They said in one of their first announcements about msfs that they used parts of the code of MSFS. You can see this in the aircraft files for example, it uses the same structure although there are features added.
I don’t think I’ll be able to find the reference, it’s more than a year old by now.
I’m sorry but I can’t help wondering then, for gauges and modules, why is the FS2020 trying to recreate the FSX SDK so much as a FSX SDK clone, instead of building it from a different perspective?
FS2020 software and gauge architecture is way ahead other simulators. It is a sound implementation with lots of potential especially in its capacity of “objectifying” what is running in the simulator in a modern way. However, there is a severe dichotomy between how it is designed and how 3rd party can access it, because of the SDK which resemble a “software bridge” between the modern simulation architecture and the outdated FSX C Gauge SDK.
I just hope this is not related to relying mostly on a single vendor building an aircraft in a certain way which is not unveiling the inherent FSX SDK intrinsic flaws. There are flaws which are limiting creativity for many 3rd party vendors in FSX, Prepar3D and FS2020 but not in X-Plane 9, 10 and 11, where unlike the later, the former requires hacking the FS code in memory to augment it with basic low level support features necessary and lacking otherwise.
PS: the flaws I’m talking about are not about FS2020 limitations due to WASM and overall FS2020 “sandboxing”. These are SDK flaws mostly due to creating and incrementally adding items in the FS SDK for supporting new features required for the default aircraft only.
Its definitely not a recreation of the FSX’s SDK. Much of the SDK’s text is literally exactly word for word as it is in FSX’s SDK. Most of Simconnect works almost exactly as it did in FSX.
They clearly retained parts of FSX where they felt no changes were needed. How much of FSX is still in MSFS is anybody’s guess.
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!
I’ve noticed the autopilot and sound engine closely-resembles earlier versions of FS. I’m sure they’ve tweaked it since then, but the essential skeleton seems to be the same.
My guess is they tried to port over as much as they could get away with, for the sake of efficiency, before realizing it was a bad idea, particularly with the autopilot.
Chunks of this game go all the way back to the DOS days. For example, the BGL file format you find in Flight Simulator goes back to at least FS5 and the early 90’s. That format, and FS5 itself, are based heavily on code going all the way back to the SubLogic days before FS1. There have of course been massive changes since then. These formats evolved, and code was rewritten and ported to run on new hardware, so I’m not saying it’s the exact same software. However, they didn’t rewrite all of these portions from scratch to be backwards compatible. They’ve at least dragged some of the old code over, and some of those remnant bits go way, waaaay back.
Really interesting insight from everyone who has posted, thanks for taking the time. Sounds like some of the DNA may be there in file formats and other chunks of code. The 10 degree bug is fascinating that it has reared its uglt head again!
Guess the answer and the perspective depends on what content one is working on?
Aircraft gauges: Whole new world, WASM and all that… Except not so much since Simconnect is still there.
Aircraft visuals: Seems completely new, but with legacy support?
Aircraft flight modeling: Format seems like same old with some detail changes, except the final remnants of the .air files are gone and content is sliced up differently between .cfg files. But the flight model that uses the data is new so the results differ.
Terrain modeling: Forget everything you once knew, nothing remains, not even using .bgl files anymore.
Other types of scenery like airports: Very little change? Hardly any change from FSX?
AI traffic: Offline traffic principles seem mostly unchanged from FS2002. Online is completely new.
UI aspects and how addons are distributed to and integrated in the sim: Completely new.
Where format and behavior is unchanged I bet it uses mostly the same code.
I’m going to point to Lionel’s comments in the first Q&A back in the fall of 2019.
3:28 - “we have our own proprietory engine at Asobo, we started with lets put a plane in there… and we had our own aerodynamics thing, and then we brought in all of this Legacy from FSX.”
3:55 - “one of the reasons we brought in everything from FSX and ‘not just the flight model’, is because The way FSX is designed makes it so that everything here is …modifiable and has layers like .BGL files, that where you can add scenery on top of others, and the way the simulation can be configured, and the way you can import models…”.
4:49 - “…we are using this architecture [FSX] and merged that somehow with our [Asobo] engine, and added bing maps on top of all of this”.
Lionels description of MSFS’s history seems to suggest a merging of Asobo, and Bing Maps technology with the legacy FSX technology. I thought Lionel’s mention of .bgl files was interesting as that is a legacy from FSX (as someone else here pointed out).
Obviously that Q&A was well over a year ago, certainly improvements have been made since then ,(though it was only a few months before the first Alpha’s went out ) But considering all the clues around us from the SDK to the .bgl files, to simconnect etc. It seems to strongly suggest some of FSX’s core was left in place in MSFS where Asobo decided little or no changes were needed.
It’s one thing to have inspiration from FSX but this sim (MSFS20) has no ESP code whatsoever. The ESP code was in 32bit format. Even P3D has little to no original ESP code in it now.
