Bo3b's School For Shaderhackers
  28 / 87    
ok, that makes sense :) To be clear the code following the fix that is not out-dented is from the original shader, and I just left it there and commented it to provide some context so you can find the correct spot for the fix in other shaders.
ok, that makes sense :)

To be clear the code following the fix that is not out-dented is from the original shader, and I just left it there and commented it to provide some context so you can find the correct spot for the fix in other shaders.

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 03/04/2015 02:27 PM   
[quote="DarkStarSword"]Glad you were able to get it working :) That's a pretty interesting note about which constants worked and which didn't - I wonder if the limit only applies to constants passed to the shader from the game/Helix mod and not constants defined locally in the shader?[/quote] I've run into a strange problem. If I disable PS 4C7711F0, the ghosting round the trees is fixed. But if I set it to output 0000 or 1111 it doesn't work. Why is that so? I'll try manipulating the output location for this shader. http://api.photos.3dvisionlive.com/imagestore/54f819abe7e564f95f0000c5/thumb.square/172/ http://api.photos.3dvisionlive.com/imagestore/54f81a6fe7e5649f630000df/thumb.square/172/
DarkStarSword said:Glad you were able to get it working :)

That's a pretty interesting note about which constants worked and which didn't - I wonder if the limit only applies to constants passed to the shader from the game/Helix mod and not constants defined locally in the shader?


I've run into a strange problem. If I disable PS 4C7711F0, the ghosting round the trees is fixed. But if I set it to output 0000 or 1111 it doesn't work. Why is that so? I'll try manipulating the output location for this shader.


http://api.photos.3dvisionlive.com/imagestore/54f819abe7e564f95f0000c5/thumb.square/172/

http://api.photos.3dvisionlive.com/imagestore/54f81a6fe7e5649f630000df/thumb.square/172/

Posted 03/05/2015 08:59 AM   
Found a possible VS candidate. If I disable this shader, the effect is removed from the conifers, but not the tree right at the back. So looks like the effect for the tree is done by a different shader. http://api.photos.3dvisionlive.com/imagestore/54f82362e7e564796e0001ce/thumb.square/172/ [code] //Shader for AO like effect on the conifers vs_3_0 // Converted from vs_2_0 with DarkStarSword's shadertool.py def c200, 0, 1, 0.0625, 0 def c17, 0.159154907, 0.5, 6.28318501, -3.14159298 // Discarded sincos constant c18 // Discarded sincos constant c19 def c20, 0, 0, 0, 0 dcl_position v0 dcl_tangent v1 dcl_normal v2 dcl_texcoord v3 dcl_texcoord1 v4 dcl_texcoord o0 dcl_texcoord1 o1 dcl_texcoord2 o2 dcl_texcoord3 o3 dcl_position o4 mov r0.x, c8.z mad r0.x, c11, r0, v0.z mad r0.x, r0, c10, v4 mad r0.x, r0, c17, c17.y frc r0.x, r0 mad r1.x, r0, c17.z, c17.w sincos r0.xy, r1.x mul r1.x, r0.y, c12 mul r1.y, r0, c13.x mul r1.z, r0.y, c14.x mov r1.w, c20.x mul r0, v4.y, r1 add r0, r0, v0 mov r1.xyz, v1 mul r2.xyz, v2.zxyw, r1.yzxw mov r1.xyz, v1 mad r1.xyz, v2.yzxw, r1.zxyw, -r2 dp4 o4.w, r0, c3 dp4 o4.z, r0, c2 dp4 o4.y, r0, c1 dp4 o4.x, r0, c0 mul r1.xyz, r1, v1.w dp3 r0.y, r1, c4 dp3 r0.x, v1, c4 dp3 r0.z, v2, c4 mul o1.xyz, r0, c9.w dp3 r0.y, r1, c5 dp3 r0.x, v1, c5 dp3 r0.z, v2, c5 mul o2.xyz, r0, c9.w dp3 r0.y, r1, c6 dp3 r0.x, v1, c6 dp3 r0.z, v2, c6 mul o3.xyz, r0, c9.w mad o0.zw, v3.xyxy, c16.xyxy, c16 mad o0.xy, v3, c15, c15.zwzw // approximately 43 instruction slots used [/code] I'm not sure where to start on this shader though. I tried setting o0 to 0000 but nothing happens when I hit F10. [code] ... mad o0.zw, v3.xyxy, c16.xyxy, c16 mad o0.xy, v3, c15, c15.zwzw mov o0.xyzw, c200.wwww [/code]
Found a possible VS candidate. If I disable this shader, the effect is removed from the conifers, but not the tree right at the back. So looks like the effect for the tree is done by a different shader.


http://api.photos.3dvisionlive.com/imagestore/54f82362e7e564796e0001ce/thumb.square/172/


//Shader for AO like effect on the conifers

vs_3_0 // Converted from vs_2_0 with DarkStarSword's shadertool.py

def c200, 0, 1, 0.0625, 0

def c17, 0.159154907, 0.5, 6.28318501, -3.14159298
// Discarded sincos constant c18
// Discarded sincos constant c19
def c20, 0, 0, 0, 0
dcl_position v0
dcl_tangent v1
dcl_normal v2
dcl_texcoord v3
dcl_texcoord1 v4

dcl_texcoord o0
dcl_texcoord1 o1
dcl_texcoord2 o2
dcl_texcoord3 o3
dcl_position o4

mov r0.x, c8.z
mad r0.x, c11, r0, v0.z
mad r0.x, r0, c10, v4
mad r0.x, r0, c17, c17.y
frc r0.x, r0
mad r1.x, r0, c17.z, c17.w
sincos r0.xy, r1.x
mul r1.x, r0.y, c12
mul r1.y, r0, c13.x
mul r1.z, r0.y, c14.x
mov r1.w, c20.x
mul r0, v4.y, r1
add r0, r0, v0
mov r1.xyz, v1
mul r2.xyz, v2.zxyw, r1.yzxw
mov r1.xyz, v1
mad r1.xyz, v2.yzxw, r1.zxyw, -r2
dp4 o4.w, r0, c3
dp4 o4.z, r0, c2
dp4 o4.y, r0, c1
dp4 o4.x, r0, c0
mul r1.xyz, r1, v1.w
dp3 r0.y, r1, c4
dp3 r0.x, v1, c4
dp3 r0.z, v2, c4
mul o1.xyz, r0, c9.w
dp3 r0.y, r1, c5
dp3 r0.x, v1, c5
dp3 r0.z, v2, c5
mul o2.xyz, r0, c9.w
dp3 r0.y, r1, c6
dp3 r0.x, v1, c6
dp3 r0.z, v2, c6
mul o3.xyz, r0, c9.w
mad o0.zw, v3.xyxy, c16.xyxy, c16
mad o0.xy, v3, c15, c15.zwzw

// approximately 43 instruction slots used


I'm not sure where to start on this shader though. I tried setting o0 to 0000 but nothing happens when I hit F10.

...
mad o0.zw, v3.xyxy, c16.xyxy, c16
mad o0.xy, v3, c15, c15.zwzw

mov o0.xyzw, c200.wwww

Posted 03/05/2015 09:42 AM   
[quote="eroc_remag"]I've run into a strange problem. If I disable PS 4C7711F0, the ghosting round the trees is fixed. But if I set it to output 0000 or 1111 it doesn't work. Why is that so? I'll try manipulating the output location for this shader. [/quote] I've also found it's worth trying 1110 and 0001 to disable effects in the pixel shader - it depends largely on how their result is being used by the game. There are two other ways you can try to disable a pixel shader if you can't find any output that works: - Comment out everything in the shader after the ps_3_0 line - Use the texkill instruction, which cancels the current pixel render if you pass it a temporary register with negative value in any of the first three components, e.g. [code] def c220, 0, 1, 0.0625, -1 ... // texkill does not work with constant registers, so set r30 to -1 and use it: mov r30, c220.wwww texkill r30 [/code] The texkill instruction is documented here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb206216(v=vs.85).aspx [quote="eroc_remag"]I'm not sure where to start on this shader though. I tried setting o0 to 0000 but nothing happens when I hit F10. [code] ... mad o0.zw, v3.xyxy, c16.xyxy, c16 mad o0.xy, v3, c15, c15.zwzw mov o0.xyzw, c200.wwww [/code][/quote]When you disable a vertex shader, you need to check which output is the position: [code]dcl_position o4[/code] In this case it's o4 and not o0 (In this case it's my script that numbered them this way after upgrading it to shader model 3 - I originally made it do that so the output texcoord numbers matched the register numbers, but I'm thinking of changing it to always use o0 for the position). Looking at your screenshots I think the leaves of the tree at the back might have a second halo that you will need to deal with separately, but I'm not certain. The screenshot with the blue background definitely looks like a halo type issue on the fog in the background. What game (or editor?) is this? I notice the shader you posted doesn't have headers which can sometimes provide clues
eroc_remag said:I've run into a strange problem. If I disable PS 4C7711F0, the ghosting round the trees is fixed. But if I set it to output 0000 or 1111 it doesn't work. Why is that so? I'll try manipulating the output location for this shader.

I've also found it's worth trying 1110 and 0001 to disable effects in the pixel shader - it depends largely on how their result is being used by the game. There are two other ways you can try to disable a pixel shader if you can't find any output that works:

- Comment out everything in the shader after the ps_3_0 line
- Use the texkill instruction, which cancels the current pixel render if you pass it a temporary register with negative value in any of the first three components, e.g.

def c220, 0, 1, 0.0625, -1

...

// texkill does not work with constant registers, so set r30 to -1 and use it:
mov r30, c220.wwww
texkill r30

The texkill instruction is documented here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb206216(v=vs.85).aspx




eroc_remag said:I'm not sure where to start on this shader though. I tried setting o0 to 0000 but nothing happens when I hit F10.

...
mad o0.zw, v3.xyxy, c16.xyxy, c16
mad o0.xy, v3, c15, c15.zwzw

mov o0.xyzw, c200.wwww
When you disable a vertex shader, you need to check which output is the position:
dcl_position o4

In this case it's o4 and not o0 (In this case it's my script that numbered them this way after upgrading it to shader model 3 - I originally made it do that so the output texcoord numbers matched the register numbers, but I'm thinking of changing it to always use o0 for the position).



Looking at your screenshots I think the leaves of the tree at the back might have a second halo that you will need to deal with separately, but I'm not certain. The screenshot with the blue background definitely looks like a halo type issue on the fog in the background.

What game (or editor?) is this? I notice the shader you posted doesn't have headers which can sometimes provide clues

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 03/05/2015 11:59 AM   
[quote="DarkStarSword"]ok, that makes sense :) To be clear the code following the fix that is not out-dented is from the original shader, and I just left it there and commented it to provide some context so you can find the correct spot for the fix in other shaders.[/quote] Ok, well I've been an ass. The penny finally dropped though. I went looking for a shader that had the "overlay" line in the header and discovered there was only one that had any impact on the campaign map. (i.e. the shaders that disabled separate effects had no such line in them). I'd already jotted that down as "turns the whole land surface white" and..........wait for it. 1) It matches the structure of the Mike's fix you quoted and (it gets worse) 2) I'd already repaired the section relating to shadows. Just completely overlooked the border and river bit. (insert facepalm smiley of your choice here). Anyway, in the end all I had to do was copy mike's fix and change an "r4" to "r5". Ok, I'll go hide in a corner now :D I'll go over your post again though, because it's one thing to know what the fix is, another how/why it works. In terms of getting this game playable this was an important fix.
DarkStarSword said:ok, that makes sense :)

To be clear the code following the fix that is not out-dented is from the original shader, and I just left it there and commented it to provide some context so you can find the correct spot for the fix in other shaders.


Ok, well I've been an ass. The penny finally dropped though. I went looking for a shader that had the "overlay" line in the header and discovered there was only one that had any impact on the campaign map. (i.e. the shaders that disabled separate effects had no such line in them).

I'd already jotted that down as "turns the whole land surface white" and..........wait for it.
1) It matches the structure of the Mike's fix you quoted and (it gets worse)
2) I'd already repaired the section relating to shadows. Just completely overlooked the border and river bit. (insert facepalm smiley of your choice here).

Anyway, in the end all I had to do was copy mike's fix and change an "r4" to "r5".


Ok, I'll go hide in a corner now :D

I'll go over your post again though, because it's one thing to know what the fix is, another how/why it works.

In terms of getting this game playable this was an important fix.

Posted 03/05/2015 02:40 PM   
Double post.
Double post.

Posted 03/09/2015 03:21 PM   
Looks like I need help again. This time I'm having a hard time finding the shader. It's once again a 2D texture projected on the ground, but this one wasn't fixed yet. The projection isn't a simple overlay this time (I think). There's a shader I can disable that will remove the texture, but when I do, a "box" of sorts appears around it. It's visible, because it's a shade lighter than the surroundings. However, once you know it's there, it becomes apparent that (with the shader active) the texture I refer to is only ever visible to the extent it falls within the outline of this box. Zooming in,out and rotating the image shows the texture is being cut off outside the bounds. Perhaps it wouldn't be if the stereo correction was ok. Last time I had to look for a shader which referred to an "overlay projection". Does the above give any clue as to what kind of projecting I should be looking for this time? P.S. I should add mike's fix does include this shader, but says it fixes a lighting issue. I tried the fix, but it doesn't appear to have any impact at all.
Looks like I need help again.

This time I'm having a hard time finding the shader.

It's once again a 2D texture projected on the ground, but this one wasn't fixed yet. The projection isn't a simple overlay this time (I think). There's a shader I can disable that will remove the texture, but when I do, a "box" of sorts appears around it.

It's visible, because it's a shade lighter than the surroundings. However, once you know it's there, it becomes apparent that (with the shader active) the texture I refer to is only ever visible to the extent it falls within the outline of this box. Zooming in,out and rotating the image shows the texture is being cut off outside the bounds. Perhaps it wouldn't be if the stereo correction was ok.

Last time I had to look for a shader which referred to an "overlay projection". Does the above give any clue as to what kind of projecting I should be looking for this time?

P.S. I should add mike's fix does include this shader, but says it fixes a lighting issue. I tried the fix, but it doesn't appear to have any impact at all.

Posted 03/09/2015 03:22 PM   
hmm, forum not moving this to page one. Trying again.
hmm, forum not moving this to page one. Trying again.

Posted 03/09/2015 03:33 PM   
[quote="Muizer"]It's once again a 2D texture projected on the ground, but this one wasn't fixed yet. The projection isn't a simple overlay this time (I think). There's a shader I can disable that will remove the texture, but when I do, a "box" of sorts appears around it. It's visible, because it's a shade lighter than the surroundings. However, once you know it's there, it becomes apparent that (with the shader active) the texture I refer to is only ever visible to the extent it falls within the outline of this box. Zooming in,out and rotating the image shows the texture is being cut off outside the bounds. Perhaps it wouldn't be if the stereo correction was ok.[/quote] Your description of the box makes me suspect that it is some kind of post-processing effect that is being limited to part of the screen, either due to scissor clipping (common and easy to disable) or the vertices only covering part of the screen (moderate to impossible to fix). First, see what happend if you add this option to the [General] section in DX9Settings.ini: [code]SkipSetScissorRect = true[/code] One trick I do in these cases to help me understand what is happening, is to set the pixel shader to output full white (or if there are several overlapping effects I sometimes use a semi-transparent colour) so I can clearly see where the bounds of the effect are (the box you described) - that can help me to work out if the bounds are positioned to correctly cover the whole effect in each eye, or if I might need to adjust the position of the vertex shader to eliminate clipping. Be aware that if you adjust the output position of the vertex shader you may make the effect worse unless you also adjust any relevant texcoords, so it's probably better to try to get it to render correctly first, then try to fix the clipping afterwards. Post-processing effects usually need to be fixed in the pixel shaders (but not always, and sometimes they need more complicated fixes in both shaders). Look for any matrix transformations and texture samplers and see what changes if you add a rough adjustment before or after the transform/sample. I always recommend trying to adjust any texcoord outputs of the vertex shader as well - even if they aren't right the first step is to try to learn as much as you can about what parts of the shaders are relevant to the effect. I can't really guess at a pattern to look for without knowing more details about the effect - would you mind posting screenshots of the broken effect, the box you see when disabling it and any vertex and pixel shaders you suspect may be related.
Muizer said:It's once again a 2D texture projected on the ground, but this one wasn't fixed yet. The projection isn't a simple overlay this time (I think). There's a shader I can disable that will remove the texture, but when I do, a "box" of sorts appears around it.

It's visible, because it's a shade lighter than the surroundings. However, once you know it's there, it becomes apparent that (with the shader active) the texture I refer to is only ever visible to the extent it falls within the outline of this box. Zooming in,out and rotating the image shows the texture is being cut off outside the bounds. Perhaps it wouldn't be if the stereo correction was ok.

Your description of the box makes me suspect that it is some kind of post-processing effect that is being limited to part of the screen, either due to scissor clipping (common and easy to disable) or the vertices only covering part of the screen (moderate to impossible to fix).

First, see what happend if you add this option to the [General] section in DX9Settings.ini:
SkipSetScissorRect = true

One trick I do in these cases to help me understand what is happening, is to set the pixel shader to output full white (or if there are several overlapping effects I sometimes use a semi-transparent colour) so I can clearly see where the bounds of the effect are (the box you described) - that can help me to work out if the bounds are positioned to correctly cover the whole effect in each eye, or if I might need to adjust the position of the vertex shader to eliminate clipping.

Be aware that if you adjust the output position of the vertex shader you may make the effect worse unless you also adjust any relevant texcoords, so it's probably better to try to get it to render correctly first, then try to fix the clipping afterwards.

Post-processing effects usually need to be fixed in the pixel shaders (but not always, and sometimes they need more complicated fixes in both shaders). Look for any matrix transformations and texture samplers and see what changes if you add a rough adjustment before or after the transform/sample. I always recommend trying to adjust any texcoord outputs of the vertex shader as well - even if they aren't right the first step is to try to learn as much as you can about what parts of the shaders are relevant to the effect.

I can't really guess at a pattern to look for without knowing more details about the effect - would you mind posting screenshots of the broken effect, the box you see when disabling it and any vertex and pixel shaders you suspect may be related.

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 03/10/2015 05:09 AM   
With the ps disabled [URL=http://smg.photobucket.com/user/Muizer/media/rome201_50_zpsvs4elfy2.jpg.html][IMG]http://img.photobucket.com/albums/v724/Muizer/rome201_50_zpsvs4elfy2.jpg[/IMG][/URL] With the ps enabled [URL=http://smg.photobucket.com/user/Muizer/media/rome202_50_zpsicod4e31.jpg.html][IMG]http://img.photobucket.com/albums/v724/Muizer/rome202_50_zpsicod4e31.jpg[/IMG][/URL] Shader code [code]// // Generated by Microsoft (R) HLSL Shader Compiler 9.27.952.3022 // // Parameters: // // float4 g_campaign_world_bounds; // float4 g_screen_size; // float g_shroud_enabled; // float g_snow_shader_state; // float2 g_texture_ratio; // float2 g_uv_offset; // float4 g_viewport_offset_scale; // float g_vpos_texel_offset; // sampler2D gbuffer_channel_4_sampler; // float4x4 inv_view_projection; // sampler2D s_diffuse_map_clamp; // sampler2D s_diffuse_map_wrap; // sampler2D s_gbuffer_normal_wrap; // sampler2D s_normal; // sampler2D s_normal_wrap; // sampler2D s_shroud; // // // Registers: // // Name Reg Size // ------------------------- ----- ---- // inv_view_projection c0 4 // g_screen_size c4 1 // g_vpos_texel_offset c5 1 // g_shroud_enabled c6 1 // g_campaign_world_bounds c7 1 // g_uv_offset c8 1 // g_snow_shader_state c9 1 // g_viewport_offset_scale c10 1 // g_texture_ratio c11 1 // gbuffer_channel_4_sampler s0 1 // s_shroud s1 1 // s_diffuse_map_clamp s2 1 // s_diffuse_map_wrap s3 1 // s_normal s4 1 // s_normal_wrap s5 1 // s_gbuffer_normal_wrap s6 1 // ps_3_0 def c12, 0.158691406, 0.00196078443, 0.00999999978, -1 def c13, 2, -2, -1, 1 def c14, 0.449999988, 0.579999983, 0.680000007, 100 def c15, 1, 0, -0.5, 0.5 def c16, -2, 3, -0.100000001, -0.5 def c17, 2.5, 0.200000003, 0, 0 dcl_texcoord v0 dcl_texcoord1 v1 dcl_texcoord2 v2 dcl_texcoord3 v3.xyz dcl_texcoord4 v4.xy dcl vPos.xy dcl_2d s0 dcl_2d s1 dcl_2d s2 dcl_2d s3 dcl_2d s4 dcl_2d s5 dcl_2d s6 add r0, c5.x, vPos.xyyy mul r1, r0, c4.zwww texldl r2, r1.xwww, s0 mov r2.zw, c4 mad r0.xy, r0.xwzw, r2.zwzw, -c10 rcp r3.x, c10.z rcp r3.y, c10.w mul r0.xy, r0, r3 mad r0.xy, r0, c13, c13.zwzw mad r0.zw, r2.x, c15.xyxy, c15.xyyx dp4 r2.x, r0, c0 dp4 r2.y, r0, c1 dp4 r2.z, r0, c2 dp4 r0.x, r0, c3 rcp r0.x, r0.x texldl r1, r1, s6 mad r0.yzw, r1.xxyz, c13.x, c13.z nrm r1.xyz, r0.yzww nrm r3.xyz, v0 mul r0.yzw, r3.xxyz, v3.x nrm r3.xyz, v1 mul r3.xyz, r3, v3.y nrm r4.xyz, v2 mul r4.xyz, r4, v3.z mov r5.x, v0.w mov r5.y, v1.w mov r5.z, v2.w mad r5.xyz, r2, r0.x, -r5 mul r3.xyz, r3, r5.y mad r0.yzw, r5.x, r0, r3.xxyz mad r0.yzw, r5.z, r4.xxyz, r0 mul r3.xyz, v3, v3 rcp r4.x, r3.x rcp r4.y, r3.y rcp r4.z, r3.z mad r3.xyz, r0.yzww, -r4, c15.z mad r5.xyz, r0.yzww, r4, c15.z cmp r5.xyz, r5, c15.y, c15.x cmp r3.xyz, r3, c15.y, r5 mul r0.z, r3.y, r3.x mul r0.z, r3.z, r0.z cmp r3, -r0.z, c13.z, c13.w texkill r3 mad r3.xy, r0.ywzw, r4.xzzw, c15.w mov r4.y, v2.z mov r4.z, v0.z mov r4.x, v1.z mul r0.yzw, r1.xzxy, r4.xxyz mad r0.yzw, r1.xyzx, r4.xyzx, -r0 nrm r4.xyz, r0.yzww mov r5.z, v1.x mov r5.x, v2.x mov r5.y, v0.x mul r0.yzw, r1.xyzx, r5.xxyz mad r0.yzw, r5.xzxy, r1.xzxy, -r0 nrm r5.xyz, r0.yzww add r3.z, -r3.y, c13.w texld r6, r3.xzzw, s2 mul r7.x, r6.w, v4.y mul r0.yz, r3.xxzw, v3.xxzw mul r0.yz, r0, c11.xxyw mul r0.yz, r0, c12.x texld r8, r0.yzzw, s3 texld r9, r0.yzzw, s5 add r0.yz, r9.xwyw, c12.y mad r9.yz, r0, c13.x, c13.z dp2add r0.y, r9.yzzw, -r9.yzzw, c13.w max r1.w, r0.y, c15.y rsq r0.y, r1.w rcp r0.y, r0.y mul r10.xyz, r5, r9.z mad r10.xyz, r9.y, r4, r10 mad r0.yzw, r0.y, r1.xxyz, r10.xxyz nrm r10.xyz, r0.yzww texld r3, r3.xzzw, s4 add r0.yz, r3.xwyw, c12.y mad r7.yz, r0, c13.x, c13.z dp2add r0.y, r7.yzzw, -r7.yzzw, c13.w max r1.w, r0.y, c15.y rsq r0.y, r1.w rcp r0.y, r0.y mul r3.xyz, r5, r7.z mad r3.xyz, r7.y, r4, r3 mad r0.yzw, r0.y, r1.xxyz, r3.xxyz nrm r1.xyz, r0.yzww cmp r0.yzw, -v4.x, r1.xxyz, r10.xxyz cmp r1.xyz, -v4.x, r6, r8 mov r9.x, r7.x cmp r3.xyw, -v4.x, r7.yzzx, r9.yzzx mov r4.xzw, c13 add r1.w, r4.z, c9.x dp2add r2.y, r3, r3, c15.y rsq r2.y, r2.y mul_sat r2.y, r2.y, r3.x lrp r3.xyz, r2.y, c14, r1 cmp r1.xyz, -r1_abs.w, r3, r1 mov r1.w, c15.w if_lt r1.w, c6.x mad r2.xy, r2.xzzw, r0.x, -c7 add r2.zw, -c7.xyxy, c7 rcp r3.x, r2.z rcp r3.y, r2.w mul r2.xy, r2, r3 mad r2.zw, c8.xyxy, -r4.x, r4.w mad r2, r2.xyyy, r2.zwww, c8.xyyy texldl r4, r2, s1 add r2, r2.xxww, c12.zwzw mul_sat r2, r2, c14.w mad r5, r2, c16.x, c16.y mul r2, r2, r2 mul r2, r2, r5 mul r0.x, r4.w, r2.x mul r0.x, r0.x, r2.z mad r0.x, r2.y, -r0.x, r0.x mad r0.x, r2.w, -r0.x, r0.x else mov r0.x, c13.w endif add r2.xy, r0.x, c16.zwzw mul_sat r0.x, r2.x, c17.x mad r1.w, r0.x, c16.x, c16.y mul r0.x, r0.x, r0.x mul r0.x, r0.x, r1.w add_sat r1.w, r2.y, r2.y mad r2.x, r1.w, c16.x, c16.y mul r1.w, r1.w, r1.w mul r1.w, r1.w, r2.x mul r0.x, r0.x, c17.y mul_sat r2.xyz, r0.x, r1 lrp r3.xyz, r1.w, r1, r2 rsq r0.x, r3.x rsq r1.x, r3.y rsq r1.y, r3.z rcp oC1.x, r0.x rcp oC1.y, r1.x rcp oC1.z, r1.y max r1.x, r0_abs.z, r0_abs.w max r2.x, r0_abs.y, r1.x rcp r0.x, r2.x mul r0.xyz, r0.x, r0.yzww mad oC0.xyz, r0, c15.w, c15.w mov oC0.w, r3.w mov oC1.w, r3.w // approximately 167 instruction slots used (10 texture, 157 arithmetic) [/code] To be clear, the effect I'd like to fix is the ground texture under the vilage. It has the left image displayed on the right and vice versa, relative to the camera (not the world). Mike's fix for this shader [code]//campaign map ground lighting around the base statue // Generated by Microsoft (R) HLSL Shader Compiler 9.27.952.3022 // // Parameters: // // float4 g_campaign_world_bounds; // float g_force_snow_shader; // float4 g_screen_size; // float g_shroud_enabled; // float2 g_texture_ratio; // float2 g_uv_offset; // float4 g_viewport_offset_scale; // float g_vpos_texel_offset; // sampler2D gbuffer_channel_4_sampler; // float4x4 inv_view_projection; // sampler2D s_diffuse_map_clamp; // sampler2D s_diffuse_map_wrap; // sampler2D s_gbuffer_normal_wrap; // sampler2D s_normal; // sampler2D s_normal_wrap; // sampler2D s_shroud; // // // Registers: // // Name Reg Size // ------------------------- ----- ---- // inv_view_projection c0 4 // g_screen_size c4 1 // g_vpos_texel_offset c5 1 // g_shroud_enabled c6 1 // g_campaign_world_bounds c7 1 // g_uv_offset c8 1 // g_force_snow_shader c9 1 // g_viewport_offset_scale c10 1 // g_texture_ratio c11 1 // gbuffer_channel_4_sampler s0 1 // s_shroud s1 1 // s_diffuse_map_clamp s2 1 // s_diffuse_map_wrap s3 1 // s_normal s4 1 // s_normal_wrap s5 1 // s_gbuffer_normal_wrap s6 1 // ps_3_0 def c12, 1, 0, -0.5, 0.5 def c13, 2, -2, -1, 1 def c14, 0.158691406, 0.00196078443, 0.00999999978, -1 def c15, 0.449999988, 0.579999983, 0.680000007, 100 def c16, -2, 3, -0.100000001, -0.5 def c17, 2.5, 0.200000003, 0, 0 def c220, 0, 0, 0.0625, 0 dcl_2d s13 dcl_texcoord v0 dcl_texcoord1 v1 dcl_texcoord2 v2 dcl_texcoord3 v3.xyz dcl_texcoord4 v4.xy dcl vPos.xy dcl_2d s0 dcl_2d s1 dcl_2d s2 dcl_2d s3 dcl_2d s4 dcl_2d s5 dcl_2d s6 add r0, c5.x, vPos.xyyy mul r1, r0, c4.zwww texldl r2, r1.xwww, s0 mov r2.zw, c4 mad r0.xy, r0.xwzw, r2.zwzw, -c10 rcp r3.x, c10.z rcp r3.y, c10.w mul r0.xy, r0, r3 mad r0.xy, r0, c13, c13.zwzw mad r0.zw, r2.x, c12.xyxy, c12.xyyx dp4 r2.x, r0, c0 dp4 r2.y, r0, c1 dp4 r2.z, r0, c2 dp4 r0.x, r0, c3 mov r10.xyz, r2.xyz mov r10.w, r0.x rcp r12.w, r0.x mul r10, r10, r12.w dp4 r11.x, r10, c200 dp4 r11.y, r10, c201 dp4 r11.z, r10, c202 dp4 r11.w, r10, c203 texldl r24, c220.z, s13 add r24.y, r11.w, -r24.y mul r24.x, r24.x, r24.y add r11.x, r11.x, -r24.x dp4 r10.x, r11, c204 //c0 dp4 r10.y, r11, c205 //c1 dp4 r10.z, r11, c206 //c2 dp4 r10.w, r11, c207 //c3 mul r10, r10, r0.x mov r2.xyz, r10.xyz rcp r0.x, r0.x texldl r1, r1, s6 mad r0.yzw, r1.xxyz, c13.x, c13.z nrm r1.xyz, r0.yzww nrm r3.xyz, v0 mul r0.yzw, r3.xxyz, v3.x nrm r3.xyz, v1 mul r3.xyz, r3, v3.y nrm r4.xyz, v2 mul r4.xyz, r4, v3.z mov r5.x, v0.w mov r5.y, v1.w mov r5.z, v2.w mad r5.xyz, r2, r0.x, -r5 mul r3.xyz, r3, r5.y mad r0.yzw, r5.x, r0, r3.xxyz mad r0.yzw, r5.z, r4.xxyz, r0 mul r3.xyz, v3, v3 rcp r4.x, r3.x rcp r4.y, r3.y rcp r4.z, r3.z mad r3.xyz, r0.yzww, -r4, c12.z mad r5.xyz, r0.yzww, r4, c12.z cmp r5.xyz, r5, c12.y, c12.x cmp r3.xyz, r3, c12.y, r5 mul r0.z, r3.y, r3.x mul r0.z, r3.z, r0.z cmp r3, -r0.z, c13.z, c13.w texkill r3 mad r3.xy, r0.ywzw, r4.xzzw, c12.w mov r4.y, v2.z mov r4.z, v0.z mov r4.x, v1.z mul r0.yzw, r1.xzxy, r4.xxyz mad r0.yzw, r1.xyzx, r4.xyzx, -r0 nrm r4.xyz, r0.yzww mov r5.z, v1.x mov r5.x, v2.x mov r5.y, v0.x mul r0.yzw, r1.xyzx, r5.xxyz mad r0.yzw, r5.xzxy, r1.xzxy, -r0 nrm r5.xyz, r0.yzww add r3.z, -r3.y, c13.w texld r6, r3.xzzw, s2 mul r7.x, r6.w, v4.y mul r0.yz, r3.xxzw, v3.xxzw mul r0.yz, r0, c11.xxyw mul r0.yz, r0, c14.x texld r8, r0.yzzw, s3 texld r9, r0.yzzw, s5 add r0.yz, r9.xwyw, c14.y mad r9.yz, r0, c13.x, c13.z dp2add r0.y, r9.yzzw, -r9.yzzw, c13.w max r1.w, r0.y, c12.y rsq r0.y, r1.w rcp r0.y, r0.y mul r10.xyz, r5, r9.z mad r10.xyz, r9.y, r4, r10 mad r0.yzw, r0.y, r1.xxyz, r10.xxyz nrm r10.xyz, r0.yzww texld r3, r3.xzzw, s4 add r0.yz, r3.xwyw, c14.y mad r7.yz, r0, c13.x, c13.z dp2add r0.y, r7.yzzw, -r7.yzzw, c13.w max r1.w, r0.y, c12.y rsq r0.y, r1.w rcp r0.y, r0.y mul r3.xyz, r5, r7.z mad r3.xyz, r7.y, r4, r3 mad r0.yzw, r0.y, r1.xxyz, r3.xxyz nrm r1.xyz, r0.yzww cmp r0.yzw, -v4.x, r1.xxyz, r10.xxyz cmp r1.xyz, -v4.x, r6, r8 mov r9.x, r7.x cmp r3.xyw, -v4.x, r7.yzzx, r9.yzzx abs r1.w, c9.x dp2add r2.y, r3, r3, c12.y rsq r2.y, r2.y mul_sat r2.y, r2.y, r3.x lrp r3.xyz, r2.y, c15, r1 cmp r1.xyz, -r1.w, r1, r3 mov r2.y, c12.y if_lt -c6.x, r2.y mad r2.xy, r2.xzzw, r0.x, -c7 add r2.zw, -c7.xyxy, c7 rcp r3.x, r2.z rcp r3.y, r2.w mul r2.xy, r2, r3 mov r4.xw, c13 mad r2.zw, c8.xyxy, -r4.x, r4.w mad r2, r2.xyyy, r2.zwww, c8.xyyy texldl r4, r2, s1 add r2, r2.xxww, c14.zwzw mul_sat r2, r2, c15.w mad r5, r2, c16.x, c16.y mul r2, r2, r2 mul r2, r2, r5 mul r0.x, r4.w, r2.x mul r0.x, r0.x, r2.z mad r0.x, r2.y, -r0.x, r0.x mad r0.x, r2.w, -r0.x, r0.x else mov r0.x, c13.w endif add r2.xy, r0.x, c16.zwzw mul_sat r0.x, r2.x, c17.x mad r1.w, r0.x, c16.x, c16.y mul r0.x, r0.x, r0.x mul r0.x, r0.x, r1.w add_sat r1.w, r2.y, r2.y mad r2.x, r1.w, c16.x, c16.y mul r1.w, r1.w, r1.w mul r1.w, r1.w, r2.x mul r0.x, r0.x, c17.y mul_sat r2.xyz, r0.x, r1 lrp r3.xyz, r1.w, r1, r2 rsq r0.x, r3.x rsq r1.x, r3.y rsq r1.y, r3.z rcp oC1.x, r0.x rcp oC1.y, r1.x rcp oC1.z, r1.y max r1.x, r0_abs.z, r0_abs.w max r2.x, r0_abs.y, r1.x rcp r0.x, r2.x mul r0.xyz, r0.x, r0.yzww mad oC0.xyz, r0, c12.w, c12.w mov oC0.w, r3.w mov oC1.w, r3.w // approximately 167 instruction slots used (10 texture, 157 arithmetic) [/code] Says it only concerns a lighting issue. When I disable the following vertex shader the ground surface disappears, but there's no other visbile effect. There's no fix in Mike's package for this shader: [code]// // Generated by Microsoft (R) HLSL Shader Compiler 9.27.952.3022 // // Parameters: // // float4x4 view_projection; // // // Registers: // // Name Reg Size // --------------- ----- ---- // view_projection c0 4 // vs_3_0 def c4, 1, 0, 0, 0 dcl_position v0 dcl_position1 v1 dcl_position2 v2 dcl_position3 v3 dcl_position4 v4 dcl_position5 v5 dcl_position o0 dcl_texcoord o1 dcl_texcoord1 o2 dcl_texcoord2 o3 dcl_texcoord3 o4 dcl_texcoord4 o5.xy mad r0, v0.xyzx, c4.xxxy, c4.yyyx dp4 r1.x, r0, v1 dp4 r1.y, r0, v2 dp4 r1.z, r0, v3 mov r1.w, c4.x dp4 o0.x, r1, c0 dp4 o0.y, r1, c1 dp4 o0.z, r1, c2 dp4 o0.w, r1, c3 mov o1, v1 mov o2, v2 mov o3, v3 mov o4, v4 mov o5.xy, v5 // approximately 14 instruction slots used [/code] Interestingly, when I disable both the vertex and the pixel shader, this is what happens: [URL=http://smg.photobucket.com/user/Muizer/media/rome203_50_zps04sy9g9v.jpg.html][IMG]http://img.photobucket.com/albums/v724/Muizer/rome203_50_zps04sy9g9v.jpg[/IMG][/URL] EDIT: I haven't looked into the role of texcoords at all so far. The main question I have atm is if these shaders are the right place to look for a fix at all, or whether it too has an "overlay" somewhere else where I need to be, as was the case for borders and rivers.
With the ps disabled

Image

With the ps enabled
Image

Shader code
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.27.952.3022
//
// Parameters:
//
// float4 g_campaign_world_bounds;
// float4 g_screen_size;
// float g_shroud_enabled;
// float g_snow_shader_state;
// float2 g_texture_ratio;
// float2 g_uv_offset;
// float4 g_viewport_offset_scale;
// float g_vpos_texel_offset;
// sampler2D gbuffer_channel_4_sampler;
// float4x4 inv_view_projection;
// sampler2D s_diffuse_map_clamp;
// sampler2D s_diffuse_map_wrap;
// sampler2D s_gbuffer_normal_wrap;
// sampler2D s_normal;
// sampler2D s_normal_wrap;
// sampler2D s_shroud;
//
//
// Registers:
//
// Name Reg Size
// ------------------------- ----- ----
// inv_view_projection c0 4
// g_screen_size c4 1
// g_vpos_texel_offset c5 1
// g_shroud_enabled c6 1
// g_campaign_world_bounds c7 1
// g_uv_offset c8 1
// g_snow_shader_state c9 1
// g_viewport_offset_scale c10 1
// g_texture_ratio c11 1
// gbuffer_channel_4_sampler s0 1
// s_shroud s1 1
// s_diffuse_map_clamp s2 1
// s_diffuse_map_wrap s3 1
// s_normal s4 1
// s_normal_wrap s5 1
// s_gbuffer_normal_wrap s6 1
//

ps_3_0
def c12, 0.158691406, 0.00196078443, 0.00999999978, -1
def c13, 2, -2, -1, 1
def c14, 0.449999988, 0.579999983, 0.680000007, 100
def c15, 1, 0, -0.5, 0.5
def c16, -2, 3, -0.100000001, -0.5
def c17, 2.5, 0.200000003, 0, 0
dcl_texcoord v0
dcl_texcoord1 v1
dcl_texcoord2 v2
dcl_texcoord3 v3.xyz
dcl_texcoord4 v4.xy
dcl vPos.xy
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_2d s3
dcl_2d s4
dcl_2d s5
dcl_2d s6
add r0, c5.x, vPos.xyyy
mul r1, r0, c4.zwww
texldl r2, r1.xwww, s0
mov r2.zw, c4
mad r0.xy, r0.xwzw, r2.zwzw, -c10
rcp r3.x, c10.z
rcp r3.y, c10.w
mul r0.xy, r0, r3
mad r0.xy, r0, c13, c13.zwzw
mad r0.zw, r2.x, c15.xyxy, c15.xyyx
dp4 r2.x, r0, c0
dp4 r2.y, r0, c1
dp4 r2.z, r0, c2
dp4 r0.x, r0, c3
rcp r0.x, r0.x

texldl r1, r1, s6
mad r0.yzw, r1.xxyz, c13.x, c13.z
nrm r1.xyz, r0.yzww

nrm r3.xyz, v0
mul r0.yzw, r3.xxyz, v3.x
nrm r3.xyz, v1
mul r3.xyz, r3, v3.y
nrm r4.xyz, v2
mul r4.xyz, r4, v3.z
mov r5.x, v0.w
mov r5.y, v1.w
mov r5.z, v2.w
mad r5.xyz, r2, r0.x, -r5
mul r3.xyz, r3, r5.y
mad r0.yzw, r5.x, r0, r3.xxyz
mad r0.yzw, r5.z, r4.xxyz, r0
mul r3.xyz, v3, v3
rcp r4.x, r3.x
rcp r4.y, r3.y
rcp r4.z, r3.z
mad r3.xyz, r0.yzww, -r4, c15.z
mad r5.xyz, r0.yzww, r4, c15.z
cmp r5.xyz, r5, c15.y, c15.x
cmp r3.xyz, r3, c15.y, r5
mul r0.z, r3.y, r3.x
mul r0.z, r3.z, r0.z
cmp r3, -r0.z, c13.z, c13.w
texkill r3
mad r3.xy, r0.ywzw, r4.xzzw, c15.w
mov r4.y, v2.z
mov r4.z, v0.z
mov r4.x, v1.z
mul r0.yzw, r1.xzxy, r4.xxyz
mad r0.yzw, r1.xyzx, r4.xyzx, -r0
nrm r4.xyz, r0.yzww
mov r5.z, v1.x
mov r5.x, v2.x
mov r5.y, v0.x
mul r0.yzw, r1.xyzx, r5.xxyz
mad r0.yzw, r5.xzxy, r1.xzxy, -r0
nrm r5.xyz, r0.yzww
add r3.z, -r3.y, c13.w
texld r6, r3.xzzw, s2
mul r7.x, r6.w, v4.y
mul r0.yz, r3.xxzw, v3.xxzw
mul r0.yz, r0, c11.xxyw
mul r0.yz, r0, c12.x
texld r8, r0.yzzw, s3
texld r9, r0.yzzw, s5
add r0.yz, r9.xwyw, c12.y
mad r9.yz, r0, c13.x, c13.z
dp2add r0.y, r9.yzzw, -r9.yzzw, c13.w
max r1.w, r0.y, c15.y
rsq r0.y, r1.w
rcp r0.y, r0.y
mul r10.xyz, r5, r9.z
mad r10.xyz, r9.y, r4, r10
mad r0.yzw, r0.y, r1.xxyz, r10.xxyz
nrm r10.xyz, r0.yzww
texld r3, r3.xzzw, s4
add r0.yz, r3.xwyw, c12.y
mad r7.yz, r0, c13.x, c13.z
dp2add r0.y, r7.yzzw, -r7.yzzw, c13.w
max r1.w, r0.y, c15.y
rsq r0.y, r1.w
rcp r0.y, r0.y
mul r3.xyz, r5, r7.z
mad r3.xyz, r7.y, r4, r3
mad r0.yzw, r0.y, r1.xxyz, r3.xxyz
nrm r1.xyz, r0.yzww
cmp r0.yzw, -v4.x, r1.xxyz, r10.xxyz
cmp r1.xyz, -v4.x, r6, r8
mov r9.x, r7.x
cmp r3.xyw, -v4.x, r7.yzzx, r9.yzzx
mov r4.xzw, c13
add r1.w, r4.z, c9.x
dp2add r2.y, r3, r3, c15.y
rsq r2.y, r2.y
mul_sat r2.y, r2.y, r3.x
lrp r3.xyz, r2.y, c14, r1
cmp r1.xyz, -r1_abs.w, r3, r1
mov r1.w, c15.w
if_lt r1.w, c6.x
mad r2.xy, r2.xzzw, r0.x, -c7
add r2.zw, -c7.xyxy, c7
rcp r3.x, r2.z
rcp r3.y, r2.w
mul r2.xy, r2, r3
mad r2.zw, c8.xyxy, -r4.x, r4.w
mad r2, r2.xyyy, r2.zwww, c8.xyyy
texldl r4, r2, s1
add r2, r2.xxww, c12.zwzw
mul_sat r2, r2, c14.w
mad r5, r2, c16.x, c16.y
mul r2, r2, r2
mul r2, r2, r5
mul r0.x, r4.w, r2.x
mul r0.x, r0.x, r2.z
mad r0.x, r2.y, -r0.x, r0.x
mad r0.x, r2.w, -r0.x, r0.x
else
mov r0.x, c13.w
endif
add r2.xy, r0.x, c16.zwzw
mul_sat r0.x, r2.x, c17.x
mad r1.w, r0.x, c16.x, c16.y
mul r0.x, r0.x, r0.x
mul r0.x, r0.x, r1.w
add_sat r1.w, r2.y, r2.y
mad r2.x, r1.w, c16.x, c16.y
mul r1.w, r1.w, r1.w
mul r1.w, r1.w, r2.x
mul r0.x, r0.x, c17.y
mul_sat r2.xyz, r0.x, r1
lrp r3.xyz, r1.w, r1, r2
rsq r0.x, r3.x
rsq r1.x, r3.y
rsq r1.y, r3.z
rcp oC1.x, r0.x
rcp oC1.y, r1.x
rcp oC1.z, r1.y
max r1.x, r0_abs.z, r0_abs.w
max r2.x, r0_abs.y, r1.x
rcp r0.x, r2.x
mul r0.xyz, r0.x, r0.yzww
mad oC0.xyz, r0, c15.w, c15.w
mov oC0.w, r3.w
mov oC1.w, r3.w

// approximately 167 instruction slots used (10 texture, 157 arithmetic)


To be clear, the effect I'd like to fix is the ground texture under the vilage. It has the left image displayed on the right and vice versa, relative to the camera (not the world).

Mike's fix for this shader

//campaign map ground lighting around the base statue
// Generated by Microsoft (R) HLSL Shader Compiler 9.27.952.3022
//
// Parameters:
//
// float4 g_campaign_world_bounds;
// float g_force_snow_shader;
// float4 g_screen_size;
// float g_shroud_enabled;
// float2 g_texture_ratio;
// float2 g_uv_offset;
// float4 g_viewport_offset_scale;
// float g_vpos_texel_offset;
// sampler2D gbuffer_channel_4_sampler;
// float4x4 inv_view_projection;
// sampler2D s_diffuse_map_clamp;
// sampler2D s_diffuse_map_wrap;
// sampler2D s_gbuffer_normal_wrap;
// sampler2D s_normal;
// sampler2D s_normal_wrap;
// sampler2D s_shroud;
//
//
// Registers:
//
// Name Reg Size
// ------------------------- ----- ----
// inv_view_projection c0 4
// g_screen_size c4 1
// g_vpos_texel_offset c5 1
// g_shroud_enabled c6 1
// g_campaign_world_bounds c7 1
// g_uv_offset c8 1
// g_force_snow_shader c9 1
// g_viewport_offset_scale c10 1
// g_texture_ratio c11 1
// gbuffer_channel_4_sampler s0 1
// s_shroud s1 1
// s_diffuse_map_clamp s2 1
// s_diffuse_map_wrap s3 1
// s_normal s4 1
// s_normal_wrap s5 1
// s_gbuffer_normal_wrap s6 1
//

ps_3_0
def c12, 1, 0, -0.5, 0.5
def c13, 2, -2, -1, 1
def c14, 0.158691406, 0.00196078443, 0.00999999978, -1
def c15, 0.449999988, 0.579999983, 0.680000007, 100
def c16, -2, 3, -0.100000001, -0.5
def c17, 2.5, 0.200000003, 0, 0
def c220, 0, 0, 0.0625, 0
dcl_2d s13
dcl_texcoord v0
dcl_texcoord1 v1
dcl_texcoord2 v2
dcl_texcoord3 v3.xyz
dcl_texcoord4 v4.xy
dcl vPos.xy
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_2d s3
dcl_2d s4
dcl_2d s5
dcl_2d s6
add r0, c5.x, vPos.xyyy
mul r1, r0, c4.zwww
texldl r2, r1.xwww, s0
mov r2.zw, c4
mad r0.xy, r0.xwzw, r2.zwzw, -c10
rcp r3.x, c10.z
rcp r3.y, c10.w
mul r0.xy, r0, r3
mad r0.xy, r0, c13, c13.zwzw
mad r0.zw, r2.x, c12.xyxy, c12.xyyx
dp4 r2.x, r0, c0
dp4 r2.y, r0, c1
dp4 r2.z, r0, c2
dp4 r0.x, r0, c3

mov r10.xyz, r2.xyz
mov r10.w, r0.x

rcp r12.w, r0.x
mul r10, r10, r12.w

dp4 r11.x, r10, c200
dp4 r11.y, r10, c201
dp4 r11.z, r10, c202
dp4 r11.w, r10, c203

texldl r24, c220.z, s13
add r24.y, r11.w, -r24.y
mul r24.x, r24.x, r24.y
add r11.x, r11.x, -r24.x

dp4 r10.x, r11, c204 //c0
dp4 r10.y, r11, c205 //c1
dp4 r10.z, r11, c206 //c2
dp4 r10.w, r11, c207 //c3

mul r10, r10, r0.x
mov r2.xyz, r10.xyz


rcp r0.x, r0.x
texldl r1, r1, s6
mad r0.yzw, r1.xxyz, c13.x, c13.z
nrm r1.xyz, r0.yzww
nrm r3.xyz, v0
mul r0.yzw, r3.xxyz, v3.x
nrm r3.xyz, v1
mul r3.xyz, r3, v3.y
nrm r4.xyz, v2
mul r4.xyz, r4, v3.z
mov r5.x, v0.w
mov r5.y, v1.w
mov r5.z, v2.w
mad r5.xyz, r2, r0.x, -r5
mul r3.xyz, r3, r5.y
mad r0.yzw, r5.x, r0, r3.xxyz
mad r0.yzw, r5.z, r4.xxyz, r0
mul r3.xyz, v3, v3
rcp r4.x, r3.x
rcp r4.y, r3.y
rcp r4.z, r3.z
mad r3.xyz, r0.yzww, -r4, c12.z
mad r5.xyz, r0.yzww, r4, c12.z
cmp r5.xyz, r5, c12.y, c12.x
cmp r3.xyz, r3, c12.y, r5
mul r0.z, r3.y, r3.x
mul r0.z, r3.z, r0.z
cmp r3, -r0.z, c13.z, c13.w
texkill r3
mad r3.xy, r0.ywzw, r4.xzzw, c12.w
mov r4.y, v2.z
mov r4.z, v0.z
mov r4.x, v1.z
mul r0.yzw, r1.xzxy, r4.xxyz
mad r0.yzw, r1.xyzx, r4.xyzx, -r0
nrm r4.xyz, r0.yzww
mov r5.z, v1.x
mov r5.x, v2.x
mov r5.y, v0.x
mul r0.yzw, r1.xyzx, r5.xxyz
mad r0.yzw, r5.xzxy, r1.xzxy, -r0
nrm r5.xyz, r0.yzww
add r3.z, -r3.y, c13.w
texld r6, r3.xzzw, s2
mul r7.x, r6.w, v4.y
mul r0.yz, r3.xxzw, v3.xxzw
mul r0.yz, r0, c11.xxyw
mul r0.yz, r0, c14.x
texld r8, r0.yzzw, s3
texld r9, r0.yzzw, s5
add r0.yz, r9.xwyw, c14.y
mad r9.yz, r0, c13.x, c13.z
dp2add r0.y, r9.yzzw, -r9.yzzw, c13.w
max r1.w, r0.y, c12.y
rsq r0.y, r1.w
rcp r0.y, r0.y
mul r10.xyz, r5, r9.z
mad r10.xyz, r9.y, r4, r10
mad r0.yzw, r0.y, r1.xxyz, r10.xxyz
nrm r10.xyz, r0.yzww
texld r3, r3.xzzw, s4
add r0.yz, r3.xwyw, c14.y
mad r7.yz, r0, c13.x, c13.z
dp2add r0.y, r7.yzzw, -r7.yzzw, c13.w
max r1.w, r0.y, c12.y
rsq r0.y, r1.w
rcp r0.y, r0.y
mul r3.xyz, r5, r7.z
mad r3.xyz, r7.y, r4, r3
mad r0.yzw, r0.y, r1.xxyz, r3.xxyz
nrm r1.xyz, r0.yzww
cmp r0.yzw, -v4.x, r1.xxyz, r10.xxyz
cmp r1.xyz, -v4.x, r6, r8
mov r9.x, r7.x
cmp r3.xyw, -v4.x, r7.yzzx, r9.yzzx
abs r1.w, c9.x
dp2add r2.y, r3, r3, c12.y
rsq r2.y, r2.y
mul_sat r2.y, r2.y, r3.x
lrp r3.xyz, r2.y, c15, r1
cmp r1.xyz, -r1.w, r1, r3
mov r2.y, c12.y
if_lt -c6.x, r2.y
mad r2.xy, r2.xzzw, r0.x, -c7
add r2.zw, -c7.xyxy, c7
rcp r3.x, r2.z
rcp r3.y, r2.w
mul r2.xy, r2, r3
mov r4.xw, c13
mad r2.zw, c8.xyxy, -r4.x, r4.w
mad r2, r2.xyyy, r2.zwww, c8.xyyy
texldl r4, r2, s1
add r2, r2.xxww, c14.zwzw
mul_sat r2, r2, c15.w
mad r5, r2, c16.x, c16.y
mul r2, r2, r2
mul r2, r2, r5
mul r0.x, r4.w, r2.x
mul r0.x, r0.x, r2.z
mad r0.x, r2.y, -r0.x, r0.x
mad r0.x, r2.w, -r0.x, r0.x
else
mov r0.x, c13.w
endif
add r2.xy, r0.x, c16.zwzw
mul_sat r0.x, r2.x, c17.x
mad r1.w, r0.x, c16.x, c16.y
mul r0.x, r0.x, r0.x
mul r0.x, r0.x, r1.w
add_sat r1.w, r2.y, r2.y
mad r2.x, r1.w, c16.x, c16.y
mul r1.w, r1.w, r1.w
mul r1.w, r1.w, r2.x
mul r0.x, r0.x, c17.y
mul_sat r2.xyz, r0.x, r1
lrp r3.xyz, r1.w, r1, r2
rsq r0.x, r3.x
rsq r1.x, r3.y
rsq r1.y, r3.z
rcp oC1.x, r0.x
rcp oC1.y, r1.x
rcp oC1.z, r1.y
max r1.x, r0_abs.z, r0_abs.w
max r2.x, r0_abs.y, r1.x
rcp r0.x, r2.x
mul r0.xyz, r0.x, r0.yzww
mad oC0.xyz, r0, c12.w, c12.w
mov oC0.w, r3.w
mov oC1.w, r3.w

// approximately 167 instruction slots used (10 texture, 157 arithmetic)


Says it only concerns a lighting issue.

When I disable the following vertex shader the ground surface disappears, but there's no other visbile effect. There's no fix in Mike's package for this shader:

//
// Generated by Microsoft (R) HLSL Shader Compiler 9.27.952.3022
//
// Parameters:
//
// float4x4 view_projection;
//
//
// Registers:
//
// Name Reg Size
// --------------- ----- ----
// view_projection c0 4
//

vs_3_0
def c4, 1, 0, 0, 0
dcl_position v0
dcl_position1 v1
dcl_position2 v2
dcl_position3 v3
dcl_position4 v4
dcl_position5 v5
dcl_position o0
dcl_texcoord o1
dcl_texcoord1 o2
dcl_texcoord2 o3
dcl_texcoord3 o4
dcl_texcoord4 o5.xy
mad r0, v0.xyzx, c4.xxxy, c4.yyyx
dp4 r1.x, r0, v1
dp4 r1.y, r0, v2
dp4 r1.z, r0, v3
mov r1.w, c4.x
dp4 o0.x, r1, c0
dp4 o0.y, r1, c1
dp4 o0.z, r1, c2
dp4 o0.w, r1, c3
mov o1, v1
mov o2, v2
mov o3, v3
mov o4, v4
mov o5.xy, v5

// approximately 14 instruction slots used


Interestingly, when I disable both the vertex and the pixel shader, this is what happens:


Image


EDIT: I haven't looked into the role of texcoords at all so far. The main question I have atm is if these shaders are the right place to look for a fix at all, or whether it too has an "overlay" somewhere else where I need to be, as was the case for borders and rivers.

Posted 03/10/2015 11:07 AM   
ok, forget what I said about scissor clipping - it's clearly not that from the screenshots (scissor clipping occurs as a 2D rectangle at screen depth, while that box is clearly 3D and correctly positioned). I noticed in Mike's fix he is using matrices in c200-c203 and c204-c207, which are not in the headers. He is using a section like this to take the inv_view_projection matrix from c0-c3 and invert it so it becomes a regular view-projection matrix in c200-c203, then inverting it yet again into c204-c207 (the later will be approximately the same as the original matrix, but may be more numerically stable): [code] [PSFCC0E468] UseMatrix = true GetMatrixFromReg = 0 MatrixReg = 200 InverseMatrix = true DoubleInverseMatrix = true [/code] Make sure you have that in your DX9Settings.ini file (replace the hash with whichever shader you are looking at). Given the box you see when it's disabled I think you might be in the right place, so it probably is worth experimenting with these shaders to see if it is possible to move or disable the effect... but it's hard to say for certain, and I don't see any obvious clues in the shaders. My gut feeling is that this won't be another overlay like before, but I can't really be certain about that. [quote] Interestingly, when I disable both the vertex and the pixel shader, this is what happens:[/quote]Yep, if this is a light/shadow shader that would make sense - disabling it can kill the light source so the map is displayed as though the whole thing is in shadow.
ok, forget what I said about scissor clipping - it's clearly not that from the screenshots (scissor clipping occurs as a 2D rectangle at screen depth, while that box is clearly 3D and correctly positioned).

I noticed in Mike's fix he is using matrices in c200-c203 and c204-c207, which are not in the headers. He is using a section like this to take the inv_view_projection matrix from c0-c3 and invert it so it becomes a regular view-projection matrix in c200-c203, then inverting it yet again into c204-c207 (the later will be approximately the same as the original matrix, but may be more numerically stable):

[PSFCC0E468]
UseMatrix = true
GetMatrixFromReg = 0
MatrixReg = 200
InverseMatrix = true
DoubleInverseMatrix = true

Make sure you have that in your DX9Settings.ini file (replace the hash with whichever shader you are looking at).


Given the box you see when it's disabled I think you might be in the right place, so it probably is worth experimenting with these shaders to see if it is possible to move or disable the effect... but it's hard to say for certain, and I don't see any obvious clues in the shaders.


My gut feeling is that this won't be another overlay like before, but I can't really be certain about that.


Interestingly, when I disable both the vertex and the pixel shader, this is what happens:
Yep, if this is a light/shadow shader that would make sense - disabling it can kill the light source so the map is displayed as though the whole thing is in shadow.

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 03/10/2015 03:45 PM   
That worked! So what this entry in the ini instructs is to get the matrix from registry 0 (inv_view_projection), put the inverse and double inverse matrices into registries c200 and onwards? A couple of things not quite clear yet. - the use of "rcp". Is this something to do with how matrix calculations work? - the fact that the fix here substracts from x rather than adds to it.
That worked! So what this entry in the ini instructs is to get the matrix from registry 0 (inv_view_projection), put the inverse and double inverse matrices into registries c200 and onwards?

A couple of things not quite clear yet.
- the use of "rcp". Is this something to do with how matrix calculations work?
- the fact that the fix here substracts from x rather than adds to it.

Posted 03/10/2015 10:43 PM   
[quote="Muizer"]That worked! So what this entry in the ini instructs is to get the matrix from registry 0 (inv_view_projection), put the inverse and double inverse matrices into registries c200 and onwards?[/quote]Exactly ;-) [quote]A couple of things not quite clear yet. - the use of "rcp". Is this something to do with how matrix calculations work? [/quote]rcp is reciprocal (1/value) and it's the way to do divisions in shader assembly. Looking at the fix Mike is using it to normalise a four dimensional homogeneous coordinate into the equivalent three dimensional cartesian coordinate before applying the fix, then scaling it back to the original afterwards. I'm not entirely clear on the maths as to why this is necessary for this particular fix either (and I just made a mental note to try this in future), but I would note that the original shader does the same thing further down if you look for where it uses r0.x. Projection matrices cause a coordinate to not be normalised (you may have heard the term "perspective divide", which is the normalisation process that turns the result of a projection into screen coordinates), so perhaps the same can happen with an inverse projection? As I said I'm not 100% on the maths here, so I'm not certain. [quote]- the fact that the fix here substracts from x rather than adds to it.[/quote]This is pretty common when correcting a world-space coordinate. My understanding is that the original coordinate will have already been adjusted for stereo by the driver, and when the game un-projects that coordinate to find the original world coordinates the correction needs to be subtracted so that it gets the real original coordinate, and not some skewed version.
Muizer said:That worked! So what this entry in the ini instructs is to get the matrix from registry 0 (inv_view_projection), put the inverse and double inverse matrices into registries c200 and onwards?
Exactly ;-)


A couple of things not quite clear yet.
- the use of "rcp". Is this something to do with how matrix calculations work?
rcp is reciprocal (1/value) and it's the way to do divisions in shader assembly.

Looking at the fix Mike is using it to normalise a four dimensional homogeneous coordinate into the equivalent three dimensional cartesian coordinate before applying the fix, then scaling it back to the original afterwards. I'm not entirely clear on the maths as to why this is necessary for this particular fix either (and I just made a mental note to try this in future), but I would note that the original shader does the same thing further down if you look for where it uses r0.x.

Projection matrices cause a coordinate to not be normalised (you may have heard the term "perspective divide", which is the normalisation process that turns the result of a projection into screen coordinates), so perhaps the same can happen with an inverse projection? As I said I'm not 100% on the maths here, so I'm not certain.


- the fact that the fix here substracts from x rather than adds to it.
This is pretty common when correcting a world-space coordinate. My understanding is that the original coordinate will have already been adjusted for stereo by the driver, and when the game un-projects that coordinate to find the original world coordinates the correction needs to be subtracted so that it gets the real original coordinate, and not some skewed version.

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 03/11/2015 12:02 AM   
[quote="DarkStarSword"] I've also found it's worth trying 1110 and 0001 to disable effects in the pixel shader - it depends largely on how their result is being used by the game. There are two other ways you can try to disable a pixel shader if you can't find any output that works: - Comment out everything in the shader after the ps_3_0 line - Use the texkill instruction, which cancels the current pixel render if you pass it a temporary register with negative value in any of the first three components, e.g. [/quote] 1110 & 0001 did not fix the effect. I tried commenting out all the lines after ps_3_0 line but that disables the tree trunks. The same thing happens when I use texkill command.
DarkStarSword said:
I've also found it's worth trying 1110 and 0001 to disable effects in the pixel shader - it depends largely on how their result is being used by the game. There are two other ways you can try to disable a pixel shader if you can't find any output that works:

- Comment out everything in the shader after the ps_3_0 line
- Use the texkill instruction, which cancels the current pixel render if you pass it a temporary register with negative value in any of the first three components, e.g.


1110 & 0001 did not fix the effect. I tried commenting out all the lines after ps_3_0 line but that disables the tree trunks. The same thing happens when I use texkill command.

Posted 03/13/2015 11:53 AM   
I'm just going through lesson 1. There's a bit of an oddity thatI don't quite understand. The lesson refers to LOG.txt and a Dumps folder in The Ball\Binaries\Win32. However, even after running The Ball with helixmod a few times, cycling through shaders and all that, I didn't have those in those locations. I had both LOG.TXT and the Dumps folder in The Ball\ (ie. the root folder). The Dumps folder had the AllShaders and SingleShaders folder inside, but they were both empty. It seems that the problem might be because I was running the Ball by using the Windows 7 "recent" right-click menu: I would right-click the Steam icon in the taskbar, and then select The Ball from the list of recently opened games. On a hunch, I tried double-clicking TheBall.exe directly from within The Ball\Binaries\Win32, and immediately LOG.txt and Dumps were created in The Ball\Binaries\Win32 as they were supposed to. And this time, the AllShaders and Singleshaders folders actually had files in them. Has anyone had this happen to them as well?
I'm just going through lesson 1. There's a bit of an oddity thatI don't quite understand.

The lesson refers to LOG.txt and a Dumps folder in The Ball\Binaries\Win32.

However, even after running The Ball with helixmod a few times, cycling through shaders and all that, I didn't have those in those locations. I had both LOG.TXT and the Dumps folder in The Ball\ (ie. the root folder). The Dumps folder had the AllShaders and SingleShaders folder inside, but they were both empty.

It seems that the problem might be because I was running the Ball by using the Windows 7 "recent" right-click menu: I would right-click the Steam icon in the taskbar, and then select The Ball from the list of recently opened games.

On a hunch, I tried double-clicking TheBall.exe directly from within The Ball\Binaries\Win32, and immediately LOG.txt and Dumps were created in The Ball\Binaries\Win32 as they were supposed to. And this time, the AllShaders and Singleshaders folders actually had files in them.

Has anyone had this happen to them as well?

ImageVolnaPC.com - Tips, tweaks, performance comparisons (PhysX card, SLI scaling, etc)

Posted 03/14/2015 11:30 AM   
  28 / 87    
Scroll To Top