MrRoper

Do you use shade?

Hi Lucas, I will attempt to help a little, 1) If you run in windowed mode then you can leave V-sync at "application controlled" The nvidia Control Panel V-sync settings only work in full screen mode. 2) Bear in mind I don't run DX10 currently (to many issues with it to use it full time) however you have to realise that when running the FSX limiter at unlimited you 'may' see blurry textures in certain situations. using the FSX limiter dedicates more time to the rendering engine hence the loss in FPS. You can gain these back by lowering your FIBER_FRAME_TIME_FRACTION setting. You need to use this setting to balance the loss of FPS vs Blurring of ground textures. The benefit of using this and the FSX limiter is that FSX will allocate processor resources to texture rendering when your frame rate exceeds the limit you have set.

Microsoft security client isnt a convenience app at all, please dont disable this! ( unless you run another av software ) its nice to be notified when a virus has been detected

I think its since Shadowplay got updated The new version now only supports 16:9 ratios I think (look into the quality -> custom options in the shadowplay app) are you able to try 1080p resolution?

Its downscaling to 1080p

Totally agree Paul, Im sure the experience without this fix (if it is working in DX9) would be worse but we are still at the limits of what DX9 can do. The Fixer goes a long way to minimising this issue, and if i could sort out my cloud fps issue it would be turned on all the time! Lets all cross our fingers that P3D goes 64bit and then we can all keep the check marks enabled in the Scenery Configuration and fly to our hearts content!

This isnt doing what you thing it is, it just marks the executable as largeaddressaware, which the executable already has set if you are running SP2

The main problem is what do MS mean by "lockable" as I don't think you can mark Vertex Buffers as "non Lockable" in DX9! what we need is two identical installs of fsx, one in XP664bit and one in windows764bit and then measure the VAS usage in both to be sure that the hotfix is doing what it said it is!

Hi, Firstly you are correct that DX10 manages memory in a totally different way than DX9 and that DX10 reduces the VAS usage due to DX9 requiring a "Virtualized" copy of video memory. Quoting the document directly So memory allocations that are not marked as lockable are not copied. My point being that a 1:1 copy of video memory is unlikely to be maintained in the VAS unless all the allocated memory is marked as lockable.. This can be checked I with Intel GPA but its not something I have done as yet.

Yep 10% would make sense, which means that 10% of memory being allocated is marked as lockable and being virtualized,

Thats not exactly true, since WDDM 1.1 and vista http://support.microsoft.com/kb/940105 However the Gist is along the right lines and as we dont know what FSX is doing with its memory (i.e. marking the buffers as lockable or not you will get a benefit from using dx10 It shouldnt be gigabytes though on a modern 64bit operating system

Hi KornDog, Just dont run the script after landing with the engines on and the flows wont be run

Hi Paul, No I don't run DX10, mainly due to issues with heavy cloud and stutter which I have not resolved as yet and as you said in DX10 the issue with corrupt objects is not apparent and I would be able to run a lower water setting and turn off shared buffer pools. However I can demonstrate easily the cost of running High water (In DX9) as the FSX engine has to render the scene twice so that it can apply the reflection textures to the water. I appreciate that as a DX10 discussion this was probably off topic as my case is particular to DX9, just wanting to point out that a "BufferPool" is just a large VertexBuffer with many objects in it as apposed to bypassing the bufferpool which is just lots of VertexBuffers with an object in each And I agree its a very interesting subject

And as I said in a commercial environment where the Sim is being restarted for different scenarios this low risk is acceptable as its VERY unlikely to happen. What we don't know is how much LM are committed to the entertainments market where people are running resource hungry scenery and aircraft. Don't get me wrong I want a 64bit version of fsx as much as the next man!

But their target audience wont be running memory intensive add-ons with high-res VC cockpits. Also not many long haul flights are performed in a commercial sim, I can imagine that P3d as it stands in a typical commercial usage scenario performs very well I agree, but I worry that they dont have the resources available to pull something out of the bag quick enough

Hi Paul, my response was in no way an attempt to prove any wrongness in your document , just to point out that FSX (Certainly in DX9) will only create vertexbuffers when using a "managed" pool when it cannot find any room in any existing tracked dynamic VertexBuffer, and that it is much quicker to search and track one large buffer than many small buffers. While this could result in memory waste, at the most this waste will only be (100MB - vertex data size) if our buffer pool setting was 100mb. The real way to balance this is to use Intel GPA to track VertexBuffer usage depending on settings and set the bufferpool size accordingly. The reason I rather do this is so that I don't have to run my water at 2xHigh that is required when not using a shared buffer as i found the FPS hit to be quite high ( I appreciate that this is not needed in dx10!) There are a few caveats to this, I run quite an aggressive RejectThreshold that means that the majority of objects are given dedicated vertexbuffers which lowers the usage of the shared buffer(s) and I also have quite a powerful machine (ivybridge at 4.5ghz and a GTX 780) Regards Chris

Hi Paul, I dont think this is correct, FSX will only create vertex buffers when it cant find space in any existing buffer within the pool, In-fact I run DX9 with a buffer pool of 100MB and never see my VRAM go above 1GB in 3rd party scenery with Dense / Very Dense autogen. In my testing it is obvious that a Large buffer pool performs better than many small pools. I do appreciate however that this might not be the case in DX10

The MOD makes the world of difference, Remove a few plastic brackets and replace with rubber bands..The center detent is still there but nowhere near as bad, I did mine a few years ago and it made a HUGE difference. Make sure you get some good chain lube and give it a spray while its open as well.

You can always try the DynamicFriction Lua script included with FSUIPC, It can be tweaked to your liking as well

Hi All, Thought I would share my V-Speed Calculator/Setter LUA script. It can be found here : https://www.dropbox.com/s/h8btvrixzcxiwf2/Q400VSpeeds.rar As an added bonus it also runs the after landing flows for you, so you can concentrate on talking to ATC and the taxi Cheers

Try the mod Jimmi, it is reversible and it makes the world of difference

James, They work fine, I would advise getting a registered copy of FSUIPC and using that to sort out your control requirements

Hi James, They increase immersion greatly, but as Jimmi said the roll axis is only 45 degrees either side of center. You can mod the yoke to remove the detents, but this will probably void the warranty. I have done it and it makes a big difference to the feel

OK, cool I will knock something together and we can test it, might be the weekend if thats ok?

Ah ok, yes could have been the drivers... Blue screens are normally caused by Hardware issues. Aentwis, yep, correct usepools/bufferpools = 0 will create the buffers directly in GPU memory and bypass the reject threshold