P3D: 64-bit development appears hopeful ;o)

[virtuali 4,421]

Neither UTX, GEX (I assume that's what you meant!), or GSX use 4096x4096 graphics.

 

And GSX (at least its entire program logic) runs externally from FSX in a separate process (Couatl.exe), which has its own separate VAS space, which can use up to 4 GB on its own.  The only things GSX creates that take from FSX memory, are service vehicles created by FSX, under GSX command, but a complete service crew has likely the same impact of a couple of AI planes more.

 

As I've said in another post, a possible chance for airplane developers to save some memory would be using a similar approach to run at least program code outside their gauges in an external process, something like an FMC using a large database could probably benefit from it. Or any kind of complex systems simulation, there's really no reason to have them running in-process with FSX.

[virtuali 4,421]

Ahh, the 64bit silver bullet discussion again. Love it.

 

Well, just to put a realistic perspective on it: right now having an hard limit on 4GB is not even so bad, because it forces users to *think* about what and how much they are installing, and it force developers to try to optimize their stuff.

 

When the limit will go up from 4GB to 8TB (or, more realistically, 192GB, which is the maximum amount of Physical memory Windows 7 Professional can see), people will keep stuffing things, so the FPS will then go down to unusable levels before being able to see an OOM message...

[tf51d 284]

 

As I've said in another post, a possible chance for airplane developers to save some memory would be using a similar approach to run at least program code outside their gauges in an external process, something like an FMC using a large database could probably benefit from it. Or any kind of complex systems simulation, there's really no reason to have them running in-process with FSX.

 

P3D claims to have this capability with a module in their SDK called ExternalSim, where code for aircraft, can be run outside the sim in it's own address space. I'm not aware of anybody actually using it yet!! A2A codes their own fight model with Accusim, but that still runs within FSX.

[mgh 89]

 

P3D claims to have this capability with a module in their SDK called ExternalSim

 

So does FSX with SimConnect.

[virtuali 4,421]

P3D claims to have this capability with a module in their SDK called ExternalSim, where code for aircraft, can be run outside the sim in it's own address space. I'm not aware of anybody actually using it yet!! A2A codes their own fight model with Accusim, but that still runs within FSX.

 

That's a built-in feature to ease the override of the *flight model* of an object, but it could be done in FSX+Simconnect too, by simply froze the object and send xyz/pbh data that were calculated elsewhere, P3D makes it just more elegant, but the final effect it's the same.

 

My point was more general, related to the overall system simulation, which can be complex and, especially when external data of unknown length (think navigation databases) must be handled, moving such code outside FSX makes perfect sense, considering this kind of data doesn't even need strict synchronization with the video frame rate, so it's not time critical for perceived smoothness.

 

Such code will also get multi-threading and spare core allocation "for free" without the developer having to code anything, because Windows by default will handle threads started by a different process (another .EXE) to CPU cores with available processing time. So, for example, an FMC stuck for any reason into a complex calculation, won't slow down FSX in any way, the most it will happen is the result of that calculation might appear a second later, but it will run entirely in the background, without having to write tricky multi-threaded code.

[Guest]

 

FSX may just need 50MB to load the scenery, but if your largest contiguous space is only 40MB, the Application will OOM! That's why it's necessary to clear as much space up front so that space is available later on.

 

I agree with your statement, but it's pretty unlikely FSX is going to request a 50MB at any "single" point of memory allocation.  It may need to load 50MB worth of data but I'm pretty sure that would be over several (actually many) allocations not just one ... one would have to run an application profiler to be sure but it would surprise me if FSX loaded a multi-section file with just a single allocation (especially when data within the file can define what needs to be allocated).

 

Even a 90MB .bgl would NOT all be loaded via a single allocation, more likely scenario will be many allocations with most being dynamic  -- the file header "It consists of a fixed length section of 0x38 bytes and a variable number of section pointers, each 0x14 bytes long.", section header i.e. "Each section header consists of a variable number of subsection pointers of 0x10 bytes length", airport records, scenery objects, etc. etc..

 

.agn files are also very small

 

Even texture files ... the largest one I've seen is 6MB but they are typically <1MB

 

.mdl files can be large sometimes (I've seen a 20MB) but again, they are sectional and most likely have many allocations during it's read/load process.

 

I'm pretty sure FSX is C++ and Assembler, so it must be using some form of OOP and structure allocations.