Thanks DarkStarSword!! Now is working....i miss changing the second value for "y2".
In Lichdom do you found an issue with water reflection....where the water have some type of tesselation? i don't found anything related in your github.
if you look the screenshot, one reflection render ok (in the right bush), but the other not (left bush)
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/65348/[/img]
Thanks DarkStarSword!! Now is working....i miss changing the second value for "y2".
In Lichdom do you found an issue with water reflection....where the water have some type of tesselation? i don't found anything related in your github.
if you look the screenshot, one reflection render ok (in the right bush), but the other not (left bush)
The worst of that reflection looks like a fake environmental map reflection. If it's the same as Lichdom I fixed by applying a 1/2 stereo adjustment on one of the texcoord outputs:
https://github.com/DarkStarSword/3d-fixes/blob/master/Lichdom%20Battlemage/ShaderFixes/3981845112a28c3d-ds.txt
https://github.com/DarkStarSword/3d-fixes/blob/master/Lichdom%20Battlemage/ShaderFixes/27a0e398808011b9-vs_replace.txt
That said, these reflections don't look as simple as Lichdom since they appear to contain a true reflection as well (which may need an adjustment as well? It looks like it is hovering on the surface?). I'm not sure - but it looks like the reflection of the rock on the right is doubled in the left eye, which might possibly need a StereoMode override to fix.
I can take a look at these tonight and see if I can work anything out - where can I find this reflection in the game?
The worst of that reflection looks like a fake environmental map reflection. If it's the same as Lichdom I fixed by applying a 1/2 stereo adjustment on one of the texcoord outputs:
That said, these reflections don't look as simple as Lichdom since they appear to contain a true reflection as well (which may need an adjustment as well? It looks like it is hovering on the surface?). I'm not sure - but it looks like the reflection of the rock on the right is doubled in the left eye, which might possibly need a StereoMode override to fix.
I can take a look at these tonight and see if I can work anything out - where can I find this reflection in the 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
Yes, have a true reflection and the surface have some kind of tesselation (it's a hard one)...Also, when you look a little up to that water all reflections are ok due the true reflection movement. Also changing WATER quality or/and SHADING quality looks the same.
Also for that water i already fix the halo in the DS (1fbb6f74a9449b02-ds)
That water is in the 5 Checkpoint of the chapter "Welcome to the Jungle".
You can use my savegame:
[url]https://s3.amazonaws.com/dhr/SaveGames.zip[/url]
Yes, have a true reflection and the surface have some kind of tesselation (it's a hard one)...Also, when you look a little up to that water all reflections are ok due the true reflection movement. Also changing WATER quality or/and SHADING quality looks the same.
Also for that water i already fix the halo in the DS (1fbb6f74a9449b02-ds)
That water is in the 5 Checkpoint of the chapter "Welcome to the Jungle".
You can use my savegame:
This is what I've been able to come up with for the reflections so far (on 'high' water quality, not 'very high'). It's a lot better then before, but could still use more work. I probably won't have time to look at this any more before I go on holidays (maybe a little on Saturday), but hopefully it will be enough to get you started:
https://github.com/DarkStarSword/3d-fixes/commit/0f68c48ab804e9cfd6c260f209dd596d12665f9b
It moves the environment reflection to water depth and adjusts the screen space reflections. The former should probably be pushed deeper and the later needs more experimentation to see if it can be improved any further - there's a bunch of places v5 is used and I have switched some of them to adj_v5 / iadj_v5 where it seemed to help, but I haven't tried all the possibilities yet. Plus a fudge factor might be able to help.
I'm not sure, but I think there might be a decompiler bug making the environment map reflections brigher than they should be. I didn't look into this at all, but it's probably worth double checking.
This fix won't work on 'very high' yet, as I don't think we can define new outputs in the assembler yet (Flugan - correct me if I'm wrong). Also note that the vertex + pixel shaders change if there is a ripple being drawn.
This is what I've been able to come up with for the reflections so far (on 'high' water quality, not 'very high'). It's a lot better then before, but could still use more work. I probably won't have time to look at this any more before I go on holidays (maybe a little on Saturday), but hopefully it will be enough to get you started:
https://github.com/DarkStarSword/3d-fixes/commit/0f68c48ab804e9cfd6c260f209dd596d12665f9b
It moves the environment reflection to water depth and adjusts the screen space reflections. The former should probably be pushed deeper and the later needs more experimentation to see if it can be improved any further - there's a bunch of places v5 is used and I have switched some of them to adj_v5 / iadj_v5 where it seemed to help, but I haven't tried all the possibilities yet. Plus a fudge factor might be able to help.
I'm not sure, but I think there might be a decompiler bug making the environment map reflections brigher than they should be. I didn't look into this at all, but it's probably worth double checking.
This fix won't work on 'very high' yet, as I don't think we can define new outputs in the assembler yet (Flugan - correct me if I'm wrong). Also note that the vertex + pixel shaders change if there is a ripple being drawn.
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
@DarkStarSword
Using those 4 fixed shader and WATER = HIGH and PARTICLE = HIGH looks a little better....but when you start to move looking the water the fix is gone (disable), and when you look up and down with the water in front....there is a black stuff over the water that moves.
Also i test with VERY HIGH settings and the PS related to water, they have a HLSL Error message in the bottom (i attach the shaders related)
[code] /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HLSL errors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wrapper1349(165,13-82):warning X3206: 'SampleGrad': implicit truncation of vector type[/code]
and
[code]/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HLSL errors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wrapper1349(188,24-35):warning X4121: gradient-based operations must be moved out of flow control to prevent divergence. Performance may improve by using a non-gradient operation[/code]
This HLSL Error [u]are also present in the fixed PS for HIGH settings[/u]....like you say, i thing there is a decompiler bug for those shaders.
@DarkStarSword
Using those 4 fixed shader and WATER = HIGH and PARTICLE = HIGH looks a little better....but when you start to move looking the water the fix is gone (disable), and when you look up and down with the water in front....there is a black stuff over the water that moves.
Also i test with VERY HIGH settings and the PS related to water, they have a HLSL Error message in the bottom (i attach the shaders related)
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HLSL errors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wrapper1349(165,13-82):warning X3206: 'SampleGrad': implicit truncation of vector type
and
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HLSL errors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wrapper1349(188,24-35):warning X4121: gradient-based operations must be moved out of flow control to prevent divergence. Performance may improve by using a non-gradient operation
This HLSL Error are also present in the fixed PS for HIGH settings....like you say, i thing there is a decompiler bug for those shaders.
@DHR: In general, the warnings are just that, a warning, it's rare to cause any problems with the shaders. If you want to remove the warning fix the SampleGrad line in 9b3a shader to be:
[code] r3.xyzw = ReflSampler.SampleGrad(ReflSampler_s, r3.xy, r2.xy, float2(0,0)).xyzw;[/code]
I cannot tell if the decompile has any errors. If you want me to take a look at these, I am happy to, but you must leave the ASM at the bottom of the file. When you delete it, I have nothing to compare against. That's why I generate that in the first place. Out of curiousity, why do you delete those? They are commented out and will have no impact on the HLSL.
@DHR: In general, the warnings are just that, a warning, it's rare to cause any problems with the shaders. If you want to remove the warning fix the SampleGrad line in 9b3a shader to be:
I cannot tell if the decompile has any errors. If you want me to take a look at these, I am happy to, but you must leave the ASM at the bottom of the file. When you delete it, I have nothing to compare against. That's why I generate that in the first place. Out of curiousity, why do you delete those? They are commented out and will have no impact on the HLSL.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
@DHR: For the 5b48 vertex shader, I do think that Decompile code is wrong. I'm still puzzling out why this happened, but here is the replacement code, and it will make the output identical to the original ASM at the bottom of the file.
// Water VS 1
// 9b3ac1b07bf3efc1 de67fe4f68dba921
Ok, the "HLSL Error" message scared me a bit...
I don't delete anything....they are dumped like that.
Edit: sorry bo3b!...i just noticed that dxd3.ini have "export_hlsl=1" ..i just changed to 2.
[quote="Flugan"]It is possible to add an output as far as I can tell[/quote]Great :)
I was under the impression that we couldn't do this with assembly yet because we reuse the output signature (OSGN) and input signature (ISGN) sections from the original shader binary, and those sections would need to change as it is the part that contains the semantics which are used by the hardware to link VS/DS/GS outputs to PS inputs - so, we could add an extra output but it wouldn't make it into the next shader.
I also had some concerns that the MS disassembler may not be giving us enough information in the dcl_ lines to recreate these sections and we may have to parse the comments it generates (DX9 used dcl_texcoordX oY.xyz, which includes the semantic type, index, register and mask, but DX11 only uses dcl_output oY.xyz, which lacks the semantic and index).
This isn't an issue with HLSL shaders as the compiler will generate new ISGN and OSGN sections.
Flugan said:It is possible to add an output as far as I can tell
Great :)
I was under the impression that we couldn't do this with assembly yet because we reuse the output signature (OSGN) and input signature (ISGN) sections from the original shader binary, and those sections would need to change as it is the part that contains the semantics which are used by the hardware to link VS/DS/GS outputs to PS inputs - so, we could add an extra output but it wouldn't make it into the next shader.
I also had some concerns that the MS disassembler may not be giving us enough information in the dcl_ lines to recreate these sections and we may have to parse the comments it generates (DX9 used dcl_texcoordX oY.xyz, which includes the semantic type, index, register and mask, but DX11 only uses dcl_output oY.xyz, which lacks the semantic and index).
This isn't an issue with HLSL shaders as the compiler will generate new ISGN and OSGN sections.
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
[quote="bo3b"]@DHR: For the 5b48 vertex shader, I do think that Decompile code is wrong. I'm still puzzling out why this happened, but here is the replacement code, and it will make the output identical to the original ASM at the bottom of the file.[/quote]Looks like the same thing I hit in FC4 the other day. Did you see my theory that this may be due to the differences between boolean comparisons in asm vs HLSL:
https://github.com/bo3b/3Dmigoto/commit/3e6a0a5daf91262efbb673c4d2621a7406f58d1a
bo3b said:@DHR: For the 5b48 vertex shader, I do think that Decompile code is wrong. I'm still puzzling out why this happened, but here is the replacement code, and it will make the output identical to the original ASM at the bottom of the file.
[quote="DHR"]@DarkStarSword
Using those 4 fixed shader and WATER = HIGH and PARTICLE = HIGH looks a little better....but when you start to move looking the water the fix is gone (disable), and when you look up and down with the water in front....there is a black stuff over the water that moves.[/quote]
There might be some more shaders to find there. I found that there are at least two pixel shaders used for the water (one constructs the reflection, the second draws the surface), and these would switch out in certain circumstances (at least when touching the water the shaders switch). It also seems like some quality settings may share vertex/domain shaders, but other settings may use two separate vertex/domain shaders - that was why I moved the halo fix into the pixel shader.
It probably also needs more experimentation to find the best fix. Unfortunately I don't think I'll have another chance to look at this for a few weeks, but hopefully you or Mike can find a solution.
Regarding frame analysis in Crysis 3 - I'm finding that it doesn't seem to work reliably on most attempts. It creates the analysis directory but doesn't create any files. If I hit F8 repeatedly eventually one of the attempts does work. This may be some interaction with the Origin overlay (say, if the overlay calls Present() as well as the game we would start analysis from the game's Present(), then immediately stop it on Origin's Present()). I need to investigate further, but this won't happen until I get back.
DHR said:@DarkStarSword
Using those 4 fixed shader and WATER = HIGH and PARTICLE = HIGH looks a little better....but when you start to move looking the water the fix is gone (disable), and when you look up and down with the water in front....there is a black stuff over the water that moves.
There might be some more shaders to find there. I found that there are at least two pixel shaders used for the water (one constructs the reflection, the second draws the surface), and these would switch out in certain circumstances (at least when touching the water the shaders switch). It also seems like some quality settings may share vertex/domain shaders, but other settings may use two separate vertex/domain shaders - that was why I moved the halo fix into the pixel shader.
It probably also needs more experimentation to find the best fix. Unfortunately I don't think I'll have another chance to look at this for a few weeks, but hopefully you or Mike can find a solution.
Regarding frame analysis in Crysis 3 - I'm finding that it doesn't seem to work reliably on most attempts. It creates the analysis directory but doesn't create any files. If I hit F8 repeatedly eventually one of the attempts does work. This may be some interaction with the Origin overlay (say, if the overlay calls Present() as well as the game we would start analysis from the game's Present(), then immediately stop it on Origin's Present()). I need to investigate further, but this won't happen until I get back.
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
[quote="DarkStarSword"][quote="bo3b"]@DHR: For the 5b48 vertex shader, I do think that Decompile code is wrong. I'm still puzzling out why this happened, but here is the replacement code, and it will make the output identical to the original ASM at the bottom of the file.[/quote]Looks like the same thing I hit in FC4 the other day. Did you see my theory that this may be due to the differences between boolean comparisons in asm vs HLSL:
https://github.com/bo3b/3Dmigoto/commit/3e6a0a5daf91262efbb673c4d2621a7406f58d1a[/quote]
Hadn't seen that check-in before, but yep, that's exactly what I'm seeing with this vertex shader.
In general, the Decompiler does in fact try to keep track of the difference between a boolean state and a numeric value. And tries to use -1 (0xffffffff) for the true state. So for example in _iadd it does:
[code] sprintf(buffer, " %s = (%s ? -1 : 0) + (%s ? 1 : 0);\n", writeTarget(op1), ci(convertToInt(op2)).c_str(), ci(convertToInt(op3)).c_str());
[/code]
Where it uses the ternary to provide the correct output of -1 or 0.
Which... has a bug. The second turnary should also be using -1 in the boolean case, to provide the 0xffffffff bitfield that we need. The idea is sound though- use the HLSL idea of boolean testing (0/1) and use that to generate the binary pattern we want.
Now a curious part I cannot seem to quite get around is that if I fix that bug, the code is still generated wrong.
If I do the logical conversion:
[code]r0.x = 0 < r1.z;
r0.y = r1.z < 0;
r0.x = -((int)r0.x ? -1 : 0) + ((int)r0.y ? -1 : 0);
o2.w = r0.x;
[/code]
I still get:
[code]lt r0.x, l(0.000000), r1.z
and r0.x, r0.x, l(1)
lt r0.y, r1.z, l(0.000000)
iadd r0.x, r0.y, r0.x
itof o2.w, r0.x[/code]
[s]
Where I have lost the minus sign for the iadd, and we are using integer 1 instead. I really hate to blame the fxc compiler, but I can't see how that is legitimate. Even if it were generating float, the values are wrong.
[/s]
No, that's right. The and forcing it to one, then removing the negation is in fact going to give the same ending result, as it could only ever be -1 or 0 to start with.
Edit: OK, I see what's happened here now. This is a bug in _IADD generation, two bugs actually.
If you replace the output line, this generates different code than the original, but it's still correct.
[code]bad: r0.x = ((int)r0.x ? -1 : 0) + ((int)r0.y ? 1 : 0);
good: r0.x = -((int)r0.x ? -1 : 0) + ((int)r0.y ? -1 : 0);
[/code]
Edit2: That _ITOF example you ran into suggests we have this upside down in the Decompiler, because to make that work, it should have had the test for boolean input and then generate the ternary. Rather than do that in every possible spot, it seems like it would be better to put the ternary assignment at each of the test instructions like _LT, _EQ and so on.
Like:
[code]r0.x = (0 < r1.z) ? asint(-1) : 0;[/code]
That would be a gigantic, risky change though, so I'll try to think that one through and test it against prior fixes.
bo3b said:@DHR: For the 5b48 vertex shader, I do think that Decompile code is wrong. I'm still puzzling out why this happened, but here is the replacement code, and it will make the output identical to the original ASM at the bottom of the file.
Hadn't seen that check-in before, but yep, that's exactly what I'm seeing with this vertex shader.
In general, the Decompiler does in fact try to keep track of the difference between a boolean state and a numeric value. And tries to use -1 (0xffffffff) for the true state. So for example in _iadd it does:
Where it uses the ternary to provide the correct output of -1 or 0.
Which... has a bug. The second turnary should also be using -1 in the boolean case, to provide the 0xffffffff bitfield that we need. The idea is sound though- use the HLSL idea of boolean testing (0/1) and use that to generate the binary pattern we want.
Now a curious part I cannot seem to quite get around is that if I fix that bug, the code is still generated wrong.
Where I have lost the minus sign for the iadd, and we are using integer 1 instead. I really hate to blame the fxc compiler, but I can't see how that is legitimate. Even if it were generating float, the values are wrong.
No, that's right. The and forcing it to one, then removing the negation is in fact going to give the same ending result, as it could only ever be -1 or 0 to start with.
Edit: OK, I see what's happened here now. This is a bug in _IADD generation, two bugs actually.
If you replace the output line, this generates different code than the original, but it's still correct.
Edit2: That _ITOF example you ran into suggests we have this upside down in the Decompiler, because to make that work, it should have had the test for boolean input and then generate the ternary. Rather than do that in every possible spot, it seems like it would be better to put the ternary assignment at each of the test instructions like _LT, _EQ and so on.
Like:
r0.x = (0 < r1.z) ? asint(-1) : 0;
That would be a gigantic, risky change though, so I'll try to think that one through and test it against prior fixes.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
[quote="DHR"]Ok, the "HLSL Error" message scared me a bit...
I don't delete anything....they are dumped like that.
Edit: sorry bo3b!...i just noticed that dxd3.ini have "export_hlsl=1" ..i just changed to 2.[/quote]
Ah, right-o. If you regenerate the file or have the ASM available, I'm happy to take a look at the shaders that seem to be in error.
[quote="DHR"]Yes, have a true reflection and the surface have some kind of tesselation (it's a hard one)...Also, when you look a little up to that water all reflections are ok due the true reflection movement. Also changing WATER quality or/and SHADING quality looks the same.[/quote]
If that VS above of 5b48 is active here, that could easily explain the symptoms. The output would be either '1' or 0, and in the wrong order. If it's in use, try my hand-fixed version there, as it will be identical to the original.
DHR said:Ok, the "HLSL Error" message scared me a bit...
I don't delete anything....they are dumped like that.
Edit: sorry bo3b!...i just noticed that dxd3.ini have "export_hlsl=1" ..i just changed to 2.
Ah, right-o. If you regenerate the file or have the ASM available, I'm happy to take a look at the shaders that seem to be in error.
DHR said:Yes, have a true reflection and the surface have some kind of tesselation (it's a hard one)...Also, when you look a little up to that water all reflections are ok due the true reflection movement. Also changing WATER quality or/and SHADING quality looks the same.
If that VS above of 5b48 is active here, that could easily explain the symptoms. The output would be either '1' or 0, and in the wrong order. If it's in use, try my hand-fixed version there, as it will be identical to the original.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
In Lichdom do you found an issue with water reflection....where the water have some type of tesselation? i don't found anything related in your github.
if you look the screenshot, one reflection render ok (in the right bush), but the other not (left bush)
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
https://github.com/DarkStarSword/3d-fixes/blob/master/Lichdom%20Battlemage/ShaderFixes/3981845112a28c3d-ds.txt
https://github.com/DarkStarSword/3d-fixes/blob/master/Lichdom%20Battlemage/ShaderFixes/27a0e398808011b9-vs_replace.txt
That said, these reflections don't look as simple as Lichdom since they appear to contain a true reflection as well (which may need an adjustment as well? It looks like it is hovering on the surface?). I'm not sure - but it looks like the reflection of the rock on the right is doubled in the left eye, which might possibly need a StereoMode override to fix.
I can take a look at these tonight and see if I can work anything out - where can I find this reflection in the 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
Also for that water i already fix the halo in the DS (1fbb6f74a9449b02-ds)
That water is in the 5 Checkpoint of the chapter "Welcome to the Jungle".
You can use my savegame:
https://s3.amazonaws.com/dhr/SaveGames.zip
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
https://steamcommunity.com/profiles/76561198014296177/
https://github.com/DarkStarSword/3d-fixes/commit/0f68c48ab804e9cfd6c260f209dd596d12665f9b
It moves the environment reflection to water depth and adjusts the screen space reflections. The former should probably be pushed deeper and the later needs more experimentation to see if it can be improved any further - there's a bunch of places v5 is used and I have switched some of them to adj_v5 / iadj_v5 where it seemed to help, but I haven't tried all the possibilities yet. Plus a fudge factor might be able to help.
I'm not sure, but I think there might be a decompiler bug making the environment map reflections brigher than they should be. I didn't look into this at all, but it's probably worth double checking.
This fix won't work on 'very high' yet, as I don't think we can define new outputs in the assembler yet (Flugan - correct me if I'm wrong). Also note that the vertex + pixel shaders change if there is a ripple being drawn.
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
before
after
Lichdom shaderfix: ffd5491b00d77e9b-vs_replace.txt
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
Using those 4 fixed shader and WATER = HIGH and PARTICLE = HIGH looks a little better....but when you start to move looking the water the fix is gone (disable), and when you look up and down with the water in front....there is a black stuff over the water that moves.
Also i test with VERY HIGH settings and the PS related to water, they have a HLSL Error message in the bottom (i attach the shaders related)
and
This HLSL Error are also present in the fixed PS for HIGH settings....like you say, i thing there is a decompiler bug for those shaders.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
I cannot tell if the decompile has any errors. If you want me to take a look at these, I am happy to, but you must leave the ASM at the bottom of the file. When you delete it, I have nothing to compare against. That's why I generate that in the first place. Out of curiousity, why do you delete those? They are commented out and will have no impact on the HLSL.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
I don't delete anything....they are dumped like that.
Edit: sorry bo3b!...i just noticed that dxd3.ini have "export_hlsl=1" ..i just changed to 2.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
I was under the impression that we couldn't do this with assembly yet because we reuse the output signature (OSGN) and input signature (ISGN) sections from the original shader binary, and those sections would need to change as it is the part that contains the semantics which are used by the hardware to link VS/DS/GS outputs to PS inputs - so, we could add an extra output but it wouldn't make it into the next shader.
I also had some concerns that the MS disassembler may not be giving us enough information in the dcl_ lines to recreate these sections and we may have to parse the comments it generates (DX9 used dcl_texcoordX oY.xyz, which includes the semantic type, index, register and mask, but DX11 only uses dcl_output oY.xyz, which lacks the semantic and index).
This isn't an issue with HLSL shaders as the compiler will generate new ISGN and OSGN sections.
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
https://github.com/bo3b/3Dmigoto/commit/3e6a0a5daf91262efbb673c4d2621a7406f58d1a
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
There might be some more shaders to find there. I found that there are at least two pixel shaders used for the water (one constructs the reflection, the second draws the surface), and these would switch out in certain circumstances (at least when touching the water the shaders switch). It also seems like some quality settings may share vertex/domain shaders, but other settings may use two separate vertex/domain shaders - that was why I moved the halo fix into the pixel shader.
It probably also needs more experimentation to find the best fix. Unfortunately I don't think I'll have another chance to look at this for a few weeks, but hopefully you or Mike can find a solution.
Regarding frame analysis in Crysis 3 - I'm finding that it doesn't seem to work reliably on most attempts. It creates the analysis directory but doesn't create any files. If I hit F8 repeatedly eventually one of the attempts does work. This may be some interaction with the Origin overlay (say, if the overlay calls Present() as well as the game we would start analysis from the game's Present(), then immediately stop it on Origin's Present()). I need to investigate further, but this won't happen until I get back.
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
Hadn't seen that check-in before, but yep, that's exactly what I'm seeing with this vertex shader.
In general, the Decompiler does in fact try to keep track of the difference between a boolean state and a numeric value. And tries to use -1 (0xffffffff) for the true state. So for example in _iadd it does:
Where it uses the ternary to provide the correct output of -1 or 0.
Which... has a bug. The second turnary should also be using -1 in the boolean case, to provide the 0xffffffff bitfield that we need. The idea is sound though- use the HLSL idea of boolean testing (0/1) and use that to generate the binary pattern we want.
Now a curious part I cannot seem to quite get around is that if I fix that bug, the code is still generated wrong.
If I do the logical conversion:
I still get:
Where I have lost the minus sign for the iadd, and we are using integer 1 instead. I really hate to blame the fxc compiler, but I can't see how that is legitimate. Even if it were generating float, the values are wrong.
No, that's right. The and forcing it to one, then removing the negation is in fact going to give the same ending result, as it could only ever be -1 or 0 to start with.
Edit: OK, I see what's happened here now. This is a bug in _IADD generation, two bugs actually.
If you replace the output line, this generates different code than the original, but it's still correct.
Edit2: That _ITOF example you ran into suggests we have this upside down in the Decompiler, because to make that work, it should have had the test for boolean input and then generate the ternary. Rather than do that in every possible spot, it seems like it would be better to put the ternary assignment at each of the test instructions like _LT, _EQ and so on.
Like:
That would be a gigantic, risky change though, so I'll try to think that one through and test it against prior fixes.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
Ah, right-o. If you regenerate the file or have the ASM available, I'm happy to take a look at the shaders that seem to be in error.
If that VS above of 5b48 is active here, that could easily explain the symptoms. The output would be either '1' or 0, and in the wrong order. If it's in use, try my hand-fixed version there, as it will be identical to the original.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers