Graphics corruption in FSX - (UPDATE: possible solution found!)

[JHepburn 0]

* SOLVED! *I was planning to write a new post, but due to Ryan being so kind to 'follow up' on this thread, I guess my best contribution is to post here for others benefit. I'm 110% confident, that this 'solves' the Dissapearing/Skeleton VC Textures, I'm also confident that this will get me on the 737 Beta Team :)You can start by adding this in the [GRAPHICS] section of your fsx.cfg file. also, the 'theory' about sound, is partially correct, it was totally on track on what (part) of the problem was... :) the 'sound' plays a huge role here.. specially, the sampling rate.[GRAPHICS]SHADER_CACHE_VERSION=1 // it 're-builds' the Shader Cache (good to do on every fsx.cfg change) just enter a random number (versioning)HIGHMEMFIX=1STALE_BUFFER_THRESHOLD=2147483647 // (2048 megabytes)[Display]TEXTURE_BANDWIDTH_MULT=400 // Default is 40 (made 10x faster so we dont end up filling the stale buffer which is also used by the sound card)TextureMaxLoad=30 // Default is 3 (same as above, we need to make video texture transfers *fast* so it won't affect low latency devices)[sOUND]SOUND=1SOUND_QUALITY=2SOUND_LOD=0Also, make sure the sampling rate/quality, for your 'sound card' is set to the 44100 sampling rate (CD Quality) you change this in your Sound Control Panel. 44100Hz is the format used for most .wav files in FSX, when a 'wav' needs re-sampling it takes 'time' which you can't afford to loose in our case. I know some of you have never seen 'some' of the above settings ever, but if any of you guys (reading) are ex-MS employees or were involved with the development, you can confirm to the group what I'm saying ;) you can Ask Rafael Cintron (and no, he was not kind enough to give me the info, I had to spend DAYS reading HEX codes to figure this out) the root cause of the problem is a DPC latency issue + stale buffer saturation with the Video and Sound card in your system, the above settings 'balance' things so both play well together. For those that used my 'shader tweak' you can forget about it... you don't need it anymore after this, also ALL FS2004 ported A/C work with no problems. The only 'caveat' is that now, ANYTIME a texture object or building 'dissapears' you'll get an application crash in the FSX API.dll module when you switch windows, thats NOT bad, it just means, you have now a WARNING! I'll provide aditional info when enough people test this solution, this is ONLY TESTED on Windows 7 64-Bit and FSX with SP2 installed. (don't know if it works for acceleration, SP1 or RTM) have not yet tested under Vista or XPone more thing.. this is NOT the solution to the 'black screens' caused by Windows TDR (Timeout Detection & Recovery) that problem is caused for OTHER reasons I've mentioned in other posts that nobody seems to read or believe (its due to the command buffer being flushed, for excessive ammount of draw calls made to the D3D API and the video card not being able to keep up reading the ring buffer fast enough) also, this is NOT related to 'mouse clicking' the VC and getting and error, that is yet ANOTHER error... (the one people fix with UIAutomationCore.dll) Enjoy people... and remember, *IF* you get an API.dll crash, don't worry... this solution can be tweaked to your particular 'setup' and make it work... the HIGHMEMFIX=1 is what 'triggers' the API.dll error, by default this value is set to 0, so, FSX (very cleverly) doesn't crash!! but, starts making stuff dissapear and gets unstable (and eventually crashes later on) specially when on final ;)As for the Black Screens caused by the Windows TDR (Timeout Detection & Recovery) I'll later post a solution to that as well... I have more than 3 weeks researching this, and I'm exhausted.

I don't know why, but these changes solved my alt-tab texture issues. I will try it with a few different aircraft, but so far so good.I have my nHancer setup per Nick's instructions and did not make any changes there. Thanks!

[bojote 20]

No need to get so defensive. You dont think those are fair and objective questions? Why dont you just answer them?

Fair request, I will... don't you want to wait for users 'feedback' first? I'll explain everything to you in due time.. be patient.

I don't know why, but these changes solved my alt-tab texture issues.

The single 'line' that fixed your issue was HIGHMEMFIX=1 set it to 0, and you'll see the issue surface again.

*******,your last advice, goiung to bufferpools=0 and turning on AA and filtering internally didn't do anything but getting me bad picture quality. Sound cracking remained. So I will stick with AA and filtering through nHancer and a bufferpools setting of 190MB. For me, it's the best compromise between picture quality and frames without stuttering.

BufferPools=0 its a 'tweak' to make FSX faster, not a 'fix' to the Black Texture/corruption problem. The 'Fix' was discussed earlier.

[Guest Shockwave]

Fair request, I will... don't you want to wait for users 'feedback' first? I'll explain everything to you in due time.. be patient.

Don't you think two years of feedback is enough?I'm sorry you seem to feel valid questions are not worth answering, but living with the texture quality of less thasn FS9 is not for me.

[jordanal 70]

@ShockwaveYou seem to be new to the AVSIM forum so I have some friendly advise for you. In this PMDG sub-forum, you have to post your full real name in each post or they will probably be deleted by the mods. It's a PMDG registration support thing.@JesusI'm pretty sure you need to inlude your last name.

[bojote 20]

@ShockwaveYou seem to be new to the AVSIM forum so I have some friendly advise for you. In this PMDG sub-forum, you have to post your full real name in each post or they will probably be deleted by the mods. It's a PMDG registration support thing.

Shockwave is far from being a newby :) he's a commercial member in disguise....

@JesusI'm pretty sure you need to inlude your last name.

Altuve..Its right there :) in my 'VATSIM indicator'

[jordanal 70]

Altuve..Its right there :) in my 'VATSIM indicator'

Ah, it must be that AA photo; it's rather distracting to the actual text of your banner. Makes it easy to miss... : :(

[EvgenyK 0]

They might have something to say to one of the people who actually programmed FSX, but that's not the type of programming we're doing here... It's largely meaningless when even we don't fully understand how the sim works at the core with respect to this kind of graphics thing. If it was a crash happening within PMDG code, then sure, but that isn't what this is.

This is not always true. It is very easy to call correct code and cause it to crash, just because it expects correct data, but gets incorrect. Offen this is result stability/performance tradeoff.Also, don't get me wrong - dump is not silver bullet or magic wand, but what I'm trying to say that it is really powerfull tool for investigation of issues. In many cases it can provide you immediate answer to questions like "is that our code called module which crashed the FSX?". In cases where you can't get this answer immediately but have number of dumps for same issue very likely you will find something common in stack, memory addresses, or in loaded modules list. It is like asking customer questions you don't even thought to ask which he can't answer anyway, but you still getting those answers.Also, I don't suggest you to dig too much into dumps, because learning details can be really complex, but rather do all quick things you can do, like getting all stack, heap, modules, and other information. All you need to know to start is how to run analyzing scripts in windbg.exe.

[jfv 4]

I have done a quick test and all I can say <in his best Robin William's voice> isTHANK YOU JEZUSSS!! :)It worked, I even put my Concorde back to high res textures and it STILL worked.Dude this is awesome. Gonna do more testing tonight.Oh, on my system CD sound has some nasty static in it, when I turn it up a notchto DVD it gets better, I did that, and I notice no problem with your other changes.You did good my friend!!

[JHepburn 0]

I have done a quick test and all I can say <in his best Robin William's voice> isTHANK YOU JEZUSSS!! :)It worked, I even put my Concorde back to high res textures and it STILL worked.Dude this is awesome. Gonna do more testing tonight.Oh, on my system CD sound has some nasty static in it, when I turn it up a notchto DVD it gets better, I did that, and I notice no problem with your other changes.You did good my friend!!

Interestingly, I went back to my old fsx.cfg just to compare, and I couldn't force a crash there either. Is that shader line a one-time reload? Could that be the issue? I need to try a few long distance flights to see what results I get. Thanks again for this!

[Scott434 12]

There is a lot of misleading information out there :)

I am led to believe that a larger percentage of W7/FSX users do not have these problems (a Tabs post if I recall correctly). I have not seen (at least in this thread) a definitive, exhaustive definition of the platform/environment where these problems are manifesting themselves. Meaning, what specific hardware combinations, OS (Vista32,64,W732/64), Updates, FSX level (SP1,SP2 or FSX+Accel), individual installation issues/capabilities, individual tuning settings, scenery add-ons and Aircraft(s) are conspiring to push the OS/application to "hit the wall". There are infinite combinations here for which a general solution is not likely to happen near term.A general solution is difficult without a clear definition of the problem. That includes an explanation of why some W7 users are seeing this and some are not. What is the actual failure mechanism and scenarios which produce deterministic failures? Why, with the same hardware and same environment, does XP64 seem to be less affected? This is perhaps an important clue which might point to a native FSX/OS weakness for which a lot of hacking and band-aid fixes in the end are not a general solution. They might fix some things for some people some of the time but compromise others the rest of the time.Is it that the faster hardware and more efficient memory management in the latest OS releases is bring to the surface the dormant flaws/bugs of the outdated FSX software design? If this is true then we are approaching the saturation point of advanced features (aircraft and scenery) that can be collectively run within FSX. It is very unlikely that this is solely a hardware issue.How likely is it that MS will fix a problem for an extremely limited small number of FSX users who are experiencing problems on a product (FSX) which is in mothballs (perhaps dead) and for which is being used on an unsupported platform? (FSX needs XP or Vista not W7 according to the requirements on the box). I concur with the OP that it is in the developer

[bojote 20]

Interestingly, I went back to my old fsx.cfg just to compare, and I couldn't force a crash there either. Is that shader line a one-time reload? Could that be the issue? I need to try a few long distance flights to see what results I get. Thanks again for this!

I gave a highly detailed technical explanation as to 'why' this is 'The Fix' the real deal... but I don't want to discuss it further until I get Ryan attention or any PMDG developer to speak to, this kind of 'solutions' end up in flame wars with party poopers trying to prevent people to try a fix or tweak..the 'short' non-technical answer:This fix works because of two 'hidden' undocumented, 'settings' in FSX.cfg that are there to 'change' the way FSX behaves under high video memory utilization scenarios, THAT line alone, doesn't 'fix' evertything, you also need to change several other options, such as the 'stale buffer threshold value' which tells FSX 'when' to consider the buffer is 'full'Video and sound 'share' that buffer, and when it reaches the threshold value, FSX will start 'droping' textures and sounds (which result in corrupted textures and crackling sound) increasing that buffer threshold gives you the edge, and using HIGHMEMFIX 'prevents' FSX to 'trash' the textures and make them invisible. Not ALL users suffer the problem, because they have simply not reached the threshold... :)How I came up with all of this? well.. thats something I'll share privately with the PMDG developers, but since this is a 4 year old problem, who is going to believe I magically came up with a fix? NOBODY :) so people just 'ignore' my posts... :) like a lot of people did with the BufferPools thread. But trust me when I say, this fix its a 'breakthrough' :) I would LOVE to have a one on one talk with Rafael Cintron... .

[Guest 413X3]

I nominate ******* for FS person of the year!!! Thank you!! Can you tell me how to remove the other shader tweak file so I can use my fs9 ported airplanes again?

[Scott434 12]

I gave a highly detailed technical explanation as to 'why' this is 'The Fix' the real deal... but I don't want to discuss it further until I get Ryan attention or any PMDG developer to speak to, this kind of 'solutions' end up in flame wars with party poopers trying to prevent people to try a fix or tweak..the 'short' non-technical answer:This fix works because of two 'hidden' undocumented, 'settings' in FSX.cfg that are there to 'change' the way FSX behaves under high video memory utilization scenarios, THAT line alone, doesn't 'fix' evertything, you also need to change several other options, such as the 'stale buffer threshold value' which tells FSX 'when' to consider the buffer is 'full'Video and sound 'share' that buffer, and when it reaches the threshold value, FSX will start 'droping' textures and sounds (which result in corrupted textures and crackling sound) increasing that buffer threshold gives you the edge, and using HIGHMEMFIX 'prevents' FSX to 'trash' the textures and make them invisible. Not ALL users suffer the problem, because they have simply not reached the threshold... :)

But ... hardware resources are much faster so in theory buffers should not be going stale as much. Some posters have seen this with default aircraft with vanilla FSX setups which do not translate into "high video utilization scenarios". AND the theory of stale buffers does not explain why XP is fine in most cases or why many users do not see these failures with W7 at all. It sounds like a throttling band-aid that will break again when a developer release the next more demanding application and in the mean time it delivers lower visual quality??? I am not sure I am getting it!

[bojote 20]

But ... hardware resources are much faster so in theory buffers should not be going stale as much.

So, how does FSX considers it stale? where do you 'set' this value? how do you know what is the default threshold? its all in my original post :)

Some posters have seen this with default aircraft with vanilla FSX setups which do not translate into "high video utilization scenarios

Highly subjective, how do you know what FSX considers a 'high video utilization scenario'? you don't so whats left? make the stale threshold the highest 32-bit integer so you 'know' there WILL be room and enough data can be considered 'fresh' and usable.

AND the theory of stale buffers does not explain why XP is fine in most cases or why many users do not see these failures with W7 at all

XP, Vista and Win7 use different WDDM (thats Windows Display Driver Model) XP uses one called WDXP, and Vista WDDM1.0 and Win7 WDDM1.1, how does each model handles 'video memory' reporting to an application at the API level? (WDDM talks to the D3D API) the app talks to D3D are you to expect always the same output under all driver models?

[bojote 20]

I nominate ******* for FS person of the year!!! Thank you!! Can you tell me how to remove the other shader tweak file so I can use my fs9 ported airplanes again?

Open the file:ShadersHLSL/Common/Common.fxhlook for:dword State_TextureWrap : STATE_TEXTUREWRAP = 0;and change it to dword State_TextureWrap : STATE_TEXTUREWRAP = D3DTADDRESS_WRAP;voila. (don't forget to prime the shader cache)