Question for Developers

[Tabs 2,790]

Yes, that's correct - you'll get engine sounds but not the other panel sounds. The 777 is fully compatible with it once SP1 releases and I'm sure we'll add same functionality when we update the NGX again.

[WebMaximus 372]

Many thanks Ryan!

[3-2-1-Now 126]

Full geometric path VNAV that takes into account both altitude and speed with all manner of soft and hard constraints, variable target descent speeds and limits, autothrottle logic etc is very heavy math. (There's all kinds of calculus and differential equations involved in doing it) Look at what our LNAV is doing too - all the turn prediction curve drawing etc - those aren't static things that get drawn once, they're dynamically generated based on the current flight situation and get recalculated with every "tick" of the aircraft's system timers. Again, very heavy math that the Q400's route line drawing doesn't have to do.

 

Being general here, none of what is described will hurt performance, and does not explain the lightness of the MJC Q400. As for clickspot count, animations, etc.. that is also irrelevant as there are over 300 clickspots in the CBs alone, and that discounts all the peripheral animations (sun visors, moving seats, side tables, etc..) in addition to everything else that is clickable to just operate the aircraft.

 

Whatever is making the Q400 "light" on frame rate is not due to simpler systems/FMS/ND drawing, as it is bogus to assume the Q400 is "light" in these areas (or conversely, that any PMDG product is particularly "heavy", either).

 

For kicks I removed all the systems programming from the 777, and got very similar frame rate to when it is up and running, strongly hinting the model is the reason for it being....slower. In fact, I couldn't see any real difference in performance at all. You can try it yourselves by removing all the 777 related DLLs.

 

Generally speaking, the systems are the least likely to impact performance of the simulator. Crunching numbers is what processors are outrageously good at, and the computers we all use today are blisteringly quick. What still kills perf today is graphics, which is why we have crazy parallel processing behemoths we call "graphics cards", dedicated to....graphics processing. The math involved in simulating an FMS etc.. is easy for modern hardware, and in fact is several times more powerful than the real hardware.

 

Airbus FBW runs on Intel 8086 and Motorola 68010 processors, several FMS use Intel 486 processor cores, for example.

 

The 777 first flew in 1994. EDIT: A quick piece of research reveals Honeywell used Motorola 68040 processors for the 777 FMS. It is trivial for modern processors to emulate these processors on modern hardware (but that would not even be necessary in terms of the systems programming we are discussing here - if you ever used an emulator to play old Nintendo games, you emulated the 68040 processor in software and ran machine-compatible code!). Writing the same software on modern hardware should actually be even faster due to advancements in the state of the art of processor architecture and design.

 

Best regards,

Robin.

 

Robin Goodchild.

[scandinavian13 5,192]

 

 

Airbus FBW runs on Intel 8086 and Motorola 68010 processors, several FMS use Intel 486 processor cores, for example.

The 777 first flew in 1994. EDIT: A quick piece of research reveals Honeywell used Motorola 68040 processors for the 777 FMS. It is trivial for modern processors to emulate these processors on modern hardware (but that would not even be necessary in terms of the systems programming we are discussing here - if you ever used an emulator to play old Nintendo games, you emulated the 68040 processor in software and ran machine-compatible code!). Writing the same software on modern hardware should actually be even faster due to advancements in the state of the art of processor architecture and design.

 

...and each one of those systems has its own processor, which FS does not allow.

 

Surprise!!!

 

...actually, no, that's not quite a surprise since we've all been suffocated by it for years now.  Nice try, but it's not at all comparable as far as levels of system processing go.

[JB3DG 225]

...and each one of those systems has its own processor, which FS does not allow.

 

Surprise!!!

 

...actually, no, that's not quite a surprise since we've all been suffocated by it for years now.  Nice try, but it's not at all comparable as far as levels of system processing go.

 

Um...if you are doing your systems outside the sim and using only the core data (air data/position/velocities etc) then emulating separate processors is possible. IMO there is nothing that FS "does not allow". The only limits are skill and imagination.

[scandinavian13 5,192]

Um...if you are doing your systems outside the sim and using only the core data (air data/position/velocities etc) then emulating separate processors is possible. IMO there is nothing that FS "does not allow". The only limits are skill and imagination.

 

Unless you're sitting on top of some Flight Sim gold mine, your point isn't exactly realistic.

 

The current situation is one where FS itself is severly limited by not being optimized for a multi-core environment.  Regardless of how much you throw outside of FSX, you're still going to see a drastic performance bottleneck by how FSX behaves itself.  Even throwing graphics processing off onto a GPU doesn't help as much as it should.

 

His scenario referenced a situation where each one of those systems had independent processing on independet processors.  Those systems may communicate, but they're being run on separate processors (not even multiple cores of a single processor).  I was simply saying the comparison was not a fair one to make.

 

So, before you go asserting that it's all up to skill and imagination, I'd suggest you take a look into the matter more carefully.

 

Example:

FSX is limited by being a 32 bit application.  Have some clever "skilled and imaginative" way to get by that limitation?

[JB3DG 225]

Unless you're sitting on top of some Flight Sim gold mine, your point isn't exactly realistic.

 

The current situation is one where FS itself is severly limited by not being optimized for a multi-core environment.  Regardless of how much you throw outside of FSX, you're still going to see a drastic performance bottleneck by how FSX behaves itself.  Even throwing graphics processing off onto a GPU doesn't help as much as it should.

 

His scenario referenced a situation where each one of those systems had independent processing on independet processors.  Those systems may communicate, but they're being run on separate processors (not even multiple cores of a single processor).  I was simply saying the comparison was not a fair one to make.

 

So, before you go asserting that it's all up to skill and imagination, I'd suggest you take a look into the matter more carefully.

 

Example:

FSX is limited by being a 32 bit application.  Have some clever "skilled and imaginative" way to get by that limitation?

 

Well depending on whether it is worthwhile or not (like the RXP GPS units) one could store data on a totally separate process and share that info with the simulator. That does take some skill.

 

As for external systems, when I say external I don't mean just running your own algorithms to simulate a system. If you know what you are doing you can run that system on a totally separate thread/core. I wouldn't be surprised if PMDG is doing just that. I know Majestic is.

 

Heck you could run that system on a separate computer entirely and make the 2 talk via network. If im not mistaken that's what most Level-D simulators are doing in the first place.

 

Put it this way:

 

The FSX process is like a pipeline. The length of this pipe is determined by CPU power and the diameter is affected by both CPU/GPU power and available memory. The destination of this pipeline is the final frame rendered. Each instruction involved is a processing center along this pipeline. This also affects the length of the pipe. For a given CPU power more instructions means more ETE.

 

However, you can handle instructions in another pipeline running in parallel. That pipe's destination is some point along the primary pipeline where it makes a turn and connects with the primary. This external pipeline could be just another thread in the FSX process for only calculation processing, or it could be some external process that stores a vast amount of data that would cause FSX to OOM instantly. Instead the connection it provides is for just one part in any location of that data for the sim to access. In any case, efficiency is improved. It does take some skill though to prevent collisions between the minions running through the pipes at intersections though :lol: .

[3-2-1-Now 126]

@Kyle: whether it is 1 processor of 50 processors doing the job, the point is a modern computer has more than enough horsepower to do what ALL those processors do per second compared to the hardware being simulated, with capacity to spare.

 

It's the old argument of this: is 5 processes running parallel faster than 5 processes running sequentially at 5 times faster than the time required?

 

e.g. Let's assume all processes take 10 ms to process on our parallel processor. Our parallel processor takes 10 ms to operate on 5 threads.

 

If our new sequential processor takes 2 ms to process each thread, and 10 ms total, is it slower? The answer is not as obvious as it first appears.

 

For the purposes of the kind of systems simulation we are doing, the answer is it makes no difference, but it depends on exactly what it is you're looking at.

 

Best regards,

Robin.

[scandinavian13 5,192]

Okay, but the problem is that both of your theories are neglecting the facts of FSX.

 

This is still FSX.  FSX is still limited by what's out there CURRENTLY.

 

So, while your theoretical debates are somehow impressive on their faces, they don't really get us anywhere.  We could certainly talk about the benefits of parallel versus sequence, or the theory of why apples are red, green, and yellow, but not purple.  Neither of those theoretical discussions are going to help us here, though.

 

The real aircraft is an entirely different beast than FSX.  You truly cannot compare them in terms of how data is processed and communicated, especially when it comes to the performance of the systems and processing.  Quit regurgitating theory that probably came from somewhere else and come with facts.  Facts are cool.

[JB3DG 225]

Given that we are both programmers, I would hardly call this just plain theory...Not likely to lay bare the proof though as source code is rather precious.

[3-2-1-Now 126]

FSX is still limited by what's out there CURRENTLY

 

FSX has its problems - sure - but that doesn't explain away the situation we are discussing here, namely performance hit (or lack thereof) of the systems simulation.

 

Best regards,

Robin.