Has MS released any info to confirm if Flight will be a true 64 bit game? I really hope so, if they are not providing any backwards compatibility why not just make a clean break and build it for the future and for exclusive use on Windows 7 64 bit machines.Mark.

Then what do you tell your target market, many of which are still using XP 32, Vista 32, or Win 7 32bit?And again, we are not the target market, the casual simmer/gamer is.My understanding is that it will be 32 bit.

Then what do you tell your target market, many of which are still using XP 32, Vista 32, or Win 7 32bit?And again, we are not the target market, the casual simmer/gamer is.My understanding is that it will be 32 bit.

You´re right on this. They try to make it as usable for most systems as possibile. But it would be good if they would do two versions and you can choose upon install whether you want to install the 32 or the 64 bit version.

IMHO, if the code base is clean (i.e. has been written with 64 bits in mind / does not reuse incompatible legacy code), it's only a question of compiling for both address models. So we could have both versions. Actually it could be a good indicator of how much the code has been rewritten (with modern coding practices). While a 64 bits version would be nice as it would permanently fix the infamous OOM that some power users encounter, a 64 bit OS solves the problem most of the time since it let the game use a full 32 bit address space (ie 4 GB). I don't see it at a priority as it doesn't have much effects on the performance.Morevoer the SDK states that "The recommended method of writing an add-on is to build it out-of-process, as an application (an .exe file) rather than in-process, as a library (a .dll file).". That way the addons should not "eat" the address space of the game leaving a full 4GB for the simulator.Mark, what were your motivations for 64 bits ?

Not that there can't be a first, but has MS ever released a game title under both 32 and 64 bit at the same time? I don't know so that is why I ask!

Not sure for Microsoft, but 64 bits games are definitely out there for a few years. An interesting read :http://www.tomshardw...aming,2250.html

IMHO, if the code base is clean (i.e. has been written with 64 bits in mind / does not reuse incompatible legacy code), it's only a question of compiling for both address models. So we could have both versions. Actually it could be a good indicator of how much the code has been rewritten (with modern coding practices). While a 64 bits version would be nice as it would permanently fix the infamous OOM that some power users encounter, a 64 bit OS solves the problem most of the time since it let the game use a full 32 bit address space (ie 4 GB). I don't see it at a priority as it doesn't have much effects on the performance.Morevoer the SDK states that "The recommended method of writing an add-on is to build it out-of-process, as an application (an .exe file) rather than in-process, as a library (a .dll file).". That way the addons should not "eat" the address space of the game leaving a full 4GB for the simulator.Mark, what were your motivations for 64 bits ?

You're right on the money!A serious problem with FSX is lack of memory (it's not 4 GBy, rather 4 GBy minus whatever the OS needs minus the size of the window to access video RAM), so a 32-bit version of Flight would be seriously lacking WRT to address space size (unless optimized with out-of-process modules as you indicate).But the "mass market" of casual simmers would likely require a 32-bit version of Flight.So MS could release both versions iff the code is re-written or adapted to allow a 64-bit compile: As you pointed out, if code is written properly compiling for 32 or 64 bits is just a compile-time switch away.Cheers,- jahman.

Mark, what were your motivations for 64 bits ?

My Marshall amp goes to 11 and I want my FS game to be bigger and better as well !!! Honestly, I have no motivation other than thinking the game would perform better in terms of OOM errors and integrate better with Windows 7 for improved performance. I may be dead wrong on this point, but it seems logical to me.http://www.youtube.com/watch?v=ll7rWiY5obIMark.

There is a series of pages on Tom's Hardware cmparing 32-bit and 64-bit beginning here:http://www.tomshardw...ing,2250-6.html The conclusions include:".... With the exception of Grand Theft Auto, none of the games we tested demonstrated any appreciable speed-up. But this is to be expected, according to a wealth of performance data posted all over the Web and confirmed by the IHV and ISV representatives to which we spoke. The magic of 64-bit computing isn’t what it does for performance. Rather, the real story is what it does for game while it’s in development and then for stability when it’s in the hands of the gamer. Of course, you must remember that a 32-bit application without /LAA enabled is still limited to 2 GB of virtual address space, even in a 64-bit environment."This suggests that simply using a 64-bit alone can't be expected to produce dramatic improvements in speed compared with 32-bit when using the same code. This is supported by results from http://blog.tune-up....re-performance/ This shows no change in frame rate for Crysis - f21 fps with 32-bit and 2 GB Ram to 22 fps with either 32-bit or 64-bit and 4 GB RAM. This was using the 32-bit and 64-bit versions of Crysis.

64-bit addressing will provide a performance boost when the working data set is > 4GB. If Flight can push the memory usage beyond 4GB it would certainly benefit from 64-bit addressing.

This suggests that simply using a 64-bit alone can't be expected to produce dramatic improvements in speed compared with 32-bit when using the same code.

The increase in average FPS for 64-bit Flight would be rather dramatic if you include the 15 min it currently takes for FSX to reload after an OOM CTD :-)64-bit was never about speed and añways about OOM CTDs. In fact, other optimizations notwithstanding, 64-bit code is slower because many of the address pointers are twice as large, thus filling-up code caches faster and lowering the cache hit ratio and also making I/O transfers longer, again due to added pointer length. You can even compare 32-bit vs. 64-bit the exe file sizes to get the idea.Then again as others pointed out, out-of-process add-on modules could reduce Flight's max memory footprint, but perhaps the increase in IPC-Inter-Process Communication could slow the program down.Cheers,- jahman.

Out of curiosity I used Process Explorer to check FSX's actual memory usage. My FSX has only default scenery and I flew the default B747 out of Heathrow. During take-off and climb to 10,000ft I found that:Virtual Size varied between 674 Mb and 690 MbPeak Working Set was 435 MbPeak Private Bytes were 466 Mb.Virtual Size is the total amount of virtual address space used, Working Set is the number of bytes in physical memory, and Private Bytes is the virtual memory that can't be shared with other processes.This suggests that default FSX is nowhere near the 2Gb limit with obvious implications.

As a check I repeated the flight using the default B747 out of Heathrow using default scenery. I moved all the sliders to the right and ticked all the boxes.This shjould represent the worst casse - it certainly killed my frame rate < 3 fps!. During take-off and climb to 10,000ft I found that:Virtual Size varied between 1,218Mb and 1,249MbPeak Working Set was 552 MbPeak Private Bytes were 932 Mbas I said previously, Virtual Size is the total amount of virtual address space used, Working Set is the number of bytes in physical memory, and Private Bytes is the virtual memory that can't be shared with other processes.This still suggests that default FSX is nowhere near the 2Gb limit - its Virtual Size is less than 1.3GbPS: I've reposted my last posts in the FSX forum becsuse I think they my be of wider interest.

64-bit addressing will provide a performance boost when the working data set is > 4GB. If Flight can push the memory usage beyond 4GB it would certainly benefit from 64-bit addressing.

The correct statement is "64-bit addressing will enable working data set > 4GB". This is a common mistake to believe that "the more data/memory used, the better perfomance". Actually it is quite the contrary : "the less data the better chance they are in the processor cache".Let's play Process Explorer (rather than flying) :My scenario is a PMDG MD-11 flight with a little bit of traffic, and standard sceneries :Peak virtual Bytes : 1.8 GBVirtual size : 2.026 GBPage Faults : 11 486 041So the plane seems to matter which is confirmed by the fact that OOM usually appears only with hardcore aircraft.Since I have been using a 64 bits OS, I don't get OOM. So FSX never get to the 4GB limits (which is standard for a 6 years programm).

What is the issue currently? 32 bit apps run in a 64 bit environment, and if the large address aware flag is set, then it can access 4Gb of memory space. I haven't seen FSX OOM on my 64 bit Windows 7 HP install yet.I have heard that you can get close to the 4Gb 32 bit limit in FTX with heavy addons (MD11X or B744X) and a heavy airport (with the appropriate settings activated) such as YBBN, though I would not say that it is a classic OOM or not, as I have never seen it happen personally (I have YBBN and the MD11X, though my more moderate settings, which suffice, do not cause OOMs or crash of any kind)If Flight comes out within the next 12 months, I would personally be a little surprised to see both 64 and 32 bit editions... it would possibly be a first though...Andrew