Bo3b's School For Shaderhackers
  50 / 88    
[quote="3d4dd"]Because of the necessary UseExtInterfaceOnly=true all the texture CRCs are shown as 0xFFFFFFFF as 4everAwake and DarkStarSword already said.[/quote]I can't recall all the details, but in ETS2 I used UseExtInterfaceOnly and do have *some* working texture CRCs. I have added both these options to the DX9Settings.ini - I can't remember exactly what difference they made, but I think I needed one or both of them: [code] CalcTexCRCatUpdate = true bCalcTexCRCatStart = true [/code] Notably, I actually explicitly match the FFFFFFFF hash in ETS2 as it only seemed to be used for dynamically updated textures, like the clouds in the sky - and that was what I needed to push to infinity, while everything else on that particular shader had valid hashes (but I may have just got lucky). I also left myself a note in the shader that I was unable to combine both texture filtering with partner shader filtering in Helix Mod because the [VS] section can't match either shaders hash when using partner shader filtering. [quote]Another problem was the fact that some VS I hunted and placed without any changes into the ShaderOverride just disabled the effect I wanted to fix.[/quote]Do they by any chance use s0 in the shader already? If they do you might want to change which stereo sampler you are using for vertex shaders, e.g. with: [code] DefVSSampler = 260 [/code] That will use s3 instead of s0 (there's a quirk with sampler register numbers in vertex shaders - add 257 to them). You can either add that in the [General] section to change it on all vertex shaders, or a [VS] section to only change it on that specific shader. Also, if the shaders have a preshader section you will need to comment it out - the first uncommented line should be vs_3_0 [quote]Changing these VS even caused the game to crash! So I e.g. couldn't push the sun to dept.[/quote]:( [quote]Most important is the fix for the shadows that worked excellent in every situation I tried so far :)[/quote]=D
3d4dd said:Because of the necessary UseExtInterfaceOnly=true all the texture CRCs are shown as 0xFFFFFFFF as 4everAwake and DarkStarSword already said.
I can't recall all the details, but in ETS2 I used UseExtInterfaceOnly and do have *some* working texture CRCs. I have added both these options to the DX9Settings.ini - I can't remember exactly what difference they made, but I think I needed one or both of them:
CalcTexCRCatUpdate = true
bCalcTexCRCatStart = true


Notably, I actually explicitly match the FFFFFFFF hash in ETS2 as it only seemed to be used for dynamically updated textures, like the clouds in the sky - and that was what I needed to push to infinity, while everything else on that particular shader had valid hashes (but I may have just got lucky).

I also left myself a note in the shader that I was unable to combine both texture filtering with partner shader filtering in Helix Mod because the [VS] section can't match either shaders hash when using partner shader filtering.

Another problem was the fact that some VS I hunted and placed without any changes into the ShaderOverride just disabled the effect I wanted to fix.
Do they by any chance use s0 in the shader already? If they do you might want to change which stereo sampler you are using for vertex shaders, e.g. with:
DefVSSampler = 260

That will use s3 instead of s0 (there's a quirk with sampler register numbers in vertex shaders - add 257 to them). You can either add that in the [General] section to change it on all vertex shaders, or a [VS] section to only change it on that specific shader.

Also, if the shaders have a preshader section you will need to comment it out - the first uncommented line should be vs_3_0

Changing these VS even caused the game to crash! So I e.g. couldn't push the sun to dept.
:(

Most important is the fix for the shadows that worked excellent in every situation I tried so far :)
=D

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 01/13/2016 02:31 AM   
[quote="DarkStarSword"]Do they by any chance use s0 in the shader already?[/quote] Yes, and this was the reason for the issues. DefVSSampler = 260 was the solution and allowed me to fix the sun and several lense flare effects. So now... [quote="DarkStarSword"] [quote]Changing these VS even caused the game to crash! So I e.g. couldn't push the sun to dept.[/quote]:( [/quote] =D Thanks to Your hint ^^ I have allready tried CalcTexCRCatUpdate = true and bCalcTexCRCatStart = true but still got FFFFFFFF for every kind of texture. But with .txt.ps I could separate HUD elements from other effects.
DarkStarSword said:Do they by any chance use s0 in the shader already?

Yes, and this was the reason for the issues. DefVSSampler = 260 was the solution and allowed me to fix the sun and several lense flare effects. So now...
DarkStarSword said:
Changing these VS even caused the game to crash! So I e.g. couldn't push the sun to dept.
:(

=D Thanks to Your hint ^^

I have allready tried CalcTexCRCatUpdate = true and bCalcTexCRCatStart = true but still got FFFFFFFF for every kind of texture. But with .txt.ps I could separate HUD elements from other effects.

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 01/13/2016 10:16 PM   
[quote="DarkStarSword"]This might be interesting to people - I've worked out how nvidia inject the separation and convergence into vertex shaders to apply their stereo correction. I found this while I was adding a feature to 3DMigoto to copy vertex buffers into shaders as constant buffers (although I have since added the ability to copy them in as structured buffers, which are a lot easier to work with, but I digress - I'll cover that in more detail when I release the FC4 update that uses it). At one point I had this: [code] [ShaderOverrideHUD] vs-cb12 = vb0 [/code] Which wasn't working, but I couldn't find any reason why it wasn't working - frame analysis showed that my injected buffer was loaded in the cb12 slot and it contained the correct data copied from the correct offset from the vertex buffer, but it's values were complete garbage when I tried to use them in the shader - they weren't the values I was seeing dumped in frame analysis, but they weren't 0 either. Eventually, I tried this: [code] if (cb12[0].x > 0) { o0 = 0; return; } [/code] As expected that disabled the shader... but unexpectedly it only disabled it in one eye! I then changed it to use constant buffer 11 instead and everything started working. So, I seem to have found a constant buffer that is hidden from the CPU (frame analysis doesn't show it), but available to the GPU and appears to contain different values in each eye. And if the game happened to use constant buffer 12 itself it would be clobbered by this hidden stereo constant buffer (perhaps there is a setting somewhere to change which constant buffer it uses). So, today I experiemented a little more with the values in constant buffer 12 and have determined that the structure seems to be: [code] cbuffer NVStereoCB : register(b12) { float nv_negative_separation_convergence; float nv_separation; float nv_unused; float nv_stereo_enabled; } [/code] So, the first value might look a bit weird, but it's a precomputation of the part of the formula that does not depend on the depth (I don't think it saves them any instructions though, but maybe they have another reason for doing it that way). Seeing if we can apply this, if this is how we would usually fix a halo type issue: [code] ... r1.xyzw = cb2[1].xyzw * r0.yyyy; r1.xyzw = cb2[0].xyzw * r0.xxxx + r1.xyzw; r1.xyzw = cb2[2].xyzw * r0.zzzz + r1.xyzw; r1.xyzw = cb2[3].xyzw * v0.wwww + r1.xyzw; o0.xyzw = r1.xyzw; float4 stereo = StereoParams.Load(0); r1.x += stereo.x * (r1.w - stereo.y); o1.xy = v3.xy; p1.xy = v4.xy; ... [/code] Then you might expect we would change it to this: [code] ... r1.xyzw = cb2[1].xyzw * r0.yyyy; r1.xyzw = cb2[0].xyzw * r0.xxxx + r1.xyzw; r1.xyzw = cb2[2].xyzw * r0.zzzz + r1.xyzw; r1.xyzw = cb2[3].xyzw * v0.wwww + r1.xyzw; o0.xyzw = r1.xyzw; r1.x += nv_separation * r1.w + nv_negative_separation_convergence; o1.xy = v3.xy; p1.xy = v4.xy; ... [/code] But it turns out that doesn't work - if the shader is accessing cb12, the driver will not apply it's stereo correction, so we actually need to apply it before o0 is set: [code] ... r1.xyzw = cb2[1].xyzw * r0.yyyy; r1.xyzw = cb2[0].xyzw * r0.xxxx + r1.xyzw; r1.xyzw = cb2[2].xyzw * r0.zzzz + r1.xyzw; r1.xyzw = cb2[3].xyzw * v0.wwww + r1.xyzw; r1.x += nv_separation * r1.w + nv_negative_separation_convergence; o0.xyzw = r1.xyzw; o1.xy = v3.xy; p1.xy = v4.xy; ... [/code] Notably this constant buffer does not seem to be available in pixel shaders (of at least it doesn't seem to be in cb12), which makes sense since the driver doesn't change them. Should you use this? Probably not - there's no way to know if nvidia will change this in the future, and it's only injected into vertex shaders. Performance might be slightly better (this generally applies to constant buffers over shader resources), but it would be marginal. The only interesting thing I see here is the fact that using it disables nvidia's stereo correction, but we can usually just subtract that ourselves if needed. Better off to stick to the 3DMigoto stereo texture I think.[/quote]After tonight's update to The Forest breaking Ceto water again (it uses all four samplers in the VS so *something* will break no matter which you pick with Helix Mod) I did a couple of experiments to see if the same thing happens in DX9 (with the intent to binary patch Helix mod to disable it's stereo texture), and sure enough it does: [code] c255.x = -separation * convergence c255.y = separation [/code] Unlike DX11 using this in the shader will not disable the driver's stereo correction. But there's a catch (isn't there always?) - that constant register is only set for vertex shaders where the driver is applying a correction, otherwise it is 0. OTOH that might actually turn out to be useful in it's own right to determine if the driver is applying a stereo correction or not for cases where it is inconsistent, or potentially for use in combination with auto halo fixes to prevent them being applied to shaders that the driver is not adjusting (--use-nv-stereo-reg-vs added to shadertool). It is unknown how reliable using this would be - it could well change in a driver or profile update, so I don't really recommend using it when the Helix Mod sampler will do, but I'm putting this out there in case it is useful to someone. I'm putting my experiments using this in The Forest back on hold for now and might revisit it later when it's out of early access (because who knows what else will change in the meantime). If anyone wanted to try it, it's in the "the_forest_stereo_register" topic branch on my 3d-fixes. Almost all vertex shaders are converted to use it (lights, halos, parallax occlusion shaders, HUD). The exceptions are light shafts and sky glow which had 0 in c255, though I could potentially move those fixes into the pixel shader. If I do end up pursuing this all the way it would mean killing the auto HUD so I could use 0 VS samplers, but that's only used for a couple of icons in The Forest (most of the HUD was already 3D) so would probably be acceptable. It could also help in Stranded Deep which also uses Ceto water, however unlike The Forest it works in DX11 so I'd probably rather switch it to that once my DX11 scripts are on parity with my DX9 scripts, and killing the auto HUD would not be a good compromise in that game.
DarkStarSword said:This might be interesting to people - I've worked out how nvidia inject the separation and convergence into vertex shaders to apply their stereo correction.

I found this while I was adding a feature to 3DMigoto to copy vertex buffers into shaders as constant buffers (although I have since added the ability to copy them in as structured buffers, which are a lot easier to work with, but I digress - I'll cover that in more detail when I release the FC4 update that uses it). At one point I had this:

[ShaderOverrideHUD]
vs-cb12 = vb0

Which wasn't working, but I couldn't find any reason why it wasn't working - frame analysis showed that my injected buffer was loaded in the cb12 slot and it contained the correct data copied from the correct offset from the vertex buffer, but it's values were complete garbage when I tried to use them in the shader - they weren't the values I was seeing dumped in frame analysis, but they weren't 0 either. Eventually, I tried this:

if (cb12[0].x > 0) {
o0 = 0;
return;
}

As expected that disabled the shader... but unexpectedly it only disabled it in one eye! I then changed it to use constant buffer 11 instead and everything started working.

So, I seem to have found a constant buffer that is hidden from the CPU (frame analysis doesn't show it), but available to the GPU and appears to contain different values in each eye. And if the game happened to use constant buffer 12 itself it would be clobbered by this hidden stereo constant buffer (perhaps there is a setting somewhere to change which constant buffer it uses).

So, today I experiemented a little more with the values in constant buffer 12 and have determined that the structure seems to be:

cbuffer NVStereoCB : register(b12)
{
float nv_negative_separation_convergence;
float nv_separation;
float nv_unused;
float nv_stereo_enabled;
}

So, the first value might look a bit weird, but it's a precomputation of the part of the formula that does not depend on the depth (I don't think it saves them any instructions though, but maybe they have another reason for doing it that way).

Seeing if we can apply this, if this is how we would usually fix a halo type issue:

...
r1.xyzw = cb2[1].xyzw * r0.yyyy;
r1.xyzw = cb2[0].xyzw * r0.xxxx + r1.xyzw;
r1.xyzw = cb2[2].xyzw * r0.zzzz + r1.xyzw;
r1.xyzw = cb2[3].xyzw * v0.wwww + r1.xyzw;
o0.xyzw = r1.xyzw;

float4 stereo = StereoParams.Load(0);
r1.x += stereo.x * (r1.w - stereo.y);

o1.xy = v3.xy;
p1.xy = v4.xy;
...

Then you might expect we would change it to this:

...
r1.xyzw = cb2[1].xyzw * r0.yyyy;
r1.xyzw = cb2[0].xyzw * r0.xxxx + r1.xyzw;
r1.xyzw = cb2[2].xyzw * r0.zzzz + r1.xyzw;
r1.xyzw = cb2[3].xyzw * v0.wwww + r1.xyzw;
o0.xyzw = r1.xyzw;

r1.x += nv_separation * r1.w + nv_negative_separation_convergence;

o1.xy = v3.xy;
p1.xy = v4.xy;
...

But it turns out that doesn't work - if the shader is accessing cb12, the driver will not apply it's stereo correction, so we actually need to apply it before o0 is set:

...
r1.xyzw = cb2[1].xyzw * r0.yyyy;
r1.xyzw = cb2[0].xyzw * r0.xxxx + r1.xyzw;
r1.xyzw = cb2[2].xyzw * r0.zzzz + r1.xyzw;
r1.xyzw = cb2[3].xyzw * v0.wwww + r1.xyzw;

r1.x += nv_separation * r1.w + nv_negative_separation_convergence;

o0.xyzw = r1.xyzw;
o1.xy = v3.xy;
p1.xy = v4.xy;
...

Notably this constant buffer does not seem to be available in pixel shaders (of at least it doesn't seem to be in cb12), which makes sense since the driver doesn't change them.

Should you use this? Probably not - there's no way to know if nvidia will change this in the future, and it's only injected into vertex shaders. Performance might be slightly better (this generally applies to constant buffers over shader resources), but it would be marginal. The only interesting thing I see here is the fact that using it disables nvidia's stereo correction, but we can usually just subtract that ourselves if needed. Better off to stick to the 3DMigoto stereo texture I think.
After tonight's update to The Forest breaking Ceto water again (it uses all four samplers in the VS so *something* will break no matter which you pick with Helix Mod) I did a couple of experiments to see if the same thing happens in DX9 (with the intent to binary patch Helix mod to disable it's stereo texture), and sure enough it does:
c255.x = -separation * convergence
c255.y = separation

Unlike DX11 using this in the shader will not disable the driver's stereo correction.

But there's a catch (isn't there always?) - that constant register is only set for vertex shaders where the driver is applying a correction, otherwise it is 0. OTOH that might actually turn out to be useful in it's own right to determine if the driver is applying a stereo correction or not for cases where it is inconsistent, or potentially for use in combination with auto halo fixes to prevent them being applied to shaders that the driver is not adjusting (--use-nv-stereo-reg-vs added to shadertool). It is unknown how reliable using this would be - it could well change in a driver or profile update, so I don't really recommend using it when the Helix Mod sampler will do, but I'm putting this out there in case it is useful to someone.

I'm putting my experiments using this in The Forest back on hold for now and might revisit it later when it's out of early access (because who knows what else will change in the meantime). If anyone wanted to try it, it's in the "the_forest_stereo_register" topic branch on my 3d-fixes. Almost all vertex shaders are converted to use it (lights, halos, parallax occlusion shaders, HUD). The exceptions are light shafts and sky glow which had 0 in c255, though I could potentially move those fixes into the pixel shader. If I do end up pursuing this all the way it would mean killing the auto HUD so I could use 0 VS samplers, but that's only used for a couple of icons in The Forest (most of the HUD was already 3D) so would probably be acceptable.

It could also help in Stranded Deep which also uses Ceto water, however unlike The Forest it works in DX11 so I'd probably rather switch it to that once my DX11 scripts are on parity with my DX9 scripts, and killing the auto HUD would not be a good compromise in that game.

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 01/21/2016 03:55 PM   
Hey guys. I've managed to make some decent progress fixing shadows in the game Dragon's Dogma, but I've hit a bit of a wall that I can't get past. DD uses the same engine Capcom uses for their Resident Evil games, so I've been using mike_ar69's RE6 fix as a reference to be able to fix similar shaders here. First, allow me to explain what has worked (and, in turn, is not working for me elsewhere). The player can attach a lantern to their hip as a source of light, which creates dynamic shadows off of most objects/environment. I've managed to fix this by following the advice given to me in the past: first I located the VS and PS pair that creates the light (on a side note, when the VS was skipped in the debugger, the light disappeared, however when the PS was skipped the light was changed to white). I subtracted the stereo fix from the position output in the vertex, grabbed the VPM from the VS and passed into the PS through the .ini, and then performed the stereo fix in there the same way and spot that Mike did in every PS shader in RE6. Surprisingly, this wasn't enough. My understanding is when I subtract the stereo correction from the VS, the shadows should have appeared at depth/in 2D, but they weren't and still stereo (in fact, the correction did very little movement). What was actually required was for me to also find the VS for the shadow itself (shadowcaster, I think they're called?) and perform the stereo fix on the output position there, and bingo! Player shadows were fixed. I then had to locate other shadowcaster VS's for each different type of object in the game that creates shadows and perform individual fixes. Don't know if this all was right (because that certainly wasn't required in Mike's RE6 fix), but it worked! Super. Awesome. Wonderful. Until I walk into the very next area of the game, and come out into an opening which has some additional lighting from the sky that creates shadows of various objects that are in 2D/at screen depth, and there's some additional shadows on the walls/landscape that are not 2D, but quite broken. Even better, a dragon comes along lights me up, and now the whole area is on fire. Fire creates light. Light creates even more shadows, and they are all broken. So, ok, I figure I could run the same strategy. I scroll through all the VS's and could only find one that cut out all lights and shadows (and seemed appropriate from looking at the code), I found one PS that causes all the illumination in the area to turn white, and a few different VS's that correspond to the shadows themselves (one which disabled all the shadows and a few for individual shadows). I tried to apply the stereo correction to the VS for the lighting, and that simply just broke the lighting badly. I figured since many of the shadows were in 2D already, maybe a VS fix wasn't required. Moved onto the PS I mentioned and tried fixing it and absolutely no change whatsoever. Then I tried fixing the VS responsible for all the shadows, and that just made them all disappear. Tried fixing one or 2 individual shadow VS's and at least there I was able to get them stereoized, but not correctly. There was also another PS that seemed promising, that was nearly identical to one of the shaders Mike fixed in RE6, but when applying the same fix it basically disabled the shader/all shadows. There were a few other VS's that seemed to cut shadows/lights, but when I looked at the code they didn't look right at all (maybe 10-15 lines of code in total), so didn't bother trying to fix any of those... Ok, I'm rambling now, but I'm just trying to mention everything relevant, and give an idea of the many MANY things I've tried, including all sorts of different variations of the fix, fixing various combinations of shaders together, etc. Probably spent around 5-10 hours (maybe more) on this particular area alone and haven't come out on top. So yeah, anyway, what I should also mention is that from studying Mike's RE6 fix, I was able to determine the pattern/commonalities in the broken shaders there, scan the DD dumps folder, find over 100 matching shaders, and create/run some macros I made to fix them all with the appropriate code. If I disable a couple of the shaders for shadows from environmental lighting, the game looks great while running around interiors with the player's lamp creating lighting/shadows nicely, but I believe a good deal of the game will involve running around outside, so no environmental lighting shadows is a big miss, and I'm hoping if I could get a little help on this one area, then I should be able to proceed and fix the rest of it... so here I am hoping to get some help from the guru's here. I'll post up some of the code in a following post.
Hey guys. I've managed to make some decent progress fixing shadows in the game Dragon's Dogma, but I've hit a bit of a wall that I can't get past. DD uses the same engine Capcom uses for their Resident Evil games, so I've been using mike_ar69's RE6 fix as a reference to be able to fix similar shaders here.

First, allow me to explain what has worked (and, in turn, is not working for me elsewhere). The player can attach a lantern to their hip as a source of light, which creates dynamic shadows off of most objects/environment. I've managed to fix this by following the advice given to me in the past: first I located the VS and PS pair that creates the light (on a side note, when the VS was skipped in the debugger, the light disappeared, however when the PS was skipped the light was changed to white). I subtracted the stereo fix from the position output in the vertex, grabbed the VPM from the VS and passed into the PS through the .ini, and then performed the stereo fix in there the same way and spot that Mike did in every PS shader in RE6.

Surprisingly, this wasn't enough. My understanding is when I subtract the stereo correction from the VS, the shadows should have appeared at depth/in 2D, but they weren't and still stereo (in fact, the correction did very little movement). What was actually required was for me to also find the VS for the shadow itself (shadowcaster, I think they're called?) and perform the stereo fix on the output position there, and bingo! Player shadows were fixed. I then had to locate other shadowcaster VS's for each different type of object in the game that creates shadows and perform individual fixes. Don't know if this all was right (because that certainly wasn't required in Mike's RE6 fix), but it worked!

Super. Awesome. Wonderful. Until I walk into the very next area of the game, and come out into an opening which has some additional lighting from the sky that creates shadows of various objects that are in 2D/at screen depth, and there's some additional shadows on the walls/landscape that are not 2D, but quite broken. Even better, a dragon comes along lights me up, and now the whole area is on fire. Fire creates light. Light creates even more shadows, and they are all broken.

So, ok, I figure I could run the same strategy. I scroll through all the VS's and could only find one that cut out all lights and shadows (and seemed appropriate from looking at the code), I found one PS that causes all the illumination in the area to turn white, and a few different VS's that correspond to the shadows themselves (one which disabled all the shadows and a few for individual shadows). I tried to apply the stereo correction to the VS for the lighting, and that simply just broke the lighting badly. I figured since many of the shadows were in 2D already, maybe a VS fix wasn't required. Moved onto the PS I mentioned and tried fixing it and absolutely no change whatsoever. Then I tried fixing the VS responsible for all the shadows, and that just made them all disappear. Tried fixing one or 2 individual shadow VS's and at least there I was able to get them stereoized, but not correctly. There was also another PS that seemed promising, that was nearly identical to one of the shaders Mike fixed in RE6, but when applying the same fix it basically disabled the shader/all shadows. There were a few other VS's that seemed to cut shadows/lights, but when I looked at the code they didn't look right at all (maybe 10-15 lines of code in total), so didn't bother trying to fix any of those... Ok, I'm rambling now, but I'm just trying to mention everything relevant, and give an idea of the many MANY things I've tried, including all sorts of different variations of the fix, fixing various combinations of shaders together, etc. Probably spent around 5-10 hours (maybe more) on this particular area alone and haven't come out on top.

So yeah, anyway, what I should also mention is that from studying Mike's RE6 fix, I was able to determine the pattern/commonalities in the broken shaders there, scan the DD dumps folder, find over 100 matching shaders, and create/run some macros I made to fix them all with the appropriate code. If I disable a couple of the shaders for shadows from environmental lighting, the game looks great while running around interiors with the player's lamp creating lighting/shadows nicely, but I believe a good deal of the game will involve running around outside, so no environmental lighting shadows is a big miss, and I'm hoping if I could get a little help on this one area, then I should be able to proceed and fix the rest of it... so here I am hoping to get some help from the guru's here. I'll post up some of the code in a following post.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 01/26/2016 02:34 AM   
Ok, so I'll post the code for the most potential candidates. I'll also include a link to a zip with the collection of other shaders that I thought might be relevant. [u][b]Vertex Shaders[/b][/u] VS5802BB90 (All lighting in area) [code]// Environment/ambient light // "Fixing" breaks lights, creates black patches // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 // // Parameters: // // float4 CBROPTest__packed0; // float2 fScreenHalfPixelOffset; // row_major float4x4 fViewProj; // row_major float3x4 fWorld; // // // Registers: // // Name Reg Size // ---------------------- ----- ---- // fViewProj c1 4 // fWorld c5 3 // CBROPTest__packed0 c8 1 // fScreenHalfPixelOffset c9 1 // vs_3_0 def c220, 0, 0, 0.0625, 0 dcl_2d s3 def c0, 1, 0, 0, 0 dcl_position v0 dcl_position o0 dcl_color o1.xy mad r0, v0.xyzx, c0.xxxy, c0.yyyx dp4 r1.x, c6, r0 mul r1, r1.x, c2 dp4 r2.x, c5, r0 dp4 r0.x, c7, r0 mad r1, r2.x, c1, r1 mad r0, r0.x, c3, r1 add r0, r0, c4 // texldl r24, c220.z, s3 // add r24.y, r0.w, -r24.y // mul r24.x, r24.x, r24.y // mul r24.x, r24.x, c1.x //Tried with and without FOV multiply // add r0.x, r0.x, -r24.x mad o0.x, c9.x, -r0.w, r0.x //Tried replacing next 3 lines of code with the code below mad o0.y, c9.y, r0.w, r0.y add o0.z, r0.z, c8.z mov o0.w, r0.w // mad r10.x, c9.x, -r0.w, r0.x // mad r10.y, c9.y, r0.w, r0.y // add r10.z, r0.z, c8.z // mov r10.w, r0.w // texldl r24, c220.z, s3 // add r24.y, r10.w, -r24.y // mul r24.x, r24.x, r24.y // mul r24.x, r24.x, c1.x //Tried with and without FOV multiply // add r10.x, r10.x, -r24.x // mov o0, r10 mov o1.xy, r0.zwzw // approximately 13 instruction slots used [/code] VS66938957 - All shadows [code]// Environment light shadowcaster // Fixing causes shadows to disappear // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 // // Parameters: // // float4 CBViewProjection__packed4; // float4 CBViewProjection__packed5; // float2 fScreenHalfPixelOffset; // row_major float4x4 fViewProjI; // // // Registers: // // Name Reg Size // ------------------------- ----- ---- // fViewProjI c1 4 // fScreenHalfPixelOffset c5 1 // CBViewProjection__packed4 c6 1 // CBViewProjection__packed5 c7 1 // vs_3_0 def c220, 0, 0, 0.0625, 0 dcl_2d s3 def c0, 0, 1, 0, 0 dcl_position v0 dcl_position o0 dcl_texcoord o1 mul r0, c2, v0.y mad r0, v0.x, c1, r0 add r0, r0, c4 rcp r0.w, r0.w mad r0.xyz, r0, r0.w, -c6 // texldl r24, c220.z, s3 // add r24.y, r0.w, -r24.y // mul r24.x, r24.x, r24.y // mul r24.x, r24.x, c1.x // add r0.x, r0.x, -r24.x dp3 r0.w, c7, r0 rcp r0.w, r0.w mul o1.xyz, r0.w, r0 add o0.x, -c5.x, v0.x add o0.y, c5.y, v0.y mov o0.zw, c0.xyxy // add r10.x, -c5.x, v0.x // add r10.y, c5.y, v0.y // mov r10.zw, c0.xyxy // texldl r24, c220.z, s3 // add r24.y, r10.w, -r24.y // mul r24.x, r24.x, r24.y // mul r24.x, r24.x, c1.x // add r10.x, r10.x, -r24.x // mov o0, r10 mov o1.w, c0.x //mov o0.xyzw, c220.xxxx // approximately 12 instruction slots used [/code] VSB1C65FCF - Many shadows created by environment/landscape [code]// Environment/Landscape shadows // // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 // // Parameters: // // float4 CBShadowCast__packed0; // float4 CBShadowLight__packed1; // float2 fScreenHalfPixelOffset; // row_major float4x4 fViewProj; // row_major float3x4 fWorld; // // // Registers: // // Name Reg Size // ---------------------- ----- ---- // fViewProj c1 4 // fWorld c5 3 // fScreenHalfPixelOffset c8 1 // CBShadowLight__packed1 c9 1 // CBShadowCast__packed0 c10 1 // vs_3_0 def c220, 0, 0, 0.0625, 0 dcl_2d s3 def c0, 1, 0, 0, 0 dcl_position v0 dcl_position o0 dcl_color o1.xy mad r0, v0.xyzx, c0.xxxy, c0.yyyx dp4 r1.x, c5, r0 dp4 r1.y, c6, r0 dp4 r1.z, c7, r0 mov r0.yzw, c9 mad r0.xyz, r0.yzww, c10.x, r1 mul r1, r0.y, c2 mad r1, r0.x, c1, r1 mad r0, r0.z, c3, r1 add r0, r0, c4 // texldl r24, c220.z, s3 // add r24.y, r0.w, -r24.y // mul r24.x, r24.x, r24.y // mul r24.x, r24.x, c1.x // add r0.x, r0.x, -r24.x mad o0.x, c8.x, -r0.w, r0.x mad o0.y, c8.y, r0.w, r0.y mov o0.zw, r0 // mad r10.x, c8.x, -r0.w, r0.x // mad r10.y, c8.y, r0.w, r0.y // mov r10.zw, r0 // texldl r24, c220.z, s3 // add r24.y, r10.w, -r24.y // mul r24.x, r24.x, r24.y // mul r24.x, r24.x, c1.x // add r10.x, r10.x, r24.x // mov o0, r10 mov o1.xy, r0.zwzw // approximately 14 instruction slots used [/code] [u][b]Pixel Shaders[/b][/u] PSC807096D - Lighting in area turns white [code]// Dragon area - All lighting/shadows go white // Fixing does nothing // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 // // Parameters: // // float4 CBLightVolume__packed0; // float4 CBScreen__packed1; // float4 CBViewProjection__packed4; // float4 CBViewProjection__packed5; // sampler2D SSBorderPoint__tComparisonTexture; // sampler2D SSBorderPoint__tGBuffer; // sampler2D SSClampPoint__tSpheremapLutTexture; // sampler2D SSPoint__tDepthMap; // sampler2D SSPoint__tLightMaskMap; // float fLightGroup; // row_major float4x4 fProj; // row_major float4x4 fViewI; // // struct // { // float4 __packed0; // float4 __packed1; // float4 __packed2; // float4 fAttenuation; // float4 fAttenuation2; // row_major float3x4 fLightRangeMat; // row_major float4x4 fLightProjMat; // // } sLightParam0; // // // Registers: // // Name Reg Size // ---------------------------------- ----- ---- // fProj c1 4 // sLightParam0 c5 4 // fViewI c9 3 // CBScreen__packed1 c12 1 // CBViewProjection__packed4 c13 1 // CBViewProjection__packed5 c14 1 // fLightGroup c15 1 // CBLightVolume__packed0 c16 1 // SSBorderPoint__tGBuffer s0 1 // SSBorderPoint__tComparisonTexture s1 1 // SSClampPoint__tSpheremapLutTexture s2 1 // SSPoint__tDepthMap s3 1 // SSPoint__tLightMaskMap s4 1 // ps_3_0 def c220, 0, 0, 0.0625, 0 dcl_2d s13 def c0, 0.5, 0.99609375, 0.001953125, 11.5415602 def c17, 1, 0.00392156886, 1.53787005e-005, -9.99999975e-006 def c18, -16.6096401, 0.298911989, 0.586610019, 0.114478 def c19, -1, -0, 2, 1 dcl_texcoord v0.xyz dcl vPos.xy dcl_2d s0 dcl_2d s1 dcl_2d s2 dcl_2d s3 dcl_2d s4 add r0.xy, c0.x, vPos mul r0.xy, r0, c12.zwzw texld r1, r0, s0 mul r2.x, r1.w, c0.y mov r3.y, c0.y mul r2.y, r3.y, c15.x add r0.zw, r2.xyxy, c0.z texld r2, r0.zwzw, s1 add r0.z, -r2.y, c0.x cmp r2, r0.z, c19.x, c19.y texkill r2 texld r2, r1, s2 mad r1.xyw, r2.xyzz, c19.z, c19.x mul r2.xyz, r1.y, c10 mad r2.xyz, r1.x, c9, r2 mad r1.xyw, r1.w, c11.xyzz, r2.xyzz nrm r2.xyz, r1.xyww mul r0.w, r1.z, c0.w exp r0.w, r0.w dp3 r1.x, c14, v0 rcp r1.x, r1.x mul r1.xyz, r1.x, v0 texld r3, r0, s3 dp3 r1.w, r3, c17 add r1.w, r1.w, c3.z rcp r1.w, r1.w mul r1.w, r1.w, c4.z mad r3.xyz, r1.w, r1, c13 mov r21.xyz, r3.xyz mul r22, c175, r21.y mad r22, c174, r21.x, r22 mad r22, c176, r21.z, r22 add r22, r22, c177 texldl r24, c220.z, s13 add r24.y, r22.w, -r24.y mul r24.x, r24.x, r24.y add r22.x, r22.x, -r24.x rcp r22.w, r22.w mul r22.xyz, r22.xyz, r22.w mul r21, c171, r22.y mad r21, c170, r22.x, r21 mad r21, c172, r22.z, r21 add r21, r21, c173 rcp r21.w, r21.w mul r21.xyz, r21.xyz, r21.w // mov r3.xyz, r21.xyz dp3 r1.w, r1, r1 rsq r1.w, r1.w texld r4, r0, s4 mov r5.xyz, c7 mul r4.xyw, r5.xyzz, c16.x add r3.xyz, -r3, c5 dp3 r0.x, r3, r3 rsq r0.x, r0.x rcp r0.y, r0.x mul r2.w, r4.z, c5.w mov r3.w, c19.w mad r3.w, r4.z, -c5.w, r3.w cmp r2.w, r2.w, r3.w, c19.w mul r3.xyz, r0.x, r3 add r0.x, r0.y, -c8.x mul_sat r0.x, r0.x, c8.y add r0.x, -r0.x, c19.w mul r0.x, r0.x, r0.x mul r0.x, r2.w, r0.x mul r4.xyz, r0.x, r4.xyww dp3 r0.x, r2, r3 max r2.w, r0.x, -c19.y mul r5.xyz, r2.w, r4 mad r1.xyz, r1, -r1.w, r3 nrm r3.xyz, r1 dp3 r0.x, r2, r3 add r0.y, r0.x, c17.w log r0.x, r0.x cmp r0.x, r0.y, r0.x, c18.x mul r0.x, r0.x, r0.w exp r0.x, r0.x mul r0.xyw, r0.x, r4.xyzz dp3 r0.x, r0.xyww, c18.yzww exp r1.x, -r5.x exp r1.y, -r5.y exp r1.z, -r5.z exp r1.w, -r0.x cmp oC0, r0.z, -c19.y, r1 // approximately 70 instruction slots used (5 texture, 65 arithmetic) [/code] PS38EA4D18 - Other promising PS for lighting [code]// Dragon area - all shadows // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 // // Parameters: // // float4 CBScreen__packed1; // float4 CBViewProjection__packed4; // sampler2D SSPoint__tDepthMap; // sampler2D SSShadowDepth__tShadowMapCombine; // float4 __tShadowMapCombine__invsize; // row_major float4x4 fProj; // // struct // { // float4 __packed0; // float4 __packed1; // float4 fShadowRange; // row_major float4x4 fShadowProjectNear; // row_major float4x4 fShadowProjectMiddle; // row_major float4x4 fShadowProjectFar; // float4 __packed15; // float4 __packed16; // float4 fShadowMapSize; // row_major float3x4 fShadowRangeMat; // float4 __packed21; // float4 __packed22; // // } sShadowReceiveParam; // // // Registers: // // Name Reg Size // -------------------------------- ----- ---- // sShadowReceiveParam c1 23 // fProj c24 4 // CBScreen__packed1 c28 1 // CBViewProjection__packed4 c29 1 // __tShadowMapCombine__invsize c30 1 // SSPoint__tDepthMap s0 1 // SSShadowDepth__tShadowMapCombine s1 1 // ps_3_0 def c220, 0, 0, 0.0625, 0 dcl_2d s13 def c0, 0.5, 1, 0.00392156886, 1.53787005e-005 def c31, 1, 3, -0.5, -1.5 def c32, 1, 3, -0.5, -2.5 def c33, 0.25, 16.0804024, 8, -5 def c34, -2, 3, 0, 0 def c35, -0.497500002, 0, 1, -1 dcl_texcoord v0.xyz dcl vPos.xy dcl_2d s0 dcl_2d s1 add r0.xy, c0.x, vPos mul r0.xy, r0, c28.zwzw texld r0, r0, s0 dp3 r0.x, r0, c0.yzww add r0.x, r0.x, c26.z rcp r0.x, r0.x mul r0.x, r0.x, c27.z if_lt r0.x, c3.z mad r0.yzw, r0.x, v0.xxyz, c29.xxyz mov r21.xyz, r3.xyz mul r22, c175, r21.y mad r22, c174, r21.x, r22 mad r22, c176, r21.z, r22 add r22, r22, c177 texldl r24, c220.z, s13 add r24.y, r22.w, -r24.y mul r24.x, r24.x, r24.y add r22.x, r22.x, -r24.x rcp r22.w, r22.w mul r22.xyz, r22.xyz, r22.w mul r21, c171, r22.y mad r21, c170, r22.x, r21 mad r21, c172, r22.z, r21 add r21, r21, c173 rcp r21.w, r21.w mul r21.xyz, r21.xyz, r21.w // mov r3.xyz, r21.xyz mul r1.xyz, r0.z, c5 mad r1.xyz, r0.y, c4, r1 mad r1.xyz, r0.w, c6, r1 add r1.xyz, r1, c7 mul r2.xyz, r0.z, c9 mad r2.xyz, r0.y, c8, r2 mad r2.xyz, r0.w, c10, r2 add r2.xyz, r2, c11 mul r3.xyz, r0.z, c13 mad r3.xyz, r0.y, c12, r3 mad r0.yzw, r0.w, c14.xxyz, r3.xxyz add r0.yzw, r0, c15.xxyz mad r3.xy, r1, c31, c31.z mad r3.zw, r2.xyxy, c31.xyxy, c31 mad r4.xy, r0.yzzw, c32, c32.zwzw add r4.zw, r3_abs.xyxy, c35.x cmp r4.zw, r4, c35.y, c35.z mul r1.w, r4.w, r4.z add r4.zw, r3_abs, c35.x cmp r4.zw, r4, c35.y, c35.z mul r2.w, r4.w, r4.z cmp r3.zw, -r2.w, r4_abs.xyxy, r3_abs cmp r3.xy, -r1.w, r3.zwzw, r3_abs cmp r4.xyz, -r2.w, r0.yzww, r2 cmp r4.xyz, -r1.w, r4, r1 cmp r1.xyz, -r1.w, r0.yzww, r2 add r2.xy, r4, -c30 mov r2.zw, c35.y texldl r2, r2, s1 mov r0.yzw, c35 mad r5, c30.xyxy, r0.wywz, r4.xyxy mul r6, r5.xyxx, c35.zzyy texldl r6, r6, s1 mul r5, r5.zwxx, c35.zzyy texldl r5, r5, s1 mad r7, c30.xyxy, r0.ywyz, r4.xyxy mul r8, r7.xyxx, c35.zzyy texldl r8, r8, s1 mov r4.w, c35.y texldl r9, r4.xyww, s1 mul r7, r7.zwxx, c35.zzyy texldl r7, r7, s1 mad r10, c30.xyxy, r0.zwzy, r4.xyxy mul r11, r10.xyxx, c35.zzyy texldl r11, r11, s1 mul r10, r10.zwxx, c35.zzyy texldl r10, r10, s1 add r12.xy, r4, c30 mov r12.zw, c35.y texldl r12, r12, s1 mov r2.y, r6.x mov r2.z, r5.x add r2.xyz, -r2, r4.z cmp r5.xyz, r2, c35.z, c35.y mov r8.y, r9.x mov r8.z, r7.x add r6.xyz, r4.z, -r8 cmp r6.xyz, r6, c35.z, c35.y mov r11.y, r10.x mov r11.z, r12.x add r7.xyz, r4.z, -r11 cmp r7.xyz, r7, c35.z, c35.y mul r3.zw, r4.xyxy, c18.xyxy frc r3.zw, r3 add r4.xyz, r5, r6 cmp r2.xyz, r2, -c35.z, -c35.y add r2.xyz, r2, r7 mad r2.xyz, r2, r3.z, r4 add r2.y, r2.y, r2.x add r2.x, -r2.x, r2.z mad r2.x, r2.x, r3.w, r2.y add r4.xy, r1, -c30 mov r4.zw, c35.y texldl r4, r4, s1 mad r5, c30.xyxy, r0.wywz, r1.xyxy mul r6, r5.xyxx, c35.zzyy texldl r6, r6, s1 mul r5, r5.zwxx, c35.zzyy texldl r5, r5, s1 mad r7, c30.xyxy, r0.ywyz, r1.xyxy mul r8, r7.xyxx, c35.zzyy texldl r8, r8, s1 mov r1.w, c35.y texldl r9, r1.xyww, s1 mul r7, r7.zwxx, c35.zzyy texldl r7, r7, s1 mad r10, c30.xyxy, r0.zwzy, r1.xyxy mul r11, r10.xyxx, c35.zzyy texldl r11, r11, s1 mul r10, r10.zwxx, c35.zzyy texldl r10, r10, s1 add r12.xy, r1, c30 mov r12.zw, c35.y texldl r12, r12, s1 mov r4.y, r6.x mov r4.z, r5.x add r0.yzw, r1.z, -r4.xxyz cmp r2.yzw, r0, c35.z, c35.y mov r8.y, r9.x mov r8.z, r7.x add r4.xyz, r1.z, -r8 cmp r4.xyz, r4, c35.z, c35.y mov r11.y, r10.x mov r11.z, r12.x add r5.xyz, r1.z, -r11 cmp r5.xyz, r5, c35.z, c35.y mul r1.xy, r1, c18 frc r1.xy, r1 add r2.yzw, r2, r4.xxyz cmp r0.yzw, r0, -c35.z, -c35.y add r0.yzw, r0, r5.xxyz mad r0.yzw, r0, r1.x, r2 add r0.z, r0.z, r0.y add r0.y, -r0.y, r0.w mad r0.y, r0.y, r1.y, r0.z mul r0.y, r0.y, c33.x max r0.z, r3.x, r3.y mad_sat r0.z, r0.z, -c33.y, c33.z mad r0.w, r2.x, c33.x, -r0.y mad r0.y, r0.z, r0.w, r0.y else mov r0.y, c35.y endif mov r0.w, c3.w mad r0.z, r0.x, r0.w, -c23.y mad r0.x, r0.x, r0.w, -c0.y mul_sat r0.x, r0.x, c33.w mad r0.w, r0.x, c34.x, c34.y mul r0.x, r0.x, r0.x mul r0.x, r0.x, r0.w cmp r0.x, r0.z, r0.x, c35.y mul oC0, r0.x, r0.y // approximately 161 instruction slots used (37 texture, 124 arithmetic) [/code] Zip file with potential shaders: [url]http://www.mediafire.com/download/5entfl04pthzvnr/DDDA_Shaders.zip[/url]
Ok, so I'll post the code for the most potential candidates. I'll also include a link to a zip with the collection of other shaders that I thought might be relevant.

Vertex Shaders

VS5802BB90 (All lighting in area)
// Environment/ambient light
// "Fixing" breaks lights, creates black patches
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
// Parameters:
//
// float4 CBROPTest__packed0;
// float2 fScreenHalfPixelOffset;
// row_major float4x4 fViewProj;
// row_major float3x4 fWorld;
//
//
// Registers:
//
// Name Reg Size
// ---------------------- ----- ----
// fViewProj c1 4
// fWorld c5 3
// CBROPTest__packed0 c8 1
// fScreenHalfPixelOffset c9 1
//

vs_3_0
def c220, 0, 0, 0.0625, 0
dcl_2d s3
def c0, 1, 0, 0, 0
dcl_position v0
dcl_position o0
dcl_color o1.xy
mad r0, v0.xyzx, c0.xxxy, c0.yyyx
dp4 r1.x, c6, r0
mul r1, r1.x, c2
dp4 r2.x, c5, r0
dp4 r0.x, c7, r0
mad r1, r2.x, c1, r1
mad r0, r0.x, c3, r1
add r0, r0, c4

// texldl r24, c220.z, s3
// add r24.y, r0.w, -r24.y
// mul r24.x, r24.x, r24.y
// mul r24.x, r24.x, c1.x //Tried with and without FOV multiply
// add r0.x, r0.x, -r24.x

mad o0.x, c9.x, -r0.w, r0.x //Tried replacing next 3 lines of code with the code below
mad o0.y, c9.y, r0.w, r0.y
add o0.z, r0.z, c8.z
mov o0.w, r0.w

// mad r10.x, c9.x, -r0.w, r0.x
// mad r10.y, c9.y, r0.w, r0.y
// add r10.z, r0.z, c8.z
// mov r10.w, r0.w
// texldl r24, c220.z, s3
// add r24.y, r10.w, -r24.y
// mul r24.x, r24.x, r24.y
// mul r24.x, r24.x, c1.x //Tried with and without FOV multiply
// add r10.x, r10.x, -r24.x
// mov o0, r10

mov o1.xy, r0.zwzw

// approximately 13 instruction slots used


VS66938957 - All shadows
// Environment light shadowcaster
// Fixing causes shadows to disappear
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
// Parameters:
//
// float4 CBViewProjection__packed4;
// float4 CBViewProjection__packed5;
// float2 fScreenHalfPixelOffset;
// row_major float4x4 fViewProjI;
//
//
// Registers:
//
// Name Reg Size
// ------------------------- ----- ----
// fViewProjI c1 4
// fScreenHalfPixelOffset c5 1
// CBViewProjection__packed4 c6 1
// CBViewProjection__packed5 c7 1
//

vs_3_0
def c220, 0, 0, 0.0625, 0
dcl_2d s3
def c0, 0, 1, 0, 0
dcl_position v0
dcl_position o0
dcl_texcoord o1
mul r0, c2, v0.y
mad r0, v0.x, c1, r0
add r0, r0, c4
rcp r0.w, r0.w
mad r0.xyz, r0, r0.w, -c6
// texldl r24, c220.z, s3
// add r24.y, r0.w, -r24.y
// mul r24.x, r24.x, r24.y
// mul r24.x, r24.x, c1.x
// add r0.x, r0.x, -r24.x
dp3 r0.w, c7, r0

rcp r0.w, r0.w
mul o1.xyz, r0.w, r0



add o0.x, -c5.x, v0.x
add o0.y, c5.y, v0.y
mov o0.zw, c0.xyxy
// add r10.x, -c5.x, v0.x
// add r10.y, c5.y, v0.y
// mov r10.zw, c0.xyxy
// texldl r24, c220.z, s3
// add r24.y, r10.w, -r24.y
// mul r24.x, r24.x, r24.y
// mul r24.x, r24.x, c1.x
// add r10.x, r10.x, -r24.x
// mov o0, r10

mov o1.w, c0.x
//mov o0.xyzw, c220.xxxx

// approximately 12 instruction slots used



VSB1C65FCF - Many shadows created by environment/landscape
// Environment/Landscape shadows
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
// Parameters:
//
// float4 CBShadowCast__packed0;
// float4 CBShadowLight__packed1;
// float2 fScreenHalfPixelOffset;
// row_major float4x4 fViewProj;
// row_major float3x4 fWorld;
//
//
// Registers:
//
// Name Reg Size
// ---------------------- ----- ----
// fViewProj c1 4
// fWorld c5 3
// fScreenHalfPixelOffset c8 1
// CBShadowLight__packed1 c9 1
// CBShadowCast__packed0 c10 1
//

vs_3_0
def c220, 0, 0, 0.0625, 0
dcl_2d s3
def c0, 1, 0, 0, 0
dcl_position v0
dcl_position o0
dcl_color o1.xy
mad r0, v0.xyzx, c0.xxxy, c0.yyyx
dp4 r1.x, c5, r0
dp4 r1.y, c6, r0
dp4 r1.z, c7, r0
mov r0.yzw, c9
mad r0.xyz, r0.yzww, c10.x, r1
mul r1, r0.y, c2
mad r1, r0.x, c1, r1
mad r0, r0.z, c3, r1
add r0, r0, c4

// texldl r24, c220.z, s3
// add r24.y, r0.w, -r24.y
// mul r24.x, r24.x, r24.y
// mul r24.x, r24.x, c1.x
// add r0.x, r0.x, -r24.x

mad o0.x, c8.x, -r0.w, r0.x
mad o0.y, c8.y, r0.w, r0.y
mov o0.zw, r0

// mad r10.x, c8.x, -r0.w, r0.x
// mad r10.y, c8.y, r0.w, r0.y
// mov r10.zw, r0
// texldl r24, c220.z, s3
// add r24.y, r10.w, -r24.y
// mul r24.x, r24.x, r24.y
// mul r24.x, r24.x, c1.x
// add r10.x, r10.x, r24.x

// mov o0, r10
mov o1.xy, r0.zwzw

// approximately 14 instruction slots used


Pixel Shaders

PSC807096D - Lighting in area turns white
// Dragon area - All lighting/shadows go white
// Fixing does nothing
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
// Parameters:
//
// float4 CBLightVolume__packed0;
// float4 CBScreen__packed1;
// float4 CBViewProjection__packed4;
// float4 CBViewProjection__packed5;
// sampler2D SSBorderPoint__tComparisonTexture;
// sampler2D SSBorderPoint__tGBuffer;
// sampler2D SSClampPoint__tSpheremapLutTexture;
// sampler2D SSPoint__tDepthMap;
// sampler2D SSPoint__tLightMaskMap;
// float fLightGroup;
// row_major float4x4 fProj;
// row_major float4x4 fViewI;
//
// struct
// {
// float4 __packed0;
// float4 __packed1;
// float4 __packed2;
// float4 fAttenuation;
// float4 fAttenuation2;
// row_major float3x4 fLightRangeMat;
// row_major float4x4 fLightProjMat;
//
// } sLightParam0;
//
//
// Registers:
//
// Name Reg Size
// ---------------------------------- ----- ----
// fProj c1 4
// sLightParam0 c5 4
// fViewI c9 3
// CBScreen__packed1 c12 1
// CBViewProjection__packed4 c13 1
// CBViewProjection__packed5 c14 1
// fLightGroup c15 1
// CBLightVolume__packed0 c16 1
// SSBorderPoint__tGBuffer s0 1
// SSBorderPoint__tComparisonTexture s1 1
// SSClampPoint__tSpheremapLutTexture s2 1
// SSPoint__tDepthMap s3 1
// SSPoint__tLightMaskMap s4 1
//

ps_3_0
def c220, 0, 0, 0.0625, 0
dcl_2d s13
def c0, 0.5, 0.99609375, 0.001953125, 11.5415602
def c17, 1, 0.00392156886, 1.53787005e-005, -9.99999975e-006
def c18, -16.6096401, 0.298911989, 0.586610019, 0.114478
def c19, -1, -0, 2, 1
dcl_texcoord v0.xyz
dcl vPos.xy
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_2d s3
dcl_2d s4
add r0.xy, c0.x, vPos
mul r0.xy, r0, c12.zwzw
texld r1, r0, s0
mul r2.x, r1.w, c0.y
mov r3.y, c0.y
mul r2.y, r3.y, c15.x
add r0.zw, r2.xyxy, c0.z
texld r2, r0.zwzw, s1
add r0.z, -r2.y, c0.x
cmp r2, r0.z, c19.x, c19.y
texkill r2
texld r2, r1, s2
mad r1.xyw, r2.xyzz, c19.z, c19.x
mul r2.xyz, r1.y, c10
mad r2.xyz, r1.x, c9, r2
mad r1.xyw, r1.w, c11.xyzz, r2.xyzz
nrm r2.xyz, r1.xyww
mul r0.w, r1.z, c0.w
exp r0.w, r0.w
dp3 r1.x, c14, v0
rcp r1.x, r1.x
mul r1.xyz, r1.x, v0
texld r3, r0, s3
dp3 r1.w, r3, c17
add r1.w, r1.w, c3.z
rcp r1.w, r1.w
mul r1.w, r1.w, c4.z
mad r3.xyz, r1.w, r1, c13
mov r21.xyz, r3.xyz
mul r22, c175, r21.y
mad r22, c174, r21.x, r22
mad r22, c176, r21.z, r22
add r22, r22, c177
texldl r24, c220.z, s13
add r24.y, r22.w, -r24.y
mul r24.x, r24.x, r24.y
add r22.x, r22.x, -r24.x
rcp r22.w, r22.w
mul r22.xyz, r22.xyz, r22.w
mul r21, c171, r22.y
mad r21, c170, r22.x, r21
mad r21, c172, r22.z, r21
add r21, r21, c173
rcp r21.w, r21.w
mul r21.xyz, r21.xyz, r21.w
// mov r3.xyz, r21.xyz
dp3 r1.w, r1, r1
rsq r1.w, r1.w
texld r4, r0, s4
mov r5.xyz, c7
mul r4.xyw, r5.xyzz, c16.x
add r3.xyz, -r3, c5
dp3 r0.x, r3, r3
rsq r0.x, r0.x
rcp r0.y, r0.x
mul r2.w, r4.z, c5.w
mov r3.w, c19.w
mad r3.w, r4.z, -c5.w, r3.w
cmp r2.w, r2.w, r3.w, c19.w
mul r3.xyz, r0.x, r3
add r0.x, r0.y, -c8.x
mul_sat r0.x, r0.x, c8.y
add r0.x, -r0.x, c19.w
mul r0.x, r0.x, r0.x
mul r0.x, r2.w, r0.x
mul r4.xyz, r0.x, r4.xyww
dp3 r0.x, r2, r3
max r2.w, r0.x, -c19.y
mul r5.xyz, r2.w, r4
mad r1.xyz, r1, -r1.w, r3
nrm r3.xyz, r1
dp3 r0.x, r2, r3
add r0.y, r0.x, c17.w
log r0.x, r0.x
cmp r0.x, r0.y, r0.x, c18.x
mul r0.x, r0.x, r0.w
exp r0.x, r0.x
mul r0.xyw, r0.x, r4.xyzz
dp3 r0.x, r0.xyww, c18.yzww
exp r1.x, -r5.x
exp r1.y, -r5.y
exp r1.z, -r5.z
exp r1.w, -r0.x
cmp oC0, r0.z, -c19.y, r1

// approximately 70 instruction slots used (5 texture, 65 arithmetic)


PS38EA4D18 - Other promising PS for lighting
// Dragon area - all shadows
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
// Parameters:
//
// float4 CBScreen__packed1;
// float4 CBViewProjection__packed4;
// sampler2D SSPoint__tDepthMap;
// sampler2D SSShadowDepth__tShadowMapCombine;
// float4 __tShadowMapCombine__invsize;
// row_major float4x4 fProj;
//
// struct
// {
// float4 __packed0;
// float4 __packed1;
// float4 fShadowRange;
// row_major float4x4 fShadowProjectNear;
// row_major float4x4 fShadowProjectMiddle;
// row_major float4x4 fShadowProjectFar;
// float4 __packed15;
// float4 __packed16;
// float4 fShadowMapSize;
// row_major float3x4 fShadowRangeMat;
// float4 __packed21;
// float4 __packed22;
//
// } sShadowReceiveParam;
//
//
// Registers:
//
// Name Reg Size
// -------------------------------- ----- ----
// sShadowReceiveParam c1 23
// fProj c24 4
// CBScreen__packed1 c28 1
// CBViewProjection__packed4 c29 1
// __tShadowMapCombine__invsize c30 1
// SSPoint__tDepthMap s0 1
// SSShadowDepth__tShadowMapCombine s1 1
//

ps_3_0
def c220, 0, 0, 0.0625, 0
dcl_2d s13
def c0, 0.5, 1, 0.00392156886, 1.53787005e-005
def c31, 1, 3, -0.5, -1.5
def c32, 1, 3, -0.5, -2.5
def c33, 0.25, 16.0804024, 8, -5
def c34, -2, 3, 0, 0
def c35, -0.497500002, 0, 1, -1
dcl_texcoord v0.xyz
dcl vPos.xy
dcl_2d s0
dcl_2d s1
add r0.xy, c0.x, vPos
mul r0.xy, r0, c28.zwzw
texld r0, r0, s0
dp3 r0.x, r0, c0.yzww
add r0.x, r0.x, c26.z
rcp r0.x, r0.x
mul r0.x, r0.x, c27.z
if_lt r0.x, c3.z
mad r0.yzw, r0.x, v0.xxyz, c29.xxyz
mov r21.xyz, r3.xyz
mul r22, c175, r21.y
mad r22, c174, r21.x, r22
mad r22, c176, r21.z, r22
add r22, r22, c177
texldl r24, c220.z, s13
add r24.y, r22.w, -r24.y
mul r24.x, r24.x, r24.y
add r22.x, r22.x, -r24.x
rcp r22.w, r22.w
mul r22.xyz, r22.xyz, r22.w
mul r21, c171, r22.y
mad r21, c170, r22.x, r21
mad r21, c172, r22.z, r21
add r21, r21, c173
rcp r21.w, r21.w
mul r21.xyz, r21.xyz, r21.w
// mov r3.xyz, r21.xyz
mul r1.xyz, r0.z, c5
mad r1.xyz, r0.y, c4, r1
mad r1.xyz, r0.w, c6, r1
add r1.xyz, r1, c7
mul r2.xyz, r0.z, c9
mad r2.xyz, r0.y, c8, r2
mad r2.xyz, r0.w, c10, r2
add r2.xyz, r2, c11
mul r3.xyz, r0.z, c13
mad r3.xyz, r0.y, c12, r3
mad r0.yzw, r0.w, c14.xxyz, r3.xxyz
add r0.yzw, r0, c15.xxyz
mad r3.xy, r1, c31, c31.z
mad r3.zw, r2.xyxy, c31.xyxy, c31
mad r4.xy, r0.yzzw, c32, c32.zwzw
add r4.zw, r3_abs.xyxy, c35.x
cmp r4.zw, r4, c35.y, c35.z
mul r1.w, r4.w, r4.z
add r4.zw, r3_abs, c35.x
cmp r4.zw, r4, c35.y, c35.z
mul r2.w, r4.w, r4.z
cmp r3.zw, -r2.w, r4_abs.xyxy, r3_abs
cmp r3.xy, -r1.w, r3.zwzw, r3_abs
cmp r4.xyz, -r2.w, r0.yzww, r2
cmp r4.xyz, -r1.w, r4, r1
cmp r1.xyz, -r1.w, r0.yzww, r2
add r2.xy, r4, -c30
mov r2.zw, c35.y
texldl r2, r2, s1
mov r0.yzw, c35
mad r5, c30.xyxy, r0.wywz, r4.xyxy
mul r6, r5.xyxx, c35.zzyy
texldl r6, r6, s1
mul r5, r5.zwxx, c35.zzyy
texldl r5, r5, s1
mad r7, c30.xyxy, r0.ywyz, r4.xyxy
mul r8, r7.xyxx, c35.zzyy
texldl r8, r8, s1
mov r4.w, c35.y
texldl r9, r4.xyww, s1
mul r7, r7.zwxx, c35.zzyy
texldl r7, r7, s1
mad r10, c30.xyxy, r0.zwzy, r4.xyxy
mul r11, r10.xyxx, c35.zzyy
texldl r11, r11, s1
mul r10, r10.zwxx, c35.zzyy
texldl r10, r10, s1
add r12.xy, r4, c30
mov r12.zw, c35.y
texldl r12, r12, s1
mov r2.y, r6.x
mov r2.z, r5.x
add r2.xyz, -r2, r4.z
cmp r5.xyz, r2, c35.z, c35.y
mov r8.y, r9.x
mov r8.z, r7.x
add r6.xyz, r4.z, -r8
cmp r6.xyz, r6, c35.z, c35.y
mov r11.y, r10.x
mov r11.z, r12.x
add r7.xyz, r4.z, -r11
cmp r7.xyz, r7, c35.z, c35.y
mul r3.zw, r4.xyxy, c18.xyxy
frc r3.zw, r3
add r4.xyz, r5, r6
cmp r2.xyz, r2, -c35.z, -c35.y
add r2.xyz, r2, r7
mad r2.xyz, r2, r3.z, r4
add r2.y, r2.y, r2.x
add r2.x, -r2.x, r2.z
mad r2.x, r2.x, r3.w, r2.y
add r4.xy, r1, -c30
mov r4.zw, c35.y
texldl r4, r4, s1
mad r5, c30.xyxy, r0.wywz, r1.xyxy
mul r6, r5.xyxx, c35.zzyy
texldl r6, r6, s1
mul r5, r5.zwxx, c35.zzyy
texldl r5, r5, s1
mad r7, c30.xyxy, r0.ywyz, r1.xyxy
mul r8, r7.xyxx, c35.zzyy
texldl r8, r8, s1
mov r1.w, c35.y
texldl r9, r1.xyww, s1
mul r7, r7.zwxx, c35.zzyy
texldl r7, r7, s1
mad r10, c30.xyxy, r0.zwzy, r1.xyxy
mul r11, r10.xyxx, c35.zzyy
texldl r11, r11, s1
mul r10, r10.zwxx, c35.zzyy
texldl r10, r10, s1
add r12.xy, r1, c30
mov r12.zw, c35.y
texldl r12, r12, s1
mov r4.y, r6.x
mov r4.z, r5.x
add r0.yzw, r1.z, -r4.xxyz
cmp r2.yzw, r0, c35.z, c35.y
mov r8.y, r9.x
mov r8.z, r7.x
add r4.xyz, r1.z, -r8
cmp r4.xyz, r4, c35.z, c35.y
mov r11.y, r10.x
mov r11.z, r12.x
add r5.xyz, r1.z, -r11
cmp r5.xyz, r5, c35.z, c35.y
mul r1.xy, r1, c18
frc r1.xy, r1
add r2.yzw, r2, r4.xxyz
cmp r0.yzw, r0, -c35.z, -c35.y
add r0.yzw, r0, r5.xxyz
mad r0.yzw, r0, r1.x, r2
add r0.z, r0.z, r0.y
add r0.y, -r0.y, r0.w
mad r0.y, r0.y, r1.y, r0.z
mul r0.y, r0.y, c33.x
max r0.z, r3.x, r3.y
mad_sat r0.z, r0.z, -c33.y, c33.z
mad r0.w, r2.x, c33.x, -r0.y
mad r0.y, r0.z, r0.w, r0.y
else
mov r0.y, c35.y
endif
mov r0.w, c3.w
mad r0.z, r0.x, r0.w, -c23.y
mad r0.x, r0.x, r0.w, -c0.y
mul_sat r0.x, r0.x, c33.w
mad r0.w, r0.x, c34.x, c34.y
mul r0.x, r0.x, r0.x
mul r0.x, r0.x, r0.w
cmp r0.x, r0.z, r0.x, c35.y
mul oC0, r0.x, r0.y

// approximately 161 instruction slots used (37 texture, 124 arithmetic)



Zip file with potential shaders: http://www.mediafire.com/download/5entfl04pthzvnr/DDDA_Shaders.zip

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 01/26/2016 02:53 AM   
I haven't looked at this in detail yet [quote="DJ-RK"]What was actually required was for me to also find the VS for the shadow itself (shadowcaster, I think they're called?) and perform the stereo fix on the output position there, and bingo! Player shadows were fixed. I then had to locate other shadowcaster VS's for each different type of object in the game that creates shadows and perform individual fixes. Don't know if this all was right (because that certainly wasn't required in Mike's RE6 fix), but it worked![/quote] That's a concern. Assuming those were indeed shadow casters (they sound like it from your description) you should not need to adjust them. Did you add or subtract the correction formula in them? What might be happening is the shadow map render targets are being stereoised by the driver - if that is the case they will need to be forced to mono. It's worth trying to force all square render targets to mono with: [code] DefSquareSurfaceMode = 2 [/code] Or you can use trial and error (a binary search works reasonably well, so long as you keep in mind that there is often multiple render targets to find) to try forcing each of the render targets (except ones that obviously going to need to be left alone, like the ones that match the screen resolution) to mono. This game uses both D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL (Add [SF] sections, list sections in SurfaceCreationModeList) and CreateDepthStencilSurface (Add [DS] sections, list sections in DepthStencilSurfaceModeList). Edit: Based on my observations hunting down the cloth glitch, I'd bet this is your shadow render target (being square and using format 114 is a bit of a giveaway as that's one of the single channel formats): D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
I haven't looked at this in detail yet

DJ-RK said:What was actually required was for me to also find the VS for the shadow itself (shadowcaster, I think they're called?) and perform the stereo fix on the output position there, and bingo! Player shadows were fixed. I then had to locate other shadowcaster VS's for each different type of object in the game that creates shadows and perform individual fixes. Don't know if this all was right (because that certainly wasn't required in Mike's RE6 fix), but it worked!

That's a concern. Assuming those were indeed shadow casters (they sound like it from your description) you should not need to adjust them. Did you add or subtract the correction formula in them?

What might be happening is the shadow map render targets are being stereoised by the driver - if that is the case they will need to be forced to mono. It's worth trying to force all square render targets to mono with:
DefSquareSurfaceMode = 2


Or you can use trial and error (a binary search works reasonably well, so long as you keep in mind that there is often multiple render targets to find) to try forcing each of the render targets (except ones that obviously going to need to be left alone, like the ones that match the screen resolution) to mono. This game uses both D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL (Add [SF] sections, list sections in SurfaceCreationModeList) and CreateDepthStencilSurface (Add [DS] sections, list sections in DepthStencilSurfaceModeList).

Edit: Based on my observations hunting down the cloth glitch, I'd bet this is your shadow render target (being square and using format 114 is a bit of a giveaway as that's one of the single channel formats):
D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0

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 01/26/2016 07:07 AM   
I'm not seeing any shadows from the fire or directional shadows - I take it you disabled them, but the only disabled shader I see is 66938957 and that didn't seem to bring them back. Did I miss one?
I'm not seeing any shadows from the fire or directional shadows - I take it you disabled them, but the only disabled shader I see is 66938957 and that didn't seem to bring them back. Did I miss one?

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 01/26/2016 08:47 AM   
Yeah, if you're using my full fix then besides 66938957, make sure VS B1C65FCF and PS 38EA4D18 are reverted back to normal. The stereo correction on those make the shadows disappear.
Yeah, if you're using my full fix then besides 66938957, make sure VS B1C65FCF and PS 38EA4D18 are reverted back to normal. The stereo correction on those make the shadows disappear.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 01/26/2016 09:05 AM   
[quote="DarkStarSword"]I haven't looked at this in detail yet That's a concern. Assuming those were indeed shadow casters (they sound like it from your description) you should not need to adjust them. Did you add or subtract the correction formula in them?[/quote] Subtract. VS E0A84044 is the one that I fixed if you need to take a look. [quote]What might be happening is the shadow map render targets are being stereoised by the driver - if that is the case they will need to be forced to mono. It's worth trying to force all square render targets to mono with: [code] DefSquareSurfaceMode = 2 [/code][/quote] That didn't change anything. Based on your target, should I also try: DefDepthStencilSurfaceMode = 2? [quote]Or you can use trial and error (a binary search works reasonably well, so long as you keep in mind that there is often multiple render targets to find) to try forcing each of the render targets (except ones that obviously going to need to be left alone, like the ones that match the screen resolution) to mono. This game uses both D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL (Add [SF] sections, list sections in SurfaceCreationModeList) and CreateDepthStencilSurface (Add [DS] sections, list sections in DepthStencilSurfaceModeList). Edit: Based on my observations hunting down the cloth glitch, I'd bet this is your shadow render target (being square and using format 114 is a bit of a giveaway as that's one of the single channel formats): D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 [/quote] Ok, so this part is all new to me. Mike's RE6 fix had SurfaceCreationModeList and a section in the .ini labelled water where he created 3 surfaces, but I hadn't brought that over into my DDDA ini since I wasn't sure what it was for and how it worked. So based on your suggestion, am I creating a SF and DS that both match? Would it look like this: [code][General] ... SurfaceCreationModeList = 0; CreateDepthStencilSurface = 0; [SF0] ;D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 DefMode = 2 Format = 114 Usage = 1 Height = 256 Width = 256 Pool = 0 Levels = 1 [DS0] ;D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 DefMode = 2 Format = 114 Usage = 1 Height = 256 Width = 256 Pool = 0 Levels = 1 [/code] I noticed in the DDDA thread you didn't include the 'texptr 0 nIndex 0, Mode 0' in your code in the SF section you suggested there, so I didn't include those here, is that correct? If it's not too much bother to explain, how did you hunt and get those values from? Edit: I tried the above as well now, and that didn't change anything either
DarkStarSword said:I haven't looked at this in detail yet

That's a concern. Assuming those were indeed shadow casters (they sound like it from your description) you should not need to adjust them. Did you add or subtract the correction formula in them?


Subtract. VS E0A84044 is the one that I fixed if you need to take a look.

What might be happening is the shadow map render targets are being stereoised by the driver - if that is the case they will need to be forced to mono. It's worth trying to force all square render targets to mono with:
DefSquareSurfaceMode = 2


That didn't change anything. Based on your target, should I also try: DefDepthStencilSurfaceMode = 2?

Or you can use trial and error (a binary search works reasonably well, so long as you keep in mind that there is often multiple render targets to find) to try forcing each of the render targets (except ones that obviously going to need to be left alone, like the ones that match the screen resolution) to mono. This game uses both D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL (Add [SF] sections, list sections in SurfaceCreationModeList) and CreateDepthStencilSurface (Add [DS] sections, list sections in DepthStencilSurfaceModeList).

Edit: Based on my observations hunting down the cloth glitch, I'd bet this is your shadow render target (being square and using format 114 is a bit of a giveaway as that's one of the single channel formats):
D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0


Ok, so this part is all new to me. Mike's RE6 fix had SurfaceCreationModeList and a section in the .ini labelled water where he created 3 surfaces, but I hadn't brought that over into my DDDA ini since I wasn't sure what it was for and how it worked.

So based on your suggestion, am I creating a SF and DS that both match? Would it look like this:

[General]
...
SurfaceCreationModeList = 0;
CreateDepthStencilSurface = 0;

[SF0]
;D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
DefMode = 2
Format = 114
Usage = 1
Height = 256
Width = 256
Pool = 0
Levels = 1

[DS0]
;D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
DefMode = 2
Format = 114
Usage = 1
Height = 256
Width = 256
Pool = 0
Levels = 1


I noticed in the DDDA thread you didn't include the 'texptr 0 nIndex 0, Mode 0' in your code in the SF section you suggested there, so I didn't include those here, is that correct?

If it's not too much bother to explain, how did you hunt and get those values from?


Edit: I tried the above as well now, and that didn't change anything either

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 01/26/2016 09:35 AM   
[quote="DJ-RK"][quote="DarkStarSword"]That's a concern. Assuming those were indeed shadow casters (they sound like it from your description) you should not need to adjust them. Did you add or subtract the correction formula in them?[/quote] Subtract. VS E0A84044 is the one that I fixed if you need to take a look.[/quote]Ok. Subtracting would make sense if they are shadow casters that are being stereoised when they should not be, as that would move their position on the shadow map back to the original (and correct) mono position. But the best thing to do will be to force the shadow map(s) to mono instead. [quote][quote]What might be happening is the shadow map render targets are being stereoised by the driver - if that is the case they will need to be forced to mono. It's worth trying to force all square render targets to mono with: [code] DefSquareSurfaceMode = 2 [/code][/quote] That didn't change anything.[/quote]ok, good to know. It might be that the game is using a mix of square and rectangular shadow maps, which would certainly play havoc with the driver heuristics. [quote]Based on your target, should I also try: DefDepthStencilSurfaceMode = 2?[/quote]That's a good thought, but it would very likely break the main depth buffer making most of the game look weird. If you were to use that, you would then need to identify which depth/stencil buffers need to be forced back to stereo. [quote] [quote]Or you can use trial and error (a binary search works reasonably well, so long as you keep in mind that there is often multiple render targets to find) to try forcing each of the render targets (except ones that obviously going to need to be left alone, like the ones that match the screen resolution) to mono. This game uses both D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL (Add [SF] sections, list sections in SurfaceCreationModeList) and CreateDepthStencilSurface (Add [DS] sections, list sections in DepthStencilSurfaceModeList). Edit: Based on my observations hunting down the cloth glitch, I'd bet this is your shadow render target (being square and using format 114 is a bit of a giveaway as that's one of the single channel formats): D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 [/quote] Ok, so this part is all new to me.[/quote]There's a bit of info on the Helix Mod features page you might want to read through for these, but I'll go through some of it here. [quote] Mike's RE6 fix had SurfaceCreationModeList and a section in the .ini labelled water where he created 3 surfaces, but I hadn't brought that over into my DDDA ini since I wasn't sure what it was for and how it worked.[/quote]I noticed that as well, and also noticed it was labelled water. They are all Format=21 (which you can check on MSDN is D3DFMT_A8R8G8B8), so they are all colour render targets and unlikely to be related to the shadows. They are more likely for reflections. [quote]So based on your suggestion, am I creating a SF and DS that both match? Would it look like this:[/quote]The SF0 is along the right lines, but if DefSquareSurfaceMode=2 didn't work than it's probably safe to assume that's the wrong one (it might well be a shadow map, but perhaps it was mono to begin with). To find the possible sections, play far enough to see the suspect effect then check the LOG.txt and search for lines containing: D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL - the most common, use [SF] sections and list in SurfaceCreationModeList CreateDepthStencilSurface - use [DS] sections and list in DepthStencilSurfaceModeList CreateRenderTarget - use [RT] sections and list in RTCreationModeList It depends on how the game created the surfaces as to which ones you will see. [quote]I noticed in the DDDA thread you didn't include the 'texptr 0 nIndex 0, Mode 0' in your code in the SF section you suggested there, so I didn't include those here, is that correct?[/quote] Right, you don't include those parts - texptr and nIndex are ways to distinguish between otherwise identical render targets in the log (I believe you can match on index, but only if you are certain that the render targets are always going to be created in the same order). Mode is the stereo mode of the surface, but unless you have already added something to the ini file to force it it will just be 0 (automatic). In the ini file you use DefMode= to force the stereo mode (0=auto, 1=stereo, 2=mono). [quote]If it's not too much bother to explain, how did you hunt and get those values from?[/quote] Since I've already done this part I might as well post it to save you some time - I grabbed the unique lines from the log with 'grep RENDERTARGET LOG.txt | sort -u' (actually I used | sort | uniq -c | sort -n to get counts of each, but that didn't really tell me anything so was a bit pointless) then used a vim macro to turn them into sections. This was grabbed right at the start of the game (before even equipping the lantern), so you would want to check the LOG.txt for any new render targets that appear once you see the broken shadows: Note: SF0 is not the same as SF0 I posted on the DD thread, which is [SF22] and [SF26] here - I renumbered them to remove all the ones I didn't need: [code] [SF0] ; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1 Width 1024 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=1 Width=1024 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF1] ; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1 Width 256 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=1 Width=256 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF2] ; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 128 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=128 Width=128 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF3] ; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1536 Width 512 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=1536 Width=512 Usage=1 Format=114 Pool=0 Levels=1 DefMode=2 [SF4] ; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 21 Pool 0 Levels 9 texptr 0 nIndex 0, Mode 0 Height=256 Width=256 Usage=1 Format=21 Pool=0 Levels=9 DefMode=2 [SF5] ; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 384 Width 384 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=384 Width=384 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF6] ; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 64 Width 64 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=64 Width=64 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF7] ; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 720 Width 1280 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=720 Width=1280 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF8] ; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1 Width 128 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=1 Width=128 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF9] ; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 128 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=128 Width=128 Usage=1 Format=114 Pool=0 Levels=1 DefMode=2 [SF10] ; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 192 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=128 Width=192 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF11] ; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=256 Width=256 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF12] ; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 33 Width 60 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=33 Width=60 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF13] ; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 360 Width 640 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=360 Width=640 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF14] ; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 67 Width 120 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=67 Width=120 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF15] ; 4 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 384 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=256 Width=384 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF16] ; 4 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 270 Width 480 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=270 Width=480 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF17] ; 5 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 135 Width 240 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=135 Width=240 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF18] ; 5 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 540 Width 960 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=540 Width=960 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF19] ; 6 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 128 Usage 1 Format 34 Pool 0 Levels 5 texptr 0 nIndex 0, Mode 0 Height=128 Width=128 Usage=1 Format=34 Pool=0 Levels=5 DefMode=2 [SF20] ; 6 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 192 Usage 1 Format 34 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=128 Width=192 Usage=1 Format=34 Pool=0 Levels=1 DefMode=2 [SF21] ; 7 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 32 Width 32 Usage 1 Format 113 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=32 Width=32 Usage=1 Format=113 Pool=0 Levels=1 DefMode=2 [SF22] ; 8 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 16 Width 64 Usage 1 Format 116 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=16 Width=64 Usage=1 Format=116 Pool=0 Levels=1 DefMode=2 [SF23] ; 10 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 128 Usage 1 Format 34 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=128 Width=128 Usage=1 Format=34 Pool=0 Levels=1 DefMode=2 [SF24] ; 12 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1080 Width 1920 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=1080 Width=1920 Usage=1 Format=21 Pool=0 Levels=1 DefMode=2 [SF25] ; 16 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 384 Usage 1 Format 34 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=256 Width=384 Usage=1 Format=34 Pool=0 Levels=1 DefMode=2 [SF26] ; 48 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 8 Width 64 Usage 1 Format 116 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=8 Width=64 Usage=1 Format=116 Pool=0 Levels=1 DefMode=2 [SF27] ; 268 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 Height=256 Width=256 Usage=1 Format=114 Pool=0 Levels=1 DefMode=2 [/code] I did not grab the DS sections since I was fairly certain the glitch I was looking for wouldn't be one, though for shadows it may well be, so you should compile a similar list for them. I then use SurfaceCreationModeList to enable/disable each section in a sort of binary search to narrow down the right one. Notably, when I used this line to force almost all of them to mono the game still seemed to render fine, so you might start with it: [code] SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;25;26;27; [/code] These comments might also help show my process for narrowing down the right sections: [code] ; --- Forcing to mono --- ; Fixed cloth (all but 24 which is 1920x1080): ;SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;25;26;27; ; Broken: ;SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13; ; Fixed: ;SurfaceCreationModeList=14;15;16;17;18;19;20;21;22;23;25;26;27; ; Broken: ;SurfaceCreationModeList=14;15;16;17;18;19;20; ; ; Not tested, *should* be fixed: ;SurfaceCreationModeList=21;22;23;25;26;27; ; Broken: ;SurfaceCreationModeList=21;22;23; ; ; Not tested, *should* be fixed: ;SurfaceCreationModeList=25;26;27; ;Broken: ;SurfaceCreationModeList=25;26; ;Broken: ;SurfaceCreationModeList=27; ; ; Bugger, must be two of them... go back and confirm assumptions ; ; Fixed: ;SurfaceCreationModeList=21;22;23;25;26;27; ; ; Both combinations broken, so it's at least one from both sets: ; SurfaceCreationModeList=21;22;23; ; SurfaceCreationModeList=25;26;27; ; Fixed: ;SurfaceCreationModeList=22;23;25;26;27; ; Broken, confirms that 22 is part of the fix: ;SurfaceCreationModeList=23;25;26;27; ; At a haunch, try 26 based on the same format as 22: ;SurfaceCreationModeList=22;26; ; Fixed :) [/code] I had also tried forcing them to stereo as well (DefMode=1 instead of 2), but progress was somewhat hindered by out of memory errors caused by stereoising 256x256 format=12 render targets that I had to track down first (I've seen that happen in Life Is Strange as well, which prevented me trying to stereoise some of the reflections). This isn't quite a binary search because I was going on haunches, which turned out to be wrong: [code] ; --- Forcing to stereo --- ;Out of Memory error, shadows on main menu broken: ;SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27; ;Out of memory error, Shadows on main menu ok: ;SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23; ; Still getting out of memory: ;SurfaceCreationModeList=0;1;2;3;4;5;6;7; ; No out of memory, glitch still occurs: ;SurfaceCreationModeList=0; ; Out of memory damnit! ;SurfaceCreationModeList=2;4;5;6; ; Out of memory: ;SurfaceCreationModeList=2;4; ; No out of memory, glitch still occurs: ;SurfaceCreationModeList=5;6; ;SurfaceCreationModeList=0;1;2;3;5;6;7; ; No out of memory, glitch still occurs: ;SurfaceCreationModeList=0;1;2;3;5;6;7;8;9;10;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27; ; Confirmed not to produce out of memory: ; 0;1;2;3;5;6;7;8;9;10;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27; ; 268 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 ; Confirmed to produce out of memory: ; 4;11; ; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 21 Pool 0 Levels 9 texptr 0 nIndex 0, Mode 0 ; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0 ; Haunch - all 256x256 textures: 4;11;27; ; no, not 27 - so all 256x256 format=21 textures ; Confirmed not to fix glitch when forcing to stereo: ; 0;1;2;3;5;6;7;8;9;10;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27; [/code]
DJ-RK said:
DarkStarSword said:That's a concern. Assuming those were indeed shadow casters (they sound like it from your description) you should not need to adjust them. Did you add or subtract the correction formula in them?


Subtract. VS E0A84044 is the one that I fixed if you need to take a look.
Ok. Subtracting would make sense if they are shadow casters that are being stereoised when they should not be, as that would move their position on the shadow map back to the original (and correct) mono position. But the best thing to do will be to force the shadow map(s) to mono instead.

What might be happening is the shadow map render targets are being stereoised by the driver - if that is the case they will need to be forced to mono. It's worth trying to force all square render targets to mono with:
DefSquareSurfaceMode = 2


That didn't change anything.
ok, good to know. It might be that the game is using a mix of square and rectangular shadow maps, which would certainly play havoc with the driver heuristics.

Based on your target, should I also try: DefDepthStencilSurfaceMode = 2?
That's a good thought, but it would very likely break the main depth buffer making most of the game look weird. If you were to use that, you would then need to identify which depth/stencil buffers need to be forced back to stereo.


Or you can use trial and error (a binary search works reasonably well, so long as you keep in mind that there is often multiple render targets to find) to try forcing each of the render targets (except ones that obviously going to need to be left alone, like the ones that match the screen resolution) to mono. This game uses both D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL (Add [SF] sections, list sections in SurfaceCreationModeList) and CreateDepthStencilSurface (Add [DS] sections, list sections in DepthStencilSurfaceModeList).

Edit: Based on my observations hunting down the cloth glitch, I'd bet this is your shadow render target (being square and using format 114 is a bit of a giveaway as that's one of the single channel formats):
D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0


Ok, so this part is all new to me.
There's a bit of info on the Helix Mod features page you might want to read through for these, but I'll go through some of it here.

Mike's RE6 fix had SurfaceCreationModeList and a section in the .ini labelled water where he created 3 surfaces, but I hadn't brought that over into my DDDA ini since I wasn't sure what it was for and how it worked.
I noticed that as well, and also noticed it was labelled water. They are all Format=21 (which you can check on MSDN is D3DFMT_A8R8G8B8), so they are all colour render targets and unlikely to be related to the shadows. They are more likely for reflections.

So based on your suggestion, am I creating a SF and DS that both match? Would it look like this:
The SF0 is along the right lines, but if DefSquareSurfaceMode=2 didn't work than it's probably safe to assume that's the wrong one (it might well be a shadow map, but perhaps it was mono to begin with). To find the possible sections, play far enough to see the suspect effect then check the LOG.txt and search for lines containing:

D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL - the most common, use [SF] sections and list in SurfaceCreationModeList
CreateDepthStencilSurface - use [DS] sections and list in DepthStencilSurfaceModeList
CreateRenderTarget - use [RT] sections and list in RTCreationModeList

It depends on how the game created the surfaces as to which ones you will see.

I noticed in the DDDA thread you didn't include the 'texptr 0 nIndex 0, Mode 0' in your code in the SF section you suggested there, so I didn't include those here, is that correct?

Right, you don't include those parts - texptr and nIndex are ways to distinguish between otherwise identical render targets in the log (I believe you can match on index, but only if you are certain that the render targets are always going to be created in the same order). Mode is the stereo mode of the surface, but unless you have already added something to the ini file to force it it will just be 0 (automatic). In the ini file you use DefMode= to force the stereo mode (0=auto, 1=stereo, 2=mono).

If it's not too much bother to explain, how did you hunt and get those values from?

Since I've already done this part I might as well post it to save you some time - I grabbed the unique lines from the log with 'grep RENDERTARGET LOG.txt | sort -u' (actually I used | sort | uniq -c | sort -n to get counts of each, but that didn't really tell me anything so was a bit pointless) then used a vim macro to turn them into sections. This was grabbed right at the start of the game (before even equipping the lantern), so you would want to check the LOG.txt for any new render targets that appear once you see the broken shadows:

Note: SF0 is not the same as SF0 I posted on the DD thread, which is [SF22] and [SF26] here - I renumbered them to remove all the ones I didn't need:
[SF0]
; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1 Width 1024 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=1
Width=1024
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF1]
; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1 Width 256 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=1
Width=256
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF2]
; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 128 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=128
Width=128
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF3]
; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1536 Width 512 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=1536
Width=512
Usage=1
Format=114
Pool=0
Levels=1
DefMode=2

[SF4]
; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 21 Pool 0 Levels 9 texptr 0 nIndex 0, Mode 0
Height=256
Width=256
Usage=1
Format=21
Pool=0
Levels=9
DefMode=2

[SF5]
; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 384 Width 384 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=384
Width=384
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF6]
; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 64 Width 64 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=64
Width=64
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF7]
; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 720 Width 1280 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=720
Width=1280
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF8]
; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1 Width 128 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=1
Width=128
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF9]
; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 128 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=128
Width=128
Usage=1
Format=114
Pool=0
Levels=1
DefMode=2

[SF10]
; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 192 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=128
Width=192
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF11]
; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=256
Width=256
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF12]
; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 33 Width 60 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=33
Width=60
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF13]
; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 360 Width 640 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=360
Width=640
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF14]
; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 67 Width 120 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=67
Width=120
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF15]
; 4 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 384 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=256
Width=384
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF16]
; 4 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 270 Width 480 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=270
Width=480
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF17]
; 5 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 135 Width 240 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=135
Width=240
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF18]
; 5 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 540 Width 960 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=540
Width=960
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF19]
; 6 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 128 Usage 1 Format 34 Pool 0 Levels 5 texptr 0 nIndex 0, Mode 0
Height=128
Width=128
Usage=1
Format=34
Pool=0
Levels=5
DefMode=2

[SF20]
; 6 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 192 Usage 1 Format 34 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=128
Width=192
Usage=1
Format=34
Pool=0
Levels=1
DefMode=2

[SF21]
; 7 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 32 Width 32 Usage 1 Format 113 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=32
Width=32
Usage=1
Format=113
Pool=0
Levels=1
DefMode=2

[SF22]
; 8 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 16 Width 64 Usage 1 Format 116 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=16
Width=64
Usage=1
Format=116
Pool=0
Levels=1
DefMode=2

[SF23]
; 10 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 128 Width 128 Usage 1 Format 34 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=128
Width=128
Usage=1
Format=34
Pool=0
Levels=1
DefMode=2

[SF24]
; 12 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 1080 Width 1920 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=1080
Width=1920
Usage=1
Format=21
Pool=0
Levels=1
DefMode=2

[SF25]
; 16 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 384 Usage 1 Format 34 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=256
Width=384
Usage=1
Format=34
Pool=0
Levels=1
DefMode=2

[SF26]
; 48 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 8 Width 64 Usage 1 Format 116 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=8
Width=64
Usage=1
Format=116
Pool=0
Levels=1
DefMode=2

[SF27]
; 268 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
Height=256
Width=256
Usage=1
Format=114
Pool=0
Levels=1
DefMode=2


I did not grab the DS sections since I was fairly certain the glitch I was looking for wouldn't be one, though for shadows it may well be, so you should compile a similar list for them.

I then use SurfaceCreationModeList to enable/disable each section in a sort of binary search to narrow down the right one.

Notably, when I used this line to force almost all of them to mono the game still seemed to render fine, so you might start with it:
SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;25;26;27;


These comments might also help show my process for narrowing down the right sections:
; --- Forcing to mono ---
; Fixed cloth (all but 24 which is 1920x1080):
;SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;25;26;27;
; Broken:
;SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13;
; Fixed:
;SurfaceCreationModeList=14;15;16;17;18;19;20;21;22;23;25;26;27;
; Broken:
;SurfaceCreationModeList=14;15;16;17;18;19;20;
;
; Not tested, *should* be fixed:
;SurfaceCreationModeList=21;22;23;25;26;27;
; Broken:
;SurfaceCreationModeList=21;22;23;
;
; Not tested, *should* be fixed:
;SurfaceCreationModeList=25;26;27;
;Broken:
;SurfaceCreationModeList=25;26;
;Broken:
;SurfaceCreationModeList=27;
;
; Bugger, must be two of them... go back and confirm assumptions
;
; Fixed:
;SurfaceCreationModeList=21;22;23;25;26;27;
;
; Both combinations broken, so it's at least one from both sets:
; SurfaceCreationModeList=21;22;23;
; SurfaceCreationModeList=25;26;27;
; Fixed:
;SurfaceCreationModeList=22;23;25;26;27;
; Broken, confirms that 22 is part of the fix:
;SurfaceCreationModeList=23;25;26;27;
; At a haunch, try 26 based on the same format as 22:
;SurfaceCreationModeList=22;26;
; Fixed :)


I had also tried forcing them to stereo as well (DefMode=1 instead of 2), but progress was somewhat hindered by out of memory errors caused by stereoising 256x256 format=12 render targets that I had to track down first (I've seen that happen in Life Is Strange as well, which prevented me trying to stereoise some of the reflections). This isn't quite a binary search because I was going on haunches, which turned out to be wrong:
; --- Forcing to stereo ---
;Out of Memory error, shadows on main menu broken:
;SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27;
;Out of memory error, Shadows on main menu ok:
;SurfaceCreationModeList=0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;
; Still getting out of memory:
;SurfaceCreationModeList=0;1;2;3;4;5;6;7;
; No out of memory, glitch still occurs:
;SurfaceCreationModeList=0;
; Out of memory damnit!
;SurfaceCreationModeList=2;4;5;6;
; Out of memory:
;SurfaceCreationModeList=2;4;
; No out of memory, glitch still occurs:
;SurfaceCreationModeList=5;6;
;SurfaceCreationModeList=0;1;2;3;5;6;7;
; No out of memory, glitch still occurs:
;SurfaceCreationModeList=0;1;2;3;5;6;7;8;9;10;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27;

; Confirmed not to produce out of memory:
; 0;1;2;3;5;6;7;8;9;10;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27;
; 268 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 114 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0

; Confirmed to produce out of memory:
; 4;11;
; 1 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 21 Pool 0 Levels 9 texptr 0 nIndex 0, Mode 0
; 2 D3DUSAGE_RENDERTARGET/D3DUSAGE_DEPTHSTENCIL Height 256 Width 256 Usage 1 Format 21 Pool 0 Levels 1 texptr 0 nIndex 0, Mode 0
; Haunch - all 256x256 textures: 4;11;27;
; no, not 27 - so all 256x256 format=21 textures

; Confirmed not to fix glitch when forcing to stereo:
; 0;1;2;3;5;6;7;8;9;10;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27;

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 01/26/2016 10:46 AM   
Alright! I was able to follow your instruction and worked out that creating the below surface got shadows from my lantern to be able to be fixed properly without needing to adjust the shadowcasters. Great lesson, should definitely be useful going forward! [code][SF0] ;Shadowmap for lantern shadows Height=2048 Width=3072 Usage=1 Format=34 Pool=0 Levels=1 DefMode=2[/code] So now, does this work out that format 34 equates to shadows, so if I need to create any additional surfaces related to shadows, would I be able to more easily identify them in the logs by them having the same format #? Or, based on your comments in the DDDA thread, could I simply remove the height and width values, and have this apply to all render targets with this format, which may hopefully preemptively set shadows to be rendered in mono? So that's great about all that being sorted out, however that doesn't seem to improve the matter of the environmental lighting/shadows. I didn't bother to try to play around with modifying any of those shaders now that I've made the above adjustment, but at glancing at the broken effects, they don't look any different than before, so I have my doubts that they've been affected by this... yet.
Alright! I was able to follow your instruction and worked out that creating the below surface got shadows from my lantern to be able to be fixed properly without needing to adjust the shadowcasters. Great lesson, should definitely be useful going forward!

[SF0]
;Shadowmap for lantern shadows
Height=2048
Width=3072
Usage=1
Format=34
Pool=0
Levels=1
DefMode=2


So now, does this work out that format 34 equates to shadows, so if I need to create any additional surfaces related to shadows, would I be able to more easily identify them in the logs by them having the same format #? Or, based on your comments in the DDDA thread, could I simply remove the height and width values, and have this apply to all render targets with this format, which may hopefully preemptively set shadows to be rendered in mono?

So that's great about all that being sorted out, however that doesn't seem to improve the matter of the environmental lighting/shadows. I didn't bother to try to play around with modifying any of those shaders now that I've made the above adjustment, but at glancing at the broken effects, they don't look any different than before, so I have my doubts that they've been affected by this... yet.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 01/26/2016 02:57 PM   
[quote="DJ-RK"]Alright! I was able to follow your instruction and worked out that creating the below surface got shadows from my lantern to be able to be fixed properly without needing to adjust the shadowcasters. Great lesson, should definitely be useful going forward![/quote]Great :) [quote]So now, does this work out that format 34 equates to shadows, so if I need to create any additional surfaces related to shadows, would I be able to more easily identify them in the logs by them having the same format #? Or, based on your comments in the DDDA thread, could I simply remove the height and width values, and have this apply to all render targets with this format, which may hopefully preemptively set shadows to be rendered in mono?[/quote]Format 34 in DX9 is D3DFMT_G16R16, not a common format and a little unusual for a shadow map since it's a two channel format, but they might be using the second channel for something. In general most games will stick to one or two formats for shadow maps and they usually won't overlap much with other effects, so you are usually fine to remove the width & height from the match, but of course I can't guarantee that will be the case. It's certainly not a common format, so I think it will be fine. [quote]So that's great about all that being sorted out, however that doesn't seem to improve the matter of the environmental lighting/shadows. I didn't bother to try to play around with modifying any of those shaders now that I've made the above adjustment, but at glancing at the broken effects, they don't look any different than before, so I have my doubts that they've been affected by this... yet.[/quote]Sometimes directional shadows follow the same pattern as point lights, and sometimes they don't. They could well be using a different format shadow map - it's at least fairly common for there to be several of different sizes if the game is using "cascaded shadows".
DJ-RK said:Alright! I was able to follow your instruction and worked out that creating the below surface got shadows from my lantern to be able to be fixed properly without needing to adjust the shadowcasters. Great lesson, should definitely be useful going forward!
Great :)

So now, does this work out that format 34 equates to shadows, so if I need to create any additional surfaces related to shadows, would I be able to more easily identify them in the logs by them having the same format #? Or, based on your comments in the DDDA thread, could I simply remove the height and width values, and have this apply to all render targets with this format, which may hopefully preemptively set shadows to be rendered in mono?
Format 34 in DX9 is D3DFMT_G16R16, not a common format and a little unusual for a shadow map since it's a two channel format, but they might be using the second channel for something. In general most games will stick to one or two formats for shadow maps and they usually won't overlap much with other effects, so you are usually fine to remove the width & height from the match, but of course I can't guarantee that will be the case. It's certainly not a common format, so I think it will be fine.

So that's great about all that being sorted out, however that doesn't seem to improve the matter of the environmental lighting/shadows. I didn't bother to try to play around with modifying any of those shaders now that I've made the above adjustment, but at glancing at the broken effects, they don't look any different than before, so I have my doubts that they've been affected by this... yet.
Sometimes directional shadows follow the same pattern as point lights, and sometimes they don't. They could well be using a different format shadow map - it's at least fairly common for there to be several of different sizes if the game is using "cascaded shadows".

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 01/26/2016 06:18 PM   
Quick question. I haven't really looked into 3Dmigoto but maybe I misread it but is there a function to grab textures [like from models?]
Quick question. I haven't really looked into 3Dmigoto but maybe I misread it but is there a function to grab textures [like from models?]

Co-founder/Web host of helixmod.blog.com

Donations for web hosting @ paypal -eqzitara@yahoo.com
or
https://www.patreon.com/user?u=791918

Posted 01/27/2016 12:27 AM   
It has texture injection, if that's what your asking. [url]https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/4767495/#4767495[/url]

Posted 01/27/2016 12:48 AM   
[quote="eqzitara"]Quick question. I haven't really looked into 3Dmigoto but maybe I misread it but is there a function to grab textures [like from models?][/quote]Yeah, you can use frame analysis to extract textures from the game. If you know the shader of the model you are trying to extract it's best to set it in that ShaderOverride section rather than globally so you don't have to wait for it to dump out every single texture used in the frame (it will still dump textures every time the shader is used and doesn't currently check if it has already dumped out a particular texture, so it might still take a lot of time & disk space if the shader is common). Uncomment ;analyse_frame=VK_F8 and add a section like this: [code] [ShaderOverrideModel] hash = <fill me in> analyse_options = mono dump_tex [/code] dump_tex will try to dump the texture as jpeg if the format is supported by DirectTK, and DDS otherwise. If you need DDS (say, to preserve an alpha channel or to dump it lossless), use dump_tex_dds. mono is there to stop it trying to dump out a stereo view of the texture (if it's a model texture it wouldn't be stereo so you would just get garbage in the other eye). To start the dump, press F8 while hunting mode is enabled.
eqzitara said:Quick question. I haven't really looked into 3Dmigoto but maybe I misread it but is there a function to grab textures [like from models?]
Yeah, you can use frame analysis to extract textures from the game. If you know the shader of the model you are trying to extract it's best to set it in that ShaderOverride section rather than globally so you don't have to wait for it to dump out every single texture used in the frame (it will still dump textures every time the shader is used and doesn't currently check if it has already dumped out a particular texture, so it might still take a lot of time & disk space if the shader is common). Uncomment ;analyse_frame=VK_F8 and add a section like this:
[ShaderOverrideModel]
hash = <fill me in>
analyse_options = mono dump_tex


dump_tex will try to dump the texture as jpeg if the format is supported by DirectTK, and DDS otherwise. If you need DDS (say, to preserve an alpha channel or to dump it lossless), use dump_tex_dds. mono is there to stop it trying to dump out a stereo view of the texture (if it's a model texture it wouldn't be stereo so you would just get garbage in the other eye).

To start the dump, press F8 while hunting mode is enabled.

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 01/27/2016 01:03 AM   
  50 / 88    
Scroll To Top