when P3DvX.X is finally made 64bit, what will be the next thing to seized upon for a whipping boy?

 

Most likely all the 3rd party vendors claiming they are going bankrupt because it's not backwards compatible ...  some however will look at it as an opportunity and will flourish. 

It seems like it was either kill backwards compatibility or change to 64-bit core engine as far as the current iteration of version 2 goes.  Was everyone ready to bail on backwards compatibility, which I think might have meant sticking w/ only default packaged aircraft/scenery/weather/etc and wait maybe a year+ to see anything else available, or get 32-bit out the door to keep interest alive and allow, dare I say, a very many previously purchased add ons to remain functional in large part?  I think the right path was taken for sure! This being said, we all hope they are working hard to develop the new 64-bit platform and hint-hint while they're there please develop a killer default ATC!   Core engine, basic scenery and a few planes, canned weather, and a better ATC would be in the basic package w/ the robust 64-bit SDKs which I think LM has already been developing.   They're on it it seems obvious to me, but their decision to release a V2 certainly grabbed some attention for folks like myself who were in no way interested in the 1.4 version.

 

Kudos to LM for the path they've taken.  Plus bonus, it works quite good already and some patches are coming along it seems.

 

 

P3D V2 needs to go 64 bit... bottom line

 

^

Most overused and overrated comment regarding P3d2.

 

If anyone wants a 64 bit flight sim, buy XP10. It works fine. If you want a flight sim that is a retooled and modernized FSX, buy P3d2. P3d2 also works fine. It's that simple.

It seems like it was either kill backwards compatibility or change to 64-bit core engine as far as the current iteration of version 2 goes.

 

Not sure I understand the "one or the other" philosophy?  Why would developing a 64bit version exclude there being a 32bit version (and compability)?  LR (XP10) have both a 32bit and 64bit and even cross platform versions.  Why should there be just one path for P3D? 

 

I'm not trivializing the challenge to move the code to 64bit, but V2 seemed like the perfect opportunity to offer a 32bit AND a 64bit product.  The same debate was brought up back in 2006 (8 years ago) for FSX ... I'm kinda surprised this debate is still living on today ... I'm puzzled from a technical and design perspective ... why support such high levels of detail when it can rarely (almost never) be utilized in a 32bit address space regardless of CPU/GPU/RAM hardware now or in the future?

 

I haven't heard anything official from LM that they are working on a 64bit product in addition to their 32bit product?  I've read it's something they will "consider" but it's not been placed on any official version/release schedule I'm aware off -- if you have more confirmed info of a P3D 64bit product please link me to it.

 

Don't get me wrong, I'm VERY glad P3DV2 is here "as is" with all it's issues -- it has clearly demonstrated the need for a 64bit option.  Like I said, I'm 100% sure LM know 64bit has to happen -- hopefully it's just a matter of when, but who knows.

 

I'm a strong supporter of all things flight simulation across many platforms, and I'm very able to turn a blind eye ... but just because I turn a blind eye, I don't ignore the bigger picture for the future of flight simulation ... if I really enjoy this hobby, I owe it to the hobby to have due diligence and take note and discuss some of the challenges for original content provider (LM), 3rd party, and end users.

 

But to sum this up "It's time to take the next step, have no fear."

Apparently, it is not just the amount of VAS showing on the monitor, but "heap fragmentation issues" that can cause a sudden, massive spike in VAS that does not even show up on a VAS counter. LM has said that this is a bug that occurs at high autogen settings and is likely the reason that OOMs have been eliminated for me by moving from very dense to dense (my OOMs always occurred with lots of free VAS showing on the counter). In any case, LM is on it, and we can hope for a fix.

 

Yes, that is true -- I got OOM errors when I get these memory spikes. 

 

 

If you want a flight sim that is a retooled and modernized FSX, buy P3d2.

 

Not sure I understand you there?  Are you saying 32bit is more modernized than 64bit?  Think I'll have to disagree with you on that one sir.

^

Most overused and overrated comment regarding P3d2.

 

If anyone wants a 64 bit flight sim, buy XP10. It works fine. If you want a flight sim that is a retooled and modernized FSX, buy P3d2. P3d2 also works fine. It's that simple.

 

That makes absolutely no sense.  No one goes out and says "I want a 64 bit flight sim."  It is quite simple... I want a flight sim that does not crash all the time... period.  I don't care about 32 bit vs 64 bit as long as it is a reliable simulator. 

 

The "retooled and modernized" FSX likely requires 64 bit at this stage because of the fact that it is trying to do so much more with the old 32 bit architecture.  It's like trying to extract more horsepower from a car where the engine is nearly maxed out.  If you do not beef up the internals (i.e. forged internals) to handle the extra horsepower, you have a blown motor.  Same thing with P3D V2... the extra eye candy necessitates better architecture... if they can find a reliable method of keeping memory in check without 64 bit, terrific.  But I will believe that when I see it.

 

Ironically, this "retooled" and "modernized" sim crashes significantly more often than the antiquated FSX... and this thread is solid proof of that. I never had issues with FSX default aircraft causing OOM's.  That is just silly. 

Not sure I understand the "one or the other" philosophy? Why would developing a 64bit version exclude there being a 32bit version (and compability)?

 

Surely unless the 32-bit  version is "frozen" then it will be necessary to develop two versions in parallel at additional cost? 

modernized FSX.

 

 

Ironically, this "retooled" and "modernized" sim crashes significantly more often than the antiquated FSX

 

For you maybe. Not for me.

Surely unless the 32-bit  version is "frozen" then it will be necessary to develop two versions in parallel at addition cost? 

 

With modern development tools (which I know LM are using) this should be a single source code base.  TFS - (team foundation server) makes it very easy to manage this situation (source code) along with conditional compiler directives in the source.   Two different final builds (one for 32bit and one for 64bit).  Data files, BGL, AGN, DDS, BMP, etc. shouldn't require any modifications.

 

Cross platform is another matter, but P3D isn't cross platform.  

 

So once it's initially done (the hard work), it's not really a major effort to manage 32bit and 64bit paths ... of course developers need to be aware moving forward, but that's assumed.  But like I said, I doubt there is a single core developer at LM that would disagree that P3D needs to have 64bit option -- the PM's and funders, well that's an entirely different matter.

 

Laminar Research have been doing 32bit and 64bit for some time and Austin has indicated it's realtively easy to manage both, Ben has even claimed cross platform is pretty easy to maintain.

 

 

Is there a reason why you're not running with 'wideview aspect' checked? I also notice on your shadows you have "noshadow flagged content" checked, what is that for? You're on a 6gb GTX 780 Titan right?

 

No wide view is just my personal preference.  The respect no shadow flag content (checked) means if there is any 3rd party content using this option, it will not receive or cast any shadows ... I believe the folks at FlyTampa actually removed this flag from their Dubai v2.3 release so as to allow buildings/terrain to receive and cast shadows.

 

I have a 6GB Titan OC.

Two different final builds (one for 32bit and one for 64bit).  Data files, BGL, AGN, DDS, BMP, etc. shouldn't require any modifications.

 

But that assumes that they are both effectively the same application. I'd suggest that it's more likely that there'd be other changes made at the same time - after all much of v2.0 is still based on FSX/FS9...

 

 

But that assumes that they are both effectively the same application.

 

Why would they be different?

 

Compiler directives should be able to handle any cases where something has to be specific to one or the other path.  Visual Studio supports "Target CPU" (x86/x64) and DX11 has 32bit and 64bit runtimes.  SlimDX (DX11 wrapper for managed framework applications -- which I know LM use but to what extent I'm not sure) has both x86 and x64 for .NET 4.0 framework.  LM indicated they have converted ALL vestiges of the "Assembler code" into C++ equivalent.

 

Again, not trying to trivialize adding/enhancing the code for a 64bit path ... but from what I know, I don't see anything that would deem the process "impossible" or not "feasible". 

 

 

 It might make sense for LM to add a more granular settings for AutoGen rather than what appears to be drastic changes in AutoGen.

Rob,

There was a thread that discussed a granular autogen setting parameter within the config file.  Below is a link to that conversation starting in entry #24, which I also have copied below.  Might be worth giving it a try in order to incrementally affect autogen density.

 

The link:

http://forum.avsim.net/topic/429435-some-good-comparison-screenshots/

 

Excerpt from Entry #24:

I played with two new settings in the config.. Oh lordy.. You can amp up the auto-gen to ridiculous amounts.

 

Max auto-gen / LOD 6.5

 

Default = 

 

AUTOGEN_BATCH_LOD=2

AUTOGEN_TREE_LOD=2

 

Edited = 

 

AUTOGEN_BATCH_LOD=0

AUTOGEN_TREE_LOD=0

 

Those are independent from auto-gen tree/building density. 

 

Warning -  2MB+ GIF!

 

:Hypnotized:  SO-MUCH-AUTO-GEN

 

http://farm8.staticf...eb890fb63_o.gif

 

Edit: Lockheeds explaination of these settings and how to use them

Quote

Hey Mr. Bill,

The updates to the auto-gen system allow us to render greater numbers of buildings and trees without the same performance hit they used to have, which is what enables the pop-free auto-gen. When the new system is enabled, scenery tiles are loaded at the LOD specified by that config option. The numbers go from 9 to 1, with one being the highest. Don't set it to zero, as that might blow up in some areas. As a few folks have noted, the auto-gen directly below the plane is a little less dense by default, because the system only loads the second highest LOD. Experimenting with the LOD in the config just provides another way to adjust the density of scenery loaded, but since both the slider and the config option do similar things, we left one in the config for our more adventurous users to play with if they wished. Be warned that increasing that setting to 1 will in many cases double the number of buildings and trees again, making it potentially very expensive. 

 

Zach Heylmun

Software Engineer - Prepar3D® Team 

 

 

 

 

 

I'm not trivializing the challenge to move the code to 64bit, but V2 seemed like the perfect opportunity to offer a 32bit AND a 64bit product.

 

My guess is that LM knows all of this quite well but w/ their current actual resource allocation they made a business decision to forego 64-bit for the reasons I mentioned:  no one will be using their massive collection of FSX add ons were to the chose 64-bit over enhancing 32-bit.  So from there I think if they had the funding they would have done both and taken advantage of this 'opportunity'.

 

 

So from there I think if they had the funding they would have done both and taken advantage of this 'opportunity'.

 

I have no idea what LM's funding situation is ... but whatever the reason, the same decision was made (to not provide a 64bit path) 8 years ago with Microsoft/Aces.

 

Anyway, just have to make the best of the situation and remain positive.

 

 

Edit: Lockheeds explaination of these settings and how to use them

 

Hi Mike, yeah I read that, I think the warning at the end suggesting it could be "expensive" is steering me clear.  I think right now I'd rather have an OOM free experience ... plus there are some products due out that I want and I know they will stress out VAS also (FSGRW and the FTX OpenLC products).