I am so glad that I have stuck with a 19" monitor and 1280x1024 resolution. In addition to the power benefits (ie. I don't need SKYNET to run the graphics), I also don't have to worry about increasing the LOD radius to some silly value. Based on what I have seen, I honestly can't see why anyone would need a LOD radius higher than 6.5.

So you don't see the ground textures load in front of your eyes...

I have noticed that at a LOD radius of 4.5, but not at 6.5 (which to be fair I have hardly ever used). Maybe it's because I tend to stay below 5000 feet during my flights? Are you talking about low level, or at cruise altitude?

You know what I have see with some sims and many other games is they mimic the distance being a bit blurry (but with features).  I can't remember what it was called, "near field" or something?  I can't remember what sim it was...

Depth of Field.

 

As far as th 30% GPU utilization. LM still isn't done updating FSX to what they plan it to be. The code is still old.

 

I would imagine when it goes to 64bit a lot will start changing.

I would imagine when it goes to 64bit a lot will start changing.

 

64-bit will probably be implemented in the next iteration of Prepar3D, because it is a very big job (and will break compatibility with pretty much all add-ons).

 

I'm hoping that for Prepar3D 2.x they will just replace as much ugly code as they can and look into the matter of CPU performance.

As far as th 30% GPU utilization.

 

This is unlikely, more likely the tool being used to measure isn't accurate -- I discussed GPU monitoring tools in the past and no one could positively identify exactly what's being used to determine "load" ... some key off the GPU's busy indicator, some from final frame, but there I was no "convincing" information about what that % value really represented.

 

For example, Process Explorer GPU utilization shows 22% on my GPU, yet MSIAfterburner with RivaTuner server shows numbers in the 70-100% range.

 

This video is from early Beta which was NOT as good as current Beta 2 ... you'll need to view 1440p to see all the GPU %, bus load, frame load, CPU loads, FPS, etc. ... it also demonstrates when nVidia's GPU Boost kicks in (look at frequency differences 875 on up to 1150 Mhz) ... which is sorta interesting and may even be responsible for why we see such difference in time between frames as GPU Boost on nVidia cards is changing performance on the fly (I need to investigate GPU Boost further and it's impact on long frames).

 

 

As far as my time frame analysis, yes I have done that with comparison data to v2.2 using built in flight recorder.  I haven't posted any charts from the data as my goal was to count "long frames" and see if v2.2 compared to v2.3 beta had more or less or same long frames.  I use excel to do this (since time frame data from FRAPS comes out in Excel format files) ... even a short flight produces considerable data (over 48,000 data points).  Anyway, what I did was calc frame times (time between frames), then in another column I flag (conditional) time between frame variances > 30 ms ... then I count this flag condition.  I was seeing about 60% reduction in long frames.  This was done in one area (French Alps) ... but it was the same recorded flight so it worked for "relative differences" from 2.2 to 2.3 beta 2.

 

It's important to understand that different areas and different add-ons and different aircraft will produce different results in terms of "long frames" ... for example the A2A Cherokee produces throttle reduction "smoke" effect during flight which can induce as much as a 50% fps hit ... same with LM's Texan trainer (which I believe is IRIS) ... so aircraft type is important in the testing and can skew results.

 

Cheers, Rob.

 

 

I'm hoping that for Prepar3D 2.x they will just replace as much ugly code as they can and look into the matter of CPU performance.

 

LM have actually had to add some ugly code already (a lot) to deal with FSX and even FS9 (and maybe even FS8).  LM have "tried" to make as best a compromise as they can to deal with legacy 3rd party processing/techniques but they also have to evaluate what this compatibility code they've created does to impact performance.

 

So, the next time folks complain about legacy product compatibility they need to decide which is better, slower code to deal with compatibility or faster code but your favorite 3rd party product will need an update that may never come from the 3rd party developer?  It's certainly "food for thought" that I HOPE people using P3D and/or potential users are VERY AWARE of ... as it stands right now 3rd party developers don't want to make two different products one for FSX and one for P3D V2.x and they certainly don't like the idea of retro-fitting their older products to work with P3D v2.x ... 3rd party try to leverage as much as they can in terms of a single product for both (many reasons for this and I'm certainly not trying to associate blame on either side as both have valid positions).  So something to think about ... the compatibility/performance relationship is very much here and now in the current P3D V2.x.

 

Cheers, Rob.

Let people decide to tweak config file and adjust Lod Radius to the value they want.

 

 

I have to respectfully disagree. First, I've never seen a comparison of FSX and P3d 2.x, which showed equivalency in the LOD settings. Is 6.5 in FSX the same as 6.5 in P3d? Second, the fewer tweaks that users can make, the more likely it is that the sim will be stable. ACES looked at the tweaking as a way to get the users of FSX involved in optimizing an app, which was years ahead of its time, at least with regard to the hardware extant at that time. And when FSX was no longer in development, user "fiddling" was a way of making people believe that the sim was still being improved. The only real tweak that I ever saw work was the DX10 Preview combined with Steve's DX10 Fixer. And the Fixer mostly fixed DX10 bugs that ACES would have patched, had the FSX team not been disbanded. IMO, every other FSX tweak is speculative hooey. Some of it works for some folks. Most of it doesn't work, but creates a placebo effect. And some of the tweaking makes FSX more unstable than it normally is. Which brings me to P3d.

 

P3d is still being improved. Other than bug fixing and small performance improvements that LM can make, the only factor that the user can control  in order to get better performance at a specific "eye candy" setting is buying new hardware. LM is correct in limiting certain types of tweaking and I would assume that their research has shown that setting an LOD=10.5 is likely to cause the sim to either OOM or CTD in some other way. Just because some users were lucky with this tweak, doesn't mean that LM should allow users to meddle at will with any setting. It's their product and their reputation. We just pay to use the product.

(and will break compatibility with pretty much all add-ons)

 

 

Probably not. Correct me if I'm wrong, but most addons talk with FSUIPC (which would have to update), or use the language that FSX has, such as the aircraft.cfg files, texture files, sound files. All that remains the same, so 64bit compatibility won't break it. At least that's how I view it. If those files were packaged into a plugin format, then I would probably believe 64bit would change things.

 

But most of them are texture files, cfg files, and sound files.

 

However, for any special addons that run apps outside of FSX, they will probably have to do some updating. Some installers will probably have to be updated too.

 

And no...we should not be charged for a majority of them, if not ALL of them.

LM is correct in limiting certain types of tweaking and I would assume that their research has shown that setting an LOD=10.5 is likely to cause the sim to either OOM or CTD in some other way.

 

See my earlier response on LOD RADIUS values ... information was passed on to me from Beau H. who does the coding in this area.  There is a real hardware GPU limit on texture array size and tessellation support, so LOD RADIUS above 6.5 is just not possible (as is) and can't be opened up as an option even if LM wanted to allow it.  To be able to move beyond 6.5 there would be considerable code changes (something better suited to a 3.x product and/or 64bit path) that could have all kinds of issues and performance concerns ... certainly something that couldn't be accomplished in just a few months.

 

Cheers, Rob.

 

 

Probably not. Correct me if I'm wrong, but most addons talk with FSUIPC (which would have to update), or use the language that FSX has, such as the aircraft.cfg files, texture files, sound files. All that remains the same, so 64bit compatibility won't break it.

 

You are wrong.  FSUIPC is most certainly not required by many add-ons ...  SimConnect, however, is required by many add-ons ... and many of the Add-ons designed for P3D still require the FSX SP2 SimConnect client and will not work with the built in new P3D managed SimConnect client.

 

64bit will break the BGL compatibility, DLL compatibilty ... pretty significant.

 

Cheers, Rob.

 

 

And no...we should not be charged for a majority of them, if not ALL of them.

 

Good luck with that ... most people like to get paid for working, something to do with feeding themselves, families, mortgage/rent, etc. etc.

 

Just curious, suppose you built a product for P3D V2.x 32bit and it took 1000 hours to do.  P3D V3.x 64bit is released and your product doesn't work with it, so you spend 500 hours getting it to work with P3D V3.x 64bit ... you really feel you should NOT be paid for that work?  Extend that philosophy out to P3D V4.x that doesn't work with you 3.x product and you have to spend another 500 hours changing your product ... what you are suggesting is you would have to magically determine all the versions you are going to support out into the future (of which you have NO control and no information) and then come up with a price for the "here and now" so it would be enough to cover all the "Future" work hours/costs.  I can't see that working for anyone?

 

Cheers, Rob.

Probably not. Correct me if I'm wrong, but most addons talk with FSUIPC (which would have to update), or use the language that FSX has, such as the aircraft.cfg files, texture files, sound files. All that remains the same, so 64bit compatibility won't break it. At least that's how I view it. If those files were packaged into a plugin format, then I would probably believe 64bit would change things.

 

But most of them are texture files, cfg files, and sound files.

 

However, for any special addons that run apps outside of FSX, they will probably have to do some updating. Some installers will probably have to be updated too.

 

And no...we should not be charged for a majority of them, if not ALL of them.

Mr. Pinard,

 

You couldn't be more inaccurate in your conclusions concerning third-party addons. Most addons do not use FSUIPC to communicate with the sim. Most addons use the built-in code interface provided by the sim to see data variables. Some use SimConnect, if it's needed. An aircraft addon with C/C++ gauges will require a complete rewrite.

 

All aircraft that utilize anything outside of XML gauge markup (I refuse to call it a language or code... it's neither!) will require rewriting. You think you deserve to get all of that for free?

 

Simply put, you really do not know what you're talking about. At all.

For newer versions, with newer features and implementation. Say for example, P3d has rain functions in the future, and a newer aircraft addon is taking advantage of that (and more features) of that. A newer version of that craft would obviously cost something extra.

 

But to update your aircraft to work with a 64bit client of the same version of the client? (in this case p3dv2). Personally, no there should not be a cost. That is an update to support a change in the software. It's not a question of them not being able to pay the bills, I get that. But we are talking about updating an addon vs. a full blown piece of software that works with an OS.

 

In the music product industry, this was a thing in around 2006 when Apple starting switching to full intel systems. All the companies that made 64bit apps for that switch over didn't charge except maybe a few that had already been working on full new upgraded versions.

 

So to be clear, if the addon dev says "no, we aren't going to upgrade to 64bit until v2" that is their perogative. But to update the same addon you paid initially to work with p3dv2 and charge for it. Well, that just doesn't seem quite right to me. MAYBE an small upgrade fee given it's a smaller company and this is a niche (and the app is largely affected by the switch). But not full cost, that's for sure.

 

Now....I sorta went off topic sorry. But I at least wanted to explain what I meant.

 

EDIT: I realize I'm not knowledgable on what's involved. Don't look at me as a know-it-all here. I just cannot think of any other developer that has charged for a 64bit client. Feel free to correct me on that. It also matters whether it was something that was forced or an option (such as if p3d forced the 64bit update and didn't give an option to keep the 32bit client)

I did inquiry and the answer was not going to happen any time soon ... maybe in the future but the task to change this is not trivial at all.

 

This is a very important answer, because this is questioned on many flight simulator foruns around the world

Edited August 6, 201411 yr by n4gix
Removed excessive quote!

Honestly, I don't get the obsession with LOD radius. 

 

I fly planes in real life. Crisp, clear scenery in the distance is not realistic. Humidity and haze usually prevent it. There's also a limit to how far the eye can clearly perceive things given atmospheric conditions.

LM have actually had to add some ugly code already (a lot) to deal with FSX and even FS9 (and maybe even FS8).  LM have "tried" to make as best a compromise as they can to deal with legacy 3rd party processing/techniques but they also have to evaluate what this compatibility code they've created does to impact performance.

 

So, the next time folks complain about legacy product compatibility they need to decide which is better, slower code to deal with compatibility or faster code but your favorite 3rd party product will need an update that may never come from the 3rd party developer?  It's certainly "food for thought" that I HOPE people using P3D and/or potential users are VERY AWARE of ... as it stands right now 3rd party developers don't want to make two different products one for FSX and one for P3D V2.x and they certainly don't like the idea of retro-fitting their older products to work with P3D v2.x ... 3rd party try to leverage as much as they can in terms of a single product for both (many reasons for this and I'm certainly not trying to associate blame on either side as both have valid positions).  So something to think about ... the compatibility/performance relationship is very much here and now in the current P3D V2.x.

 

I agree, hopefully people will let go of add-ons that are still using FS9 and FS8 elements. They don't have a place in a simulator that is at least 10 years newer.

 

Probably not. Correct me if I'm wrong, but most addons talk with FSUIPC (which would have to update), or use the language that FSX has, such as the aircraft.cfg files, texture files, sound files. All that remains the same, so 64bit compatibility won't break it. At least that's how I view it. If those files were packaged into a plugin format, then I would probably believe 64bit would change things.

 

But most of them are texture files, cfg files, and sound files.

 

However, for any special addons that run apps outside of FSX, they will probably have to do some updating. Some installers will probably have to be updated too.

 

And no...we should not be charged for a majority of them, if not ALL of them.

 

Since when do most add-ons use FSUIPC? I've never used that thing.

 

I'm pretty sure that Lockheed Martin have said that all aircraft will have to be recompiled for 64-bit, and Orbx have said that 64-bit renders BGL files incompatible.

Honestly, I don't get the obsession with LOD radius. 

 

I fly planes in real life. Crisp, clear scenery in the distance is not realistic. Humidity and haze usually prevent it. There's also a limit to how far the eye can clearly perceive things given atmospheric conditions.

Thank you! In 25 years of flying I can count on one hand the times when I could see clearly to the horizon. 

 

Where I see confusion is those who have scenery popping in as they fly and assuming that a larger LOD will prevent that from happening.

 

Vic