1 hour ago, GoranM said:

Yes and no.  Do the pro's outweigh the cons?  More code comes at a cost in the form of CPU cycles.  Efficient code can minimize the hit on FPS, but there will be a hit on FPS.  Inefficient code can obliterate FPS.  Bad memory management can cause even more problems.

I'm not saying what they did was "wrong", and obviously it worked for them.  I'm just confused at why do something, that in my opinion, isn't really necessary for a consumer level flight sim, when the tools are already provided...unless they want to really nail down some pesky problem.  However, from what I can see, they've customized the flight model quite a lot.  

There is a lot of customization possible in Planemaker.  I'm not talking about bits and pieces here and there.  I'm talking about just about everything can be customized within Planemaker.  Maybe it's easier for a dev to code something rather than making it work in Planemaker.  Ben Supnik once told us, if X-Plane doesn't have it, code it.

Again, there are other helo's from various developers, including the default eVTOL, which was made for United Therapeutic, with the default XP flight model.  And it flies pretty nicely.  It's not a helo, but it's the same principal.  

To me, coding a completely external flight model, or even coding a large portion of the flight model, is extra work that doesn't need to be done.  But I'm sure they had their reasons.

I take your point. Good enough is good enough to sell a plane. I would say that excellence beyond that which any sim can offer as default will also sell in bucketloads as the A2A proves?

21 minutes ago, jarmstro said:

Good enough is good enough

Sometimes it's just as much the nerdy curiosity of the developer as it is knowing what will sell the bucketloads. Though with the proliferation of cheap(er) 6dof platforms, the drive to nail down those secondary motions may get more and more heated in years to come.

I can envision a situation in which a FM mod might be a near-zero loss in FPS, that being with the fuselage. Delete the fuselage in planemaker so that XP wouldn't go into those calculation loops. The plugin then does the force injections at each frame-draw. It's robbing one hand to pay the other, and I bet there's always at least some FPS loss when triggering the plugin to run, but potentially a bit less of a hit.

13 hours ago, jarmstro said:

I take your point. Good enough is good enough to sell a plane. I would say that excellence beyond that which any sim can offer as default will also sell in bucketloads as the A2A proves?

Weeeellllll, that's a very grey area.  What I bolded is extremely subjective.  A2A have a solid reputation.  Good enough for them, could easily mean "above and beyond" for other devs.  

I have a great respect and admiration for their work, and part of what I do stems from my experiences with them and their products back in the FSX days.  Fortunately, I work with people who have that same kind of perspective.

I know, for a fact, the MSFS flight model has some issues that need looking into.  And they'll likely be taken care of next year.  The X-Plane flight model is not perfect, and I haven't seen anyone ever claim it was.  However, using real world figures and info, and putting them into planemaker, will create a flight model in X-Plane that flies quite close to the real world counterpart.  Obviously, there are likely many areas where the physics and math is missing or incorrect, but if those areas get noticed and reported, Laminar will address them.

A good example of that is this rather large modification in the jet engine physics of X-Plane 12.

And there's this one, which was observed by an X-Plane enthusiast by the name of Mike Vivaldi.  This was a pretty big update that plugged a hole in the supersonic physics in X-Plane.  And for all intents and purposes, was the reason not many supersonic add ons were made, due to weird behaviour in X-Plane when approaching supersonic speeds.

 

Edited July 22, 20232 yr by GoranM

12 hours ago, blingthinger said:

Sometimes it's just as much the nerdy curiosity of the developer as it is knowing what will sell the bucketloads. Though with the proliferation of cheap(er) 6dof platforms, the drive to nail down those secondary motions may get more and more heated in years to come.

I can envision a situation in which a FM mod might be a near-zero loss in FPS, that being with the fuselage. Delete the fuselage in planemaker so that XP wouldn't go into those calculation loops. The plugin then does the force injections at each frame-draw. It's robbing one hand to pay the other, and I bet there's always at least some FPS loss when triggering the plugin to run, but potentially a bit less of a hit.

Admittedly, I'm well out of my depth here but I remember when FlightFactor brought out the glass cockpit option for the 767. These four screens dragged my then PC to its knees. However, if the work was being done outside of the sim would it not be the case that the performance would have been substantially better?

Edited July 22, 20232 yr by jarmstro

My first experience with a "out-of-the-sim" aircraft was the Majestic Q-400 with FSX.

I was long waiting for it's release, since around 2005 when I started following their project based on JSBSim's FM. 

I never really liked the feel of the Majestic in FSX... but some users told me it worked & felt a lot better in P3D. I am about to try it with P3dv6 because I decided to support the platform, and the Q-400 is one of the few aircraft that natively support v6 now.

I tried using Aerowinx with both X-Plane (10, 11 and 12) as well as with P3D, but the solution never proved good enough for my liking 😕 Hand flying an approach in PSX, even with the poor / basic World graphics,, feels a lot more lively than when used with those visuals sims...

ELITE does feel a LOT better when used with P3D for the visuals.

I guess the approach followed by A2A is rather ingenious and they could probably do the same in any other simulator platform provided they are offered the access to the necessary variables. Maybe ACCUSIM 2 can make A2A debut in XP ?  Or ... AEFS ...

3 hours ago, jarmstro said:

Admittedly, I'm well out of my depth here but I remember when FlightFactor brought out the glass cockpit option for the 767. These four screens dragged my then PC to its knees. However, if the work was being done outside of the sim would it not be the case that the performance would have been substantially better?

Hmm, OK, sounds like a simplified(!!!!) explanation of parallel compute is in order.

When it comes to performance, what actually matters is the time it takes to complete a task.

This is generally expressed/written as "frames per second"/FPS. A frame is the task of drawing everything to the screen - FPS; how many times you can draw a complete scene on a monitor in a second.

But, obviously, there are many more tasks involved than just drawing to the screen, and to understand that performance fps is basically meaningless. The first step is to convert fps to frame time, 1/fps, 

e.g. 60fps is 1/60 = 0.016666 seconds, written as 16.6 milliseconds. 16ms.

In plain english, to achieve 60 FPS all tasks need to be completed within 16 milliseconds.

What are these tasks? everything involved in creating that scene: reading the controller hardware, calculating the physics, running AI - everything you want to happen in your flightsim.

for example, decompressing and loading in to memory a lovely 50MB ortho tile.

Thats going to take at least 2 or 3 seconds......

So, how do we complete a task that takes 2 or 3 seconds in 16ms, looks like we need to speed that up several thousand times....

The answer is, we dont. we turn to parallel compute.

instead of making the drawing of the scene wait 2 or 3 seconds (2 or 3 seconds per frame for fps fans), that load happens in parallel - no less than 2 or 3 seconds before drawing the scene actually needs it.

How does it do it in parallel? well, modern CPUs are actually several computers all bundled onto a single chip - how many is denoted by how many cores your CPU has.

One core is drawing the scene, the other starts loading the tile 2 or 3 seconds before its needed, everything chugs along visually taking no more than 16ms, we have our 60fps. everyone is happy.

great,

OK, but we need to load 20 tiles in at the same time, and we only have 4 cores on our CPU to play with...

Enter "threads"

Developers dont program so much for cores (simplification, but unimportant for the explanation), they program threads. Identical concept -tasks that want to run independently of each other; except the operating system handles turning 21 threads (20 tile loads and 1 draw) into work for the CPU cores, splitting the work among the available cores, to get everything done as quickly as possible.

For those who like it more visual, that is exactly what is happening in the CPU utilisation graph of this video as xplane loads up.

Sidenote: windows home generally limits that to about 4 cores give or take, because any more is "expensive operating system software only big business servers need".

If you made it this far, congrats, you now have more knowledge about how compute works than 99% of software developers.

Lets take it a bit further.

Cores are "multiple computers on a single chip" but what if we want to make use of physically distinct computers, everything above is still mostly the same, but now we cant rely on the OS to get our threads to talk to each other, we have to write our own, most versatile way is to do that is over the network.

If you want to run the flight model on one PC and the graphics engine on another this is exactly what they do.

CIGI/HLA/DIS I mentioned a page or two ago are standardised ways to do this for flight sim. There are many others and many not standardised.

This is known as distributed compute. If you made it this far, congrats, you now have more knowledge about how compute works than 99.99999% of software developers.

What I mostly skipped over for simplicity is the challenges that accompany all this, and they simply cannot be exaggerated, doing any of these well is a gigantic challenge, and fixing issues in any of these approaches is incredibly time consuming and frustrating. Windows also comes with virtually no tools to help that kind of development (which is why so few developers adopt it).

As a very simple example of how time consuming that can be consider what would be involved in diagnosing and fixing even something simple like a random tile load taking 4 seconds when it will be expected by the GPU in 2, and the only error you get is "GPU error". Throw network errors in there and things get messy quickly.

From my side, this is the motivation behind the xtlua development that comes in the 744.

All the other Lua engines (xlua, FWL, SASL, gizmo) run inside the XP drawing thread - so if the aircraft system code takes 5 milliseconds to calculate everything (very, very common), your 16 millisecond draw time budget for 60fps falls to 11 milliseconds. Worse, VR really wants 90fps, 11 milliseconds total, giving xplane only 6 milliseconds to do all its drawing stuff - perhaps doable on extremely low settings.

XTLua runs the systems in a seperate thread, and takes all the headache out of synchronising everything with XPlane mentioned above, now all the draw thread has to wait for is any data changes that happened since the last time it drew stuff, on the 744 with 10s of thousands of things (datarefs) that would potentially need synchronising, that generally takes about 200 nanoseconds, giving nearly the full 11ms for xplane to run its drawing thread at 90fps and a very happy tubeliner in VR.

did I say simplified.... sorry about that, I'll get my coat.

8 hours ago, jarmstro said:

However, if the work was being done outside of the sim would it not be the case that the performance would have been substantially better?

Goran or msparks or another dev reading through would have to confirm, but I think XP sits waiting until all the user's plugins are finished thinking about life, before moving on. Nor does it run the individual plugins in parallel to each other?? May be wrong on that bit. 

So regardless if drawing to the screen or replacing the FM in some way, there's going to be some hit, hopefully small. Zibo's very well optimized for example. FF absolutely could do better. Shame on FF.

I do know that drawing from a plugin (e.g. EICAS screens) has historically been complicated by opengl, which was/is clinging to the single-thread-compute-life that it was born into in the 90s. Can't easily make GL draw calls in parallel threads, if at all.

As for parallel, what he said ^^^. Xtlua is a cool idea and works quite well.

Edited July 22, 20232 yr by blingthinger

On 7/16/2023 at 11:38 PM, mSparks said:

Considering past PMDG offerings were basically universally praised, we've discussed before that they cant be that pleased with the criticism they have been getting for their latest releases through no fault of their own.

Could be the first rumblings of them coming back to XPlane.

While no one likes their work to be criticized, after 20 odd years as a commercial dev, I'm sure they don't lose much sleep over the baseless commentary of the chattering classes.

And I'll never say, "never", but I think the odds of them coming "back" to X-Plane are exceedingly low, all things considered. 😉

On 7/18/2023 at 7:35 AM, Pe11e said:

Sorry for interrupting the (as usual, heated) discussion, but A2A released the Comanche for MSFS today, and I hear the mermaid singing, again.

I know that A2A is using their custom physics engine, running external, as well as sound engine. It seems that is the only way to get the physics right in MSFS

Why resist? Regardless of how they accomplish it, their addons have always been among the most accurately simulated available in any sim. Their older addons, particularly the Civ Mustang, and other warbirds and GA, are, aside from Majestic's Q400, the only reason I keep P3D installed.

As to your second point, it's a gross over-generalization.

A2A have literally decades of experience using external code to get the exacting results they demand. So it's only natural that they would continue that approach in the new sim.

Indeed, it was probably inevitable considering how rapidly MSFS has been evolving, as well as the genuine limitations within the sim.

MSFS is far and away better than it was 3 years ago, and genuinely good physics are now possible in the sim.

It's simply obvious, though, that "good" isn't enough for the A2A team. 🙂

Edited July 22, 20232 yr by UrgentSiesta

The A2A Comanche is very tempting.  The issue holding me back is my other (limited) experience with MSFS payware aircraft.  JF Turbo Arrow, C414 and PDGM.  I'll leave PDGM out of this discussion because I'm satisfied with the systems model.  I never piloted an airliner, so FM wise I wouldn't know.  My opinion of the JF Turbo Arrow model is pretty low FM and systems wise.  Having flown a real (normally aspirated) Arrow during CPL training, the JF model for MSFS is way off the mark.  The C414 is a bit more fun and except for the fact that you can do just about everything wrong and it doesn't matter, I do enjoy it.  Full disclosure - I spend most of my sim time in XP.  But if this A2A thing is as good as some folks are saying I can see using it A LOT.  

1 hour ago, UrgentSiesta said:

While no one likes their work to be criticized, after 20 odd years as a commercial dev, I'm sure they don't lose much sleep over the baseless commentary of the chattering classes.

And I'll never say, "never", but I think the odds of them coming "back" to X-Plane are exceedingly low, all things considered. 😉

Well, "never" is definately someway off the mark, since:

7 years old now, still destroys all the competition from what I can tell.

I would be incredibly surprised if giving new life to that un xplane, and even the rest of their fleet isn't something they have discussed.

Just suggesting that a "what do you think of xplane" question on a teleconference with PMDG is more than sufficient motivation for 737NG to do some background research, and share it on their YT channel.

7 hours ago, blingthinger said:

but I think XP sits waiting until all the user's plugins are finished thinking about life

XPs frame times are "real" frame times (big difference vs a lot of games) so all the core sim stuff happens at the reported framerate.

(i.e. yes, you are correct)

what a lot of games sneakily do is run their physics and AI in parallel at like 30 milliseconds a cycle, while the draw thread rockets away reporting 350fps.

That looks great on the benchmarks, until you realise thats actually only 33 different frames but "drawn" 10 times each, because nothing changes in that 30ms gap.

This is why many applications and games can feel slow and stuttery while also reporting a stupidly high framerate.

1 hour ago, mSparks said:

XPs frame times are "real" frame times (big difference vs a lot of games) so all the core sim stuff happens at the reported framerate.

Does XP put ALL plugin threads (including any children) to sleep while it's running the physics and render passes? In other words, could a FM plugin spawn a child thread to do some tasks and then hold at a mutex/semaphore while waiting for XP to callback?

 

1 hour ago, mSparks said:

thats actually only 33 different frames but "drawn" 10 times each, because nothing changes in that 30ms gap.

ha! Didn't know that was a thing. Not surprising.

2 hours ago, oldflyguy70 said:

My opinion of the JF Turbo Arrow model is pretty low FM and systems wise.  Having flown a real (normally aspirated) Arrow during CPL training, the JF model for MSFS is way off the mark

Oh, yeah. This definitely falls into the “what the heck were they thinking” category. No one who has ever flown an Arrow of any type would have signed off of that pile of hot garbage 😂

3 hours ago, oldflyguy70 said:

Full disclosure - I spend most of my sim time in XP.  But if this A2A thing is as good as some folks are saying I can see using it A LOT.  

As an unabashed xplane / SimCoders / AFL fan, A2A is absolutely worth the time.