most importantly, kept an ancient and passionate, and deeply knowledgeable user base in tact.  I don't think there is another publicly available software that has more fanatical critical core users.  I can't think of another game that I've ever seen either where the users are so on top of the game developers.  It's a gift and a curse 

 

 

 

spend a few minutes on the avenger's alliance forums and fsx/p3d users will start to look like a paragon of civility, patience, and decorum

 

cheers

-andy crosby

 

 

Autogen_batch_lod is for building?



Autogen_batch and the sliders seems to do similar things in the end i.e. modulating the level of autogen. Why bother to change cfg if we can achieve the same results with the sliders?

 

Yes AUTOGEN_BATCH_LOD applies to buildings (as far as I recall; all information on these entries seems to have been taken out of the Learning Centre/Tuning Guide; I could have sworn they were mentioned in there in the V2.0 version; I looked them up juts the other day!. Also no mention of them from the devs on their forums, but before, again I seem to remember these settings being described before as "advanced user settings"; Just spent a half hour searching over there)

 

 

These settings appear to do a similar thing to density sliders, but actually are not identical. The LOD .cfg entries thin out autogen, reducing the number of trees or buildings that can display at a given density slider setting (if numbers are set higher - max value 9), or increasing the numbers of autogen items, if LOD numbers are set lower (min value 1).

 

In the FSX .cfg file one could do the same by directly limiting the number of trees or buildings with;

 

[TERRAIN]
TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=800
TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=1000

 

A trick I use to manage VAS in that platform for using the PMDG777 etc without ever having OOMs

 

Hope this helps

 

Rob

 

 

Interesting find, indicative that it may have a coding problem.

 

Well, this find was what led me to react abruptly to 2.1 as troublesome as it was one of the first planes I used, and having used it extensively in 2.0 w/o this problem I assumed something had changed, in 2.1 that is, because I didn't change anything in the QW757 and in fact didn't upgrade to SP3 on that since SP2 worked fine in 2.0.  Maybe the hot patch addresses whatever changed in 2.1 that might be contributing to this so I'll try again tomorrow and see if maybe I left the hot patch too quickly.  

Hello John,

 

Here was my original post that initially got naysaying, then as people continued trying discovered there is merit to it.  Since I made the post I've discovered the best of all combinations I've tried, and by best I mean best AA + best water + best performance, was the following:

 

In-Sim:

• AF: 16x
• FXAA: Off
• MSAA: 4x (can use 8x w/ small hit)
• Frame Rate:  UNLIMITED
• VSYNC:  ON (I have a 60Mhz display)

nV Inspector:

• AA Compatibility DX1x:  Bioshock profile
• AA Mode:  Override any application setting
• AA Setting: 8xS   (this is not the best for runway lines compared to SUPERVCAA 64x_4x, but it's much better for REX4 water using the DX11 textures)
• AA Transparency Supersampling:  4x Supersampling
• Anisotropic Filtering:  Application-Controlled
• Texture Filtering-Neg LOD Bias:  Allowed

Good luck--what really amazes me most is that the distance swimming textures has virtually completely disappeared, and of course runway lines/thresholds are vastly improved.  I'm amazed there isn't more consensus from others on this.  AA could be improved as I mentioned above, but it's quite decent now.  I can get SUPERVCAA on but somewhat frequently when an initial flight loads it will be a black screen, though the AA is superior than w/ 8xS.  With 8xS I never get the black screen issue.

Wow Noel thanks for that, what an improvement. Just setting up my new pc and your suggestions were just what I needed do get a quality display. Thanks again :smile:

Please explain to me how a VRAM memory of more than 4GB (or actually about 3.5GB accessible because some is lost to overhead) is accessed in a 32bit program?

 

There was once a day when RAM was nothing more than a way to speed up disk access - to make a copy of what was on disk in a place that it could be accessed faster.  That really hasn't changed.   32bit programs can communicate in parallel if you know how to do that.  That's what 64bit is, it isn't just more memory.

Your argument appears to be that even were P3DvX.X made a 64bit application it still wouldn't achieve the goal because the video card(s) presumably would still be using 32bit addresses.

 

This is a non-sequitur simply because the VRAM of the video card is not mapped to any of the systems' VAS table with a 64bit OS.

 

But, even if it were, it would share a portion of the operating system's VAS table, not the application's VAS table.

Wow Noel thanks for that, what an improvement. Just setting up my new pc and your suggestions were just what I needed do get a quality display. Thanks again :smile:

Nice!  I still see others bemoaning AA in P3DV2.x and it puzzles me and makes me wonder if they aren't setting up exactly the same.   I went back to AA=SUPERVCAA_64x_4x  yesterday and noticed w/ the particular wave animation I'm currently using it looks as good as AA 8xS but there is a small performance hit of maybe 6% or so, but AA line edging is a little better so you can try that and see how it goes.   Glad it helps it certainly does here and makes P3D V2x pretty much as good as the AA I had in DX9/FSX.   

Nice! I still see others bemoaning AA in P3DV2.x and it puzzles me and makes me wonder if they aren't setting up exactly the same.

 

Because it doesn't seem to work for all, and there can be a huge performance hit, unlike the same, or similar settings in FSX.

 

I have been playing with NI this evening and was getting load of glitches and anomalies [weird fizzing blocky textures] using Supersamling, with my current drivers, until I tried AA_MODE_REPLAY_SAMPLES_FOUR ....this mode eliminated all the glitches, but seems to give very nice clean runway marking in combination with 4xS, and no issues with water. I've yet to test this combo fully, but there seems to be little performance hit.

 

Still running max Autogen and have not encountered a single issue or oom... I'm not expecting it last, and I don't intend to always push the sim this hard, but for now I ain't complaining.

Because it doesn't seem to work for all, and there can be a huge performance hit, unlike the same, or similar settings in FSX.

 

If the driver is the same, and processing power is comparable, then yes it's a puzzle to me why it doesn't seem to work for all.  My first guess would be that something is different in the other users' setup, that is not identical to my own setup, provided the driver is the same and the GPU is comparable.  There is NO huge performance hit here.  There are only a zillion variables that could be different, so yes my first guess would be the two systems are not set up identically, rather than some random, unaccounted for behavior.  Outside of not posting the driver, I think I've posted everything else I could think of.  ALL other settings in NI were left to default, except I use the single display optimization.

If the driver is the same, and processing power is comparable, then yes it's a puzzle to me why it doesn't seem to work for all.

 

 

In those cases it should, but in computing there seems to be no such thing as 'all things being equal'.... I think most people with powerful GPU's can run NI with those settings, but lesser cards seems to struggle more than in FSX... but this is because P3D does use hardware differently to FSX, to some degree anyway.

 

I am getting the best performance + stability I have yet had using v2x.... whether this is because of the hotfix, or because I've turned off Pop_Free or the modded driver [334.95] I'm using I don't know... apart from an odd stutter, and agn spike everything is glorious.

 

To get around the shadow bug with the recent nV drivers I'm running shadows at 'Med' on the slider, but have edited the cfg to push the distance to 'Ultra'... and the above NI setting seem to work really well for me... not sure what this AA_MODE_REPLAY_SAMPLES_FOUR supersample mode is all about, but its working for me.

it still wouldn't achieve the goal because the video card(s) presumably would still be using 32bit addresses.

 

Not that.  It would make the goal easier to achieve, and in the long run, because hardware will run away with 64bit, leave 32bit in the dust.  But it is not the only path *at this technological stage with hardware* because you only have so much speed and memory to play with *at this stage*.   2 years from now it will be a different story.  That's when I'll start whining about 64bit.  But even then if they don't master scheduling (which they already are) there might be problems.  For sure everything would run hot and messy.

 

My whole point is many people are looking at their VRAM use and seeing it maxed out now with 32bit.  What magic does 64bit have that will fix that?  People are forgetting that RAM and VRAM have the same purpose, to make it so you don't have to do a read/write for everything.  We only have VRAM because card manufacturers are pushing speed, which is awesome, but there is only so much of it PHYSICALLY to use, that 32bit really is pointless in 2014.  2 years from now when 6 or 8 or 12GB VRAM is ubiquitous it will matter.  It just doesn't now.   What will matter very quickly, and LM says it's whats for dinner, is SLI.  Getting that up will end all of these 64bit magic perceptions, because SLI speed is the one thing that hasn't been thrown into the mix now.

 

Also, always remember OOMs are a unhandled errors.  The proper response from a developer is to figure out why it is happening, and handle the error so the program continues to run.   I promise you you can still get memory related issues that are just as serious in a 64bit code.  You're just not going to see them as obviously, but they can create nasty bottlenecks at the CPU or GPU, and you'll still get stutters.  Without doing what the P3D team is doing now, creating functions to track the memory closely, they won't be able to fix those either.

 

I wrote my first program on an 8bit system.   It's interesting that P3D2 naysayers are beating it down ... with a 7 year old 32bit program.  

 

 

handle the error so the program continues to run.

 

I suspect they're already doing something like this. 

 

What happens if you attempt to allocate memory and it fails?  You get a null pointer returned.  When this null pointer is passed to another module, bad things happen.  My event viewer shows a lot of these.

 

So, how do you handle a failed memory allocation? 

 

Hook

you test for the null

That's how you TEST for it.  How do you HANDLE it?

 

Hook

You keep track of what your program is doing, know your limits, and keep within them.  Trim back, or um ... allow expert users to trim back with some sliders.  You don't make the call for memory in the first place.

 

 

You don't make the call for memory in the first place.

 

That's actually the most likely scenario.  The memory is allocated in a different thread which doesn't check for null pointer returns or ignores them because there's not much the program can do, or that part of the program isn't called.

 

Now, WHY could you get a failed memory allocation?  Well, even if you have plenty of memory left, it could be fragmented to the point that a malloc call can't get enough free contiguous memory.  This seems unlikely but possible, but the allocated blocks of memory that are passed to various modules (via pointer) shouldn't be that large.

 

It's very unlikely to be corrupted pointers, as the pointer values sent to the modules aren't garbage.

 

This is from a programmer's viewpoint, not a user's.

 

How can we fix fragmented memory?  Garbage collection of some sort.  This doesn't appear to be done by default in the program, but I suspect changing views in flight, lingering on Nearest Airport until the terrain starts to show up, will force some garbage collection as it frees old terrain memory.  When you go back to the cockpit, you'll see blurries and occasionally low res terrain mesh, and this is what you want to see, but they fix themselves quickly.  This does a reallocation of the memory used by various terrain thingies, and should alleviate fragmentation if it exists.  Since I've been doing this, I haven't had crashes constantly.

 

THAT is from a user's point of view.

 

Hook