This whole thing sounds like they are trying to do something similar to what FSDT and Flightbeam do using Couatl and python to control the way an airport renders itself.

 

It will be interesting to see more information on this.

It hasn't been done before with airports, but it is commonplace with weather injection (ASN, OpusFSI and FSGRW are all freestanding apps), gauges (The GTN 750/650 gauge is a freestanding app) and other add-ons (Traffic Optimizer, AI Controller, TrackIR, Super Traffic Board, GSX  and a number of others). I have a post here:

 

http://forum.avsim.net/topic/463728-is-there-any-prepar3d-64bit-information/?p=3191915

 

in which I calculated that I had 500+ MB of add-ons running in their own memory spaces. Does that save 500 MB of VAS in the flight sim's memory space? Of course not, because some of the flight sim's VAS is used up just in the communication between the flight sim's exe and the add-on's exe.

 

Unfortunately, the reason why this isn't done with aircraft and airports is that additional computational overhead is introduced via this constant communication between apps. What may be gained in VAS savings in the flight sim  is lost in FPS and smoothness. It's just a stopgap approach on the way to 64 bits.

 

Thanks for the education...very interesting. 

Then while your at it add OOMs=0 under SIM section  

 

Great one George :im Not Worthy:

But if it uses an .exe file than rather than a .dll then each .exe file each has the full 4GB available in 64-bit Windows.

 

Yep, the Airport Controller is .exe, not a .dll.

 

That makes perfect sense. But if so, why hasn't everyone done it before now? I find that rather curious.

 

Among other reasons there was quite long time needed to investigate. The SDK documentation is poor, often misleading and often wrong. Also, as the FSX were developed over years, there are parts of code duct-taped together and there could be find two different approaches for stuff which appears to be logicaly the same and you'd expect the code is recycled. This is for instance the case of well-known problem light effects could be hardly positioned on a pole just by setting identical coordinates. And there are many of such places in SDK which makes usage of this aproach whatever but straighforward.

 

Unfortunately, the reason why this isn't done with aircraft and airports is that additional computational overhead is introduced via this constant communication between apps. What may be gained in VAS savings in the flight sim  is lost in FPS and smoothness. It's just a stopgap approach on the way to 64 bits.

 

Well, there will be definitelly some overhead for communication and this is one of the reasons I tried to calm down some excited expressions. On the other hand the results, especialy with LKPR, looks promising so I believe it will bring significant improvement.

 

It's just a stopgap approach on the way to 64 bits.

 

True, true, true ;-)

Making the airport use memory outside of the sim

 I've mentioned this possibility before.  Even LM can do it, utilize another application in another memory space for certain processes and just use com interfaces between them.  But as I've also said before. MEMORY IS NOT THE PROBLEM, CPU processing "bandwidth" is the issue.  You can have a whole water tower full of water, but if you only have a 2" pipe you won't get any more water.  We are still at the limits of what the CPU can do.   Once DX12 (Which will hopefull help DX11 a little) comes along, with MS finally fixing their decades old fiber management issues, the P3D team has positioned themselves right where they want to be to race ahead.

Well, there will be definitelly some overhead for communication and this is one of the reasons I tried to calm down some excited expressions. On the other hand the results, especialy with LKPR, looks promising so I believe it will bring significant improvement.

 

 

I hope you didn't take my comments the wrong way as I believe that what you are doing something innovative that will set the tone for other developers.

 

The 4 GB VAS limit doesn't matter if one is flying the default Cessna around in FSX. But load up a complex aircraft like the PMDG 777 and then take it on a long haul flight with a ton of add-on scenery also active and one is pretty much assured of having one of those "Oh glob!" moments.

 

Complex airports that don't add to the 32 bit OOM problem are sorely needed.

This whole thing sounds like they are trying to do something similar to what FSDT and Flightbeam do using Couatl and python to control the way an airport renders itself.

 

It will be interesting to see more information on this.

The first thing I thought of when they said it was licensed, was that it was from FSDT since they are the only ones I know of who developed such an "airport controller" that runs outside of the sim. Whether that is in fact the case, I couldn't know. That was just what entered my mind as soon as I saw that statement from Mathias. My next thought was, if it is licensed from someone else, how revolutionary can it be?

I hope you didn't take my comments the wrong way as I believe that what you are doing something innovative that will set the tone for other developers.

 

Not at all Jay, don't worry.

More than that, I'm glad people are presenting clear reasons out why it's not revolutionary. 

 

 

The 4 GB VAS limit doesn't matter if one is flying the default Cessna around in FSX. But load up a complex aircraft like the PMDG 777 and then take it on a long haul flight with a ton of add-on scenery also active and one is pretty much assured of having one of those "Oh glob!" moments.

 

Complex airports that don't add to the 32 bit OOM problem are sorely needed.

 

Yes, exactly that I have in mind when first time appeared "no more OOMs" - that scared me.

There is so much involved we could not affect that I believe the appropriate approach here is "Never say never!"

 

 

The first thing I thought of when they said it was licensed, was that it was from FSDT since they are the only ones I know of who developed such an "airport controller" that runs outside of the sim. Whether that is in fact the case, I couldn't know. That was just what entered my mind as soon as I saw that statement from Mathias. My next thought was, if it is licensed from someone else, how revolutionary can it be?

 

No, it's not from FSDT. Umberto's approach is somewhat similar, but we went our own way. And to be more specific - when I say "we" I mean XHT Labs.

No way software operating inside an operating system can define to that OS where and how VAS is used.

Offsetting thread load is one thing, but I can't see the technical argument by uitlising a dll outside of the sim - it still uses VAS address space inside the OS.

Unless the dll can be run on a separate computer of course.

That's not how VAS works, and it won't be a DLL but a EXE. VAS is the virtual address space the OS allocates to each process for a 32bit app on a 64bit OS that's 4GB. This is how you can run more than 1 application at a time in Windows. So take GSX for example you have FSX with it's 4GB VAS and GSX runs under the external application Courtl.exe with it's 4GB VAS.  The OS manages how actual memory usage Physical memory (RAM) and data paged out to Virtual Memory (VM - Not to be confused with VAS). This is where having greater than 4GB RAM on your system comes in handy as  the system won't have to page out memory as often the more you have, making your system run faster and smoother. FSDT does something similar with their airports but instead of doing it with an external app they do it with their Addon Manager DLL, which of course doesn't help the VAS situation since DLL's run inside of FSX. I wonder could this concept be used in more global scenery like FTX Global? If so that would significantly cut the VAS footprint down in FSX or P3D.

The first thing I thought of when they said it was licensed, was that it was from FSDT since they are the only ones I know of who developed such an "airport controller" that runs outside of the sim. Whether that is in fact the case, I couldn't know. That was just what entered my mind as soon as I saw that statement from Mathias. My next thought was, if it is licensed from someone else, how revolutionary can it be?

What FSDT does with airport scenery doesn't run outside of of the sim. It's external in the sense that uses a different method of injecting scenery into the sim, but since it does this through the Addonmanager which is a DLL it's still running within the SIM. Which is why it doesn't help the VAS issue. Their GSX on the other hand does run outside the sim through there Courtl.exe application.