Makes no since to me why I cant get all the shaders rebuilt.

There is a setting in the fsx.cfg called SHADER_CACHE_PRIMED=xxxxset it to 0, the sim will automatically rebuild the cache next time you start it.

D3DTADDRESS_WRAP is defined as a constant (that value is never changed) check the DEFINE statament at the begining of the code, it looks like this:

#define D3DTADDRESS_WRAP 1

the above, was NEVER touched, it remained as 1to this:

dword State_TextureWrap			  : STATE_TEXTUREWRAP			  = 0;

I 'disabled' D3DTADDRESS_WRAP?

texture corruption can be due to a series of factors, this solution (disabling texture wrapping) does not address them all, but in my specific case solved my problem. Tim, even disabling Texture wrapping got an error! however, I can't, no matter what I do.. yet, I do not have any PMDG product installed, IF this can only be triggered with a PMDG product, then a SINGLE corrupted texture could be the culprit!!

I'll repeat the question, by replacing D3DTADDRESS_WRAP with 0; what do you think was just accomplished?Paul

I'll repeat the question, by replacing D3DTADDRESS_WRAP with 0; what do you think was just accomplished?

You just replaced a CONSTANT with an integer. Thats the ONLY thing that was accomplished!

#define D3DTADDRESS_WRAP 1dword State_TextureWrap			  : STATE_TEXTUREWRAP  =  D3DTADDRESS_WRAP;

and this:

#define YOU_HAVE_NO_CLUE 1dword State_TextureWrap			  : STATE_TEXTUREWRAP  =  YOU_HAVE_NO_CLUE;

and this:

dword State_TextureWrap			  : STATE_TEXTUREWRAP  =  1;

MEAN THE EXACT SAME THING!!!!!!!!

Hey Guys I hate to step into the middle of an argument here, but I have a question...I started the tweak with Win7 and got horrible artifacts, moved back to Win XP 64, a very streamlined OS with low resource utilization and voila' artifacts gone, then I increased the size of my monitor and now i have artifacts at the very highest settings for weather over FTX terrain.So my question is: could the artifacts be related to the amount of system memory as well as the dedicated memory for the GPU. I have 6 gb of DDR3 memory, would going to 9 or 12 help, is anyone running this with 8 or 12 GB of system memory? If so are they seeing artifacts?

could the artifacts be related to the amount of system memory as well as the dedicated memory for the GPU.

1) First, find what 'causes' them, lock your FPS to a very low value 15, for example (for testing purposes, of course) and see if you have artifacts.2) if the artifacts persist, try to LOWER your screen resolution (for testing purposes again) to something like 1024x768 or 1280x720 do you still see artifacts?test #1 will help you understand IF CPU (or System memory) is responsibletest #2 will help you understand IF GPU or Video memory is responsibletell me which of the above tests helped and we go from there

You just replaced a CONSTANT with an integer. Thats the ONLY thing that was accomplished!

#define D3DTADDRESS_WRAP 1dword State_TextureWrap			  : STATE_TEXTUREWRAP  =  D3DTADDRESS_WRAP;

and this:

#define YOU_HAVE_NO_CLUE 1dword State_TextureWrap			  : STATE_TEXTUREWRAP  =  YOU_HAVE_NO_CLUE;

and this:

dword State_TextureWrap			  : STATE_TEXTUREWRAP  =  1;

MEAN THE EXACT SAME THING!!!!!!!!

LOL Guy!No, I replaced nothing, you had everyone replace D3DTADDRESS_WRAP; with 0;I may be on meds, but You are stating that it does the same thing as having left it in the first place???yet I recall from the DX9 white papers that "To disable texture wrapping ... set the value for the corresponding render state to 0" and since you said "this solution (disabling texture wrapping) "???I presumed you looked into it, again for the 3rd and final time what is it that >your acomplishing with the shaders with replacing = D3DTADDRESS_WRAP with 0;???? You suggest to everyone to do this why???Paul

I presumed you looked into it, again for the 3rd and final time what is it that >your acomplishing with the shaders with replacing = D3DTADDRESS_WRAP with 0;???? Your have everyone doing this why???

Assume the following:A texture is copied to a surface, but the memory allocated for the surface is not large enough for the texture.If at the end of the memory for the surface there is other memory allocated, this will corrupt the data in the allocated memory.If at the end of the memory for the surface there is no other memory allocated, this will cause an access violation exception and crash/corrupt FSX.The larger the source texture is, the more likely it is to corrupt other data or hit unallocated memory. If you run an external debugger and are able to replicate the black textures problem you'll notice it ALWAYS fail here:

HRESULT D3DXLoadSurfaceFromMemory(  LPDIRECT3DSURFACE9 pDestSurface,  CONST PALETTEENTRY * pDestPalette,  CONST RECT * pDestRect,  LPCVOID pSrcMemory,  D3DFORMAT SrcFormat,  UINT SrcPitch,  CONST PALETTEENTRY * pSrcPalette,  CONST RECT * pSrcRect,  DWORD Filter,  D3DCOLOR ColorKey);

Credit goes to Daniel for identifying the 'source' of the problem. I simply tried to find a way to 'reduce' the possibility of the crash simplying the way textures were being perceived, wrapping, simply finds the shortest route between coordinates so that the rasterizer takes the shortest one, it made total sense to me that if there was a crash loading surfaces from memory, disabling wrapping would play a role in trying to troubleshoot the problem, and in my case it did. Texture wrapping 'helps' performance? I guess it does, but can you quantify it? well.. I don't know because I can't see any difference! so the 'vadility' of this so called 'tweak/hack' is yet to be determined, I'm just sharing, I'm not MAKING people do a change! you make it sound like I'm holding a gun to their heads :) and this is NOT in any way related to BP=0, the shader tweak DID SOLVE in my case a long standing black texture/corruption problem.

Assume the following:A texture is copied to a surface, but the memory allocated for the surface is not large enough for the texture.If at the end of the memory for the surface there is other memory allocated, this will corrupt the data in the allocated memory.If at the end of the memory for the surface there is no other memory allocated, this will cause an access violation exception and crash/corrupt FSX.The larger the source texture is, the more likely it is to corrupt other data or hit unallocated memory. If you run an external debugger and are able to replicate the black textures problem you'll notice it ALWAYS fail here:

HRESULT D3DXLoadSurfaceFromMemory(  LPDIRECT3DSURFACE9 pDestSurface,  CONST PALETTEENTRY * pDestPalette,  CONST RECT * pDestRect,  LPCVOID pSrcMemory,  D3DFORMAT SrcFormat,  UINT SrcPitch,  CONST PALETTEENTRY * pSrcPalette,  CONST RECT * pSrcRect,  DWORD Filter,  D3DCOLOR ColorKey);

Credit goes to Daniel for identifying the 'source' of the problem. I simply tried to find a way to 'reduce' the possibility of the crash simplying the way textures were being interpreted, wrapping, changes how Direct3D perceives the shortest route between texture coordinates so the rasterizer takes the shortest route between texture coordinates sets, it made total sense to me that if there was a crash loading surfaces from memory, disabling wrapping would play a role in trying to troubleshoot the problem, and in my case it did. Satisfied? any more questions Paul?

No, I'm sorry it really doesn't.I read through Danials report before I posted last night, that FSX BlackScreens where it did does not necassarily mean that is where the problem lies as I pointed out in the previous post, other wise why would lessening the burden in other ways also help to avoid Black Screens? I already provided other examples.I dont see the logic in your statment at all.How can you state that in your case >it< did? You can lessen the burden on FSX and avoid a Black Screen (These are not CTDT BTW) by doing any number of small things as pointed out in countless post about turning down sound, and other settings does that prove that all of those things play the same role? No.Hey, Joe turned traffic down to 0% and now no more Black Screens when I fly PMDG! doesnt make Traffic the cause anymore than Texture_Wrap is my point.Seems like you are riding the merry go round.Paul

why would lessening the burden in other ways also help to avoid crashes?

I would need to know how memory is allocated, how much is available and what you mean by 'burden', if you are refering to 'sound' and why sound (reducing quality/acceleration) plays a role, then a full reading of how DirectSound, DirectX and memory management works is in order.

I dont see the logic in your statment at all.

Of course you don't!, you are not a programmer ;)

Seems like your riding the merry go round.

And you seem to enjoy this thread a lot :) I wonder why so much interest in it if it is so misleading :)

Hah! There you go again trying to take me out of context, I said "otherwise why" as part of the logic for you to answer for your self as to the fact that lessening the burden helps to avoid Black Screens, >not "why" as in help me understand.

I would need to know how memory is allocated, how much is available and what you mean by 'burden', if you are refering to 'sound' and why sound (reducing quality/acceleration) plays a role, then a full reading of how DirectSound, DirectX and memory management works is in order.Of course you don't!, you are not a programmer ;) And you seem to enjoy this thread a lot :) I wonder why so much interest in it if it is so misleading :)

LOL, and no, I dont need a lesson on memory managment, I was opening 600mb graphic files in win95 with PS with just 8mb of ram when Adobe said it couldnt be done on a desktop.I also dont have the issues you are having and I run at much higher display res and high IQ settings without BS, BSOD or CTDT.Progamer, What? You mean C++? D3D? mainly just Scasm, thru newer BGL language and prefer to spend my time flying about in the real world and to just use a dumb GUI when I have to "program".You?My intrest is FSX used with the best quality possible with no problems, While writing scenery for FS I used to write tweaking guides concerning all things FS right here on Avsim back when LOD_Radius was something new to all of us.Paul

And you seem to enjoy this thread a lot :) I wonder why so much interest in it if it is so misleading :)

Maybe for the same reason as I have: I'm very curious how this wild-goose chase will end up. Started off as a holy grail tweak. Now there is some "deep and systematic" testing to be done to determine wether artifacts, when using the holy grail tweak, are caused by the CPU or the GPU. I'm now anxiously waiting for the next chapter...My recommendation to people having problems with the tweak would be to either revert to "normal" BP setting, turn down some display settings a notch or two, lock fps at 25 and enjoy flying the sim instead of tweaking away the best time of their life,orif needed build a high end computer and enjoy FSX with high display settings instead of tweaking away the best time of their life.I remember that Mitch some months ago build himself a real good FSX computer. No need for any tweaking then! Now Mitch is one of the persons eagerly searching for the holy grail, instead of flying. IMO this is insane. I wonder what Mitch and all other tweakers will think of this holy grail next year?Just my thoughts. Sorry!

I think no one will mind if you two use the PM-system to fight this one out... :(EDIT:O, I thought bojote and FlyingBits were still talking... but no, of course it was Ulf who posted before me. :(

There is a setting in the fsx.cfg called SHADER_CACHE_PRIMED=xxxxset it to 0, the sim will automatically rebuild the cache next time you start it.

I did this still dont have any shaders in the Terrain or general folders. That is why I think there is an error somewhere in my common.fxh file. Maybe you could post your whole file so i can try and copy and paste it into mine? Or just look through mine and see if you can find a noticeable error. I have my backup shaders file just in case but i was hoping to be able to use FSX without compatibility mode.

I think no one will mind if you two use the PM-system to fight this one out... :(

Yes, my bad sorry, sorry.Paul

I think no one will mind if you two use the PM-system to fight this one out... :(EDIT:O, I thought bojote and FlyingBits were still talking... but no, of course it was Ulf who posted before me. :(

Sorry :( I'll go to bed now (it's late here in Sweden) and let you do all the posting :(