Another interesting case. This one doesn't compile because the sampler is specified incorrectly by the decompiler. I added this as a sample shader to the project, as one that doesn't decompile right.
BTW. The first line was a warning not an error. The key distinction being that the warnings, especially for truncation, almost never matter.
Here is the hand-fixed code that will compile and generate the same ASM.
// Manually fixed shader.
// key instructions are the same after recompile with fxc.
Texture2D<float4> t1 : register(t1);
Texture2D<float4> t0 : register(t0);
// Used as a SampleCmpLevelZero, so needs to be comparison type
SamplerComparisonState s1 : register(s1);
[quote="Jan-Itor"]If I want to shader hunt in Assassins Creed 3, how exactly do I go about doing that? I tried different releases but everything crashes.[/quote]Even though Assassins Creed 3 is already fixed?
The code there is the oldest we've got, and I will update the fix at some point with a more modern version.
Until then, you can use any recent release of the 3Dmigoto, but best bet would be to use the reently updated AC4 dlls: [url]https://github.com/bo3b/3Dmigoto/releases/tag/0.98-beta[/url]
Use everything from that fix, except for the ShaderFixes folder. The AC3 ShaderFixes folder will still work with this latest code.
This latest code base fixes some requirements we had earlier, no need for KB platform update, and it works OK on 8.1 now. Your crashes are nearly sure to be one of those two problems.
Using that AC4 version, you can edit the .ini file to enable hunting=1, and it should work pretty well. You [i]might [/i]need to also enable force_cpu_affinity=1 while hunting, as AC3 had a weird flickering shader when selected.
Let me know if that doesn't work for you.
Use everything from that fix, except for the ShaderFixes folder. The AC3 ShaderFixes folder will still work with this latest code.
This latest code base fixes some requirements we had earlier, no need for KB platform update, and it works OK on 8.1 now. Your crashes are nearly sure to be one of those two problems.
Using that AC4 version, you can edit the .ini file to enable hunting=1, and it should work pretty well. You might need to also enable force_cpu_affinity=1 while hunting, as AC3 had a weird flickering shader when selected.
Let me know if that doesn't work for you.
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="bo3b"]Even though Assassins Creed 3 is already fixed?[/quote]
I wanna remove these white outlines around NPCs:
http://i.minus.com/ibwL6VOBJ5y9rK.png
I've done it for all the DX9 Assassins Creeds with Helix wrapper, now I'm trying to do it for the DX11 games :)
[quote="bo3b"]The code there is the oldest we've got, and I will update the fix at some point with a more modern version.
Until then, you can use any recent release of the 3Dmigoto, but best bet would be to use the reently updated AC4 dlls: [url]https://github.com/bo3b/3Dmigoto/releases/tag/0.98-beta[/url]
Use everything from that fix, except for the ShaderFixes folder. The AC3 ShaderFixes folder will still work with this latest code.
This latest code base fixes some requirements we had earlier, no need for KB platform update, and it works OK on 8.1 now. Your crashes are nearly sure to be one of those two problems.
Using that AC4 version, you can edit the .ini file to enable hunting=1, and it should work pretty well. You [i]might [/i]need to also enable force_cpu_affinity=1 while hunting, as AC3 had a weird flickering shader when selected.
Let me know if that doesn't work for you.[/quote]
Well it doesn't crash anymore, but shader hunting doesn't seem to be working, nothing happens when I press the numpad keys. (I've set hunting=1)
Thanks for you help
Use everything from that fix, except for the ShaderFixes folder. The AC3 ShaderFixes folder will still work with this latest code.
This latest code base fixes some requirements we had earlier, no need for KB platform update, and it works OK on 8.1 now. Your crashes are nearly sure to be one of those two problems.
Using that AC4 version, you can edit the .ini file to enable hunting=1, and it should work pretty well. You might need to also enable force_cpu_affinity=1 while hunting, as AC3 had a weird flickering shader when selected.
Let me know if that doesn't work for you.
Well it doesn't crash anymore, but shader hunting doesn't seem to be working, nothing happens when I press the numpad keys. (I've set hunting=1)
Thanks for you help
1080 Ti - i7 5820k - 16Gb RAM - Win 10 version 1607 - ASUS VG236H (1920x1080@120Hz)
OK, cool, we love to see any changes you like to make it better.
Since then I've also implemented constants, so we can make your change an optional setting via the .ini file.
I went ahead and tested it, to see how it works with the current codebase. It looks good to me.
Runs without crashing, shaderhunting was working OK for me. I did get the flicker on shaders, instead of blanking them, and had to set the affinity flag as well to make it searchable. (really hammers performance of course).
I also got to be reminded why I hate both Steam and UPlay now, because they both have to launch, and both want to put up overlays. All the people involved with this double DRM thing are evil, hateful people.
Did you disable the fake-3D with ctrl-alt-F11? I don't think shader hunting works in CM. That's all I can think of at the moment, the newer code base is simpler and much more compatible with all games.
OK, cool, we love to see any changes you like to make it better.
Since then I've also implemented constants, so we can make your change an optional setting via the .ini file.
I went ahead and tested it, to see how it works with the current codebase. It looks good to me.
Runs without crashing, shaderhunting was working OK for me. I did get the flicker on shaders, instead of blanking them, and had to set the affinity flag as well to make it searchable. (really hammers performance of course).
I also got to be reminded why I hate both Steam and UPlay now, because they both have to launch, and both want to put up overlays. All the people involved with this double DRM thing are evil, hateful people.
Did you disable the fake-3D with ctrl-alt-F11? I don't think shader hunting works in CM. That's all I can think of at the moment, the newer code base is simpler and much more compatible with all games.
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="bo3b"]the newer code base is simpler and much more compatible with all games.[/quote]
So that's in development? Maybe I should just wait for that instead :P
[quote="Jan-Itor"][quote="bo3b"]the newer code base is simpler and much more compatible with all games.[/quote]
So that's in development? Maybe I should just wait for that instead :P[/quote]No sorry, when I mean newer code base, it's newer than the AC3 fix, but is the same as the current AC4 fix. I made a lot of changes to support games like Saints Row and WatchDogs, and think the current code base is pretty solid.
I used the AC4 dlls, and it worked well on AC3.
bo3b said:the newer code base is simpler and much more compatible with all games.
So that's in development? Maybe I should just wait for that instead :P
No sorry, when I mean newer code base, it's newer than the AC3 fix, but is the same as the current AC4 fix. I made a lot of changes to support games like Saints Row and WatchDogs, and think the current code base is pretty solid.
I used the AC4 dlls, and it worked well on AC3.
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'm talking about the "float4 v4 : TEXCOORD3" whose z parameter was used for the stereo fix. How did you know that that could help to fix the shader for 3d?
No worries, I think it's good to explain some of these things in these threads, because it makes it easier for other people to learn as well, and they can be found with google searches. Sometimes we won't get back to you because of being too busy, but we always want to try to explain things.
[quote="ForgottenProdigy"]
Can't you just put
[code] float4 stereo = StereoParams.Load(0);
o0.xyzw = r1.xyzw;
r1.x += stereo.x * (r1.w - stereo.y);
[/code]
instead or is it necessary to create the r23 variable?[/quote]
Yep, you can do the simpler version. This is an artifact of copy and paste where early on we didn't quite understand how flexible HLSL is, and were using techniques that came from the ASM side, where you have to do it via temporary variables.
This fix is similar to the blood spatters in Alien, where the output itself needs to be unchanged, but we want to modify the follow-on uses of that variable to make it stereo.
[quote="ForgottenProdigy"]
2. Something else new that I saw was that you guys straight up created a new variable to be exported. Here's the full code for the shader:
...
I'm talking about the "[b]float4 v4 : TEXCOORD3[/b]" whose z parameter was used for the stereo fix. How did you know that that could help to fix the shader for 3d?[/quote]
This is actually fixing the problem in the corresponding PixelShader. The variable was added in the VertexShader associated with this effect, and is passing in the .z parameter as a specific matrix value to be used in the PixelShader. The VS had the proper matrix, the PS did not, so this is one way to pass that on where it's needed.
For whatever reason, this seems to work more often in DX11/HLSL than in the ASM versions. Sometimes it just doesn't work in ASM, and it's not clear why.
[quote="ForgottenProdigy"]
3. Can I assume that this line:
[code]r1.xyz = r0.www ? r3.yzw : r1.xyz;[/code]
being converted to
[code]r1.x = r0.w ? r3.y : r1.x;
r1.y = r0.w ? r3.z : r1.y;
r1.z = r0.w ? r3.w : r1.z; [/code]
is just manual decompiler fix or is it part of the 3d fix? I'm leaning on the decompiler fix side.
[/quote]
Yes, this is part of the back-and-forth that Mike and I do on fixes. Sometimes we find stuff that is broken because the Decompiler generated bad code, and I work out how to fix the code generation.
This one is actually the opposite, the unrolled version is actually wrong, the rolled up version is correct. We have some in-progress stuff that we don't bother to clean up, as long as we know it's working.
The unrolled version can do something like "r1.x = r1.x ? r2.x : r3.x", then in the next line, use r1.x again, and generate bad results. Since the output can possibly the test parameter, it's safer and generates the proper ASM to roll it back up. I hesitantly changed a bunch of these, because Chiri believes that they need to be unrolled, and wrote it that way originally. I've tested a lot of code, and am confident enough to leave them rolled up.
For the last part of the question, I'll leave that to Mike, as I don't know what it's doing either.
No worries, I think it's good to explain some of these things in these threads, because it makes it easier for other people to learn as well, and they can be found with google searches. Sometimes we won't get back to you because of being too busy, but we always want to try to explain things.
instead or is it necessary to create the r23 variable?
Yep, you can do the simpler version. This is an artifact of copy and paste where early on we didn't quite understand how flexible HLSL is, and were using techniques that came from the ASM side, where you have to do it via temporary variables.
This fix is similar to the blood spatters in Alien, where the output itself needs to be unchanged, but we want to modify the follow-on uses of that variable to make it stereo.
ForgottenProdigy said:
2. Something else new that I saw was that you guys straight up created a new variable to be exported. Here's the full code for the shader:
...
I'm talking about the "float4 v4 : TEXCOORD3" whose z parameter was used for the stereo fix. How did you know that that could help to fix the shader for 3d?
This is actually fixing the problem in the corresponding PixelShader. The variable was added in the VertexShader associated with this effect, and is passing in the .z parameter as a specific matrix value to be used in the PixelShader. The VS had the proper matrix, the PS did not, so this is one way to pass that on where it's needed.
For whatever reason, this seems to work more often in DX11/HLSL than in the ASM versions. Sometimes it just doesn't work in ASM, and it's not clear why.
ForgottenProdigy said:
3. Can I assume that this line:
is just manual decompiler fix or is it part of the 3d fix? I'm leaning on the decompiler fix side.
Yes, this is part of the back-and-forth that Mike and I do on fixes. Sometimes we find stuff that is broken because the Decompiler generated bad code, and I work out how to fix the code generation.
This one is actually the opposite, the unrolled version is actually wrong, the rolled up version is correct. We have some in-progress stuff that we don't bother to clean up, as long as we know it's working.
The unrolled version can do something like "r1.x = r1.x ? r2.x : r3.x", then in the next line, use r1.x again, and generate bad results. Since the output can possibly the test parameter, it's safer and generates the proper ASM to roll it back up. I hesitantly changed a bunch of these, because Chiri believes that they need to be unrolled, and wrote it that way originally. I've tested a lot of code, and am confident enough to leave them rolled up.
For the last part of the question, I'll leave that to Mike, as I don't know what it's doing either.
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
Continued from here: [url]https://forums.geforce.com/default/topic/766890/3d-vision/bo3bs-school-for-shaderhackers/post/4365642/#4365642[/url]
I have the debug & unbuffered flags set to 1 and export_hlsl is set to 3. Now the game crashes immediately.
[quote="bo3b"]No worries, I think it's good to explain some of these things in these threads, because it makes it easier for other people to learn as well, and they can be found with google searches. Sometimes we won't get back to you because of being too busy, but we always want to try to explain things.
[quote="ForgottenProdigy"]
Can't you just put
[code] float4 stereo = StereoParams.Load(0);
o0.xyzw = r1.xyzw;
r1.x += stereo.x * (r1.w - stereo.y);
[/code]
instead or is it necessary to create the r23 variable?[/quote]
Yep, you can do the simpler version. This is an artifact of copy and paste where early on we didn't quite understand how flexible HLSL is, and were using techniques that came from the ASM side, where you have to do it via temporary variables.
This fix is similar to the blood spatters in Alien, where the output itself needs to be unchanged, but we want to modify the follow-on uses of that variable to make it stereo.
[quote="ForgottenProdigy"]
2. Something else new that I saw was that you guys straight up created a new variable to be exported. Here's the full code for the shader:
...
I'm talking about the "[b]float4 v4 : TEXCOORD3[/b]" whose z parameter was used for the stereo fix. How did you know that that could help to fix the shader for 3d?[/quote]
This is actually fixing the problem in the corresponding PixelShader. The variable was added in the VertexShader associated with this effect, and is passing in the .z parameter as a specific matrix value to be used in the PixelShader. The VS had the proper matrix, the PS did not, so this is one way to pass that on where it's needed.
For whatever reason, this seems to work more often in DX11/HLSL than in the ASM versions. Sometimes it just doesn't work in ASM, and it's not clear why.
[quote="ForgottenProdigy"]
3. Can I assume that this line:
[code]r1.xyz = r0.www ? r3.yzw : r1.xyz;[/code]
being converted to
[code]r1.x = r0.w ? r3.y : r1.x;
r1.y = r0.w ? r3.z : r1.y;
r1.z = r0.w ? r3.w : r1.z; [/code]
is just manual decompiler fix or is it part of the 3d fix? I'm leaning on the decompiler fix side.
[/quote]
Yes, this is part of the back-and-forth that Mike and I do on fixes. Sometimes we find stuff that is broken because the Decompiler generated bad code, and I work out how to fix the code generation.
This one is actually the opposite, the unrolled version is actually wrong, the rolled up version is correct. We have some in-progress stuff that we don't bother to clean up, as long as we know it's working.
The unrolled version can do something like "r1.x = r1.x ? r2.x : r3.x", then in the next line, use r1.x again, and generate bad results. Since the output can possibly the test parameter, it's safer and generates the proper ASM to roll it back up. I hesitantly changed a bunch of these, because Chiri believes that they need to be unrolled, and wrote it that way originally. I've tested a lot of code, and am confident enough to leave them rolled up.
For the last part of the question, I'll leave that to Mike, as I don't know what it's doing either.[/quote]
Regarding the last part... As bo3b notes we sometimes have artifacts of experimentation left in the code. If you work it through this code is exactly the same as just fixing the r0.xyzw variable, so I could not be bothered to put it back. There are a couple of shaders I found early that required one of the o1 or o2 variables to use the non-shifted r0, that's why I created the duplicate r20 variable. I then applied this fix to several other similar shaders, only to find that it screwed them up so I had to revert back. VS are much less consistent in their patterns than PS, so this happens a lot. On average though, autofixing and then correcting the few things that break is still far quicker and more efficient than individually tracking every shader down.
Regarding the v4 variable I pass in. You will see some VS in the shaderfixes that pass out a TEXCOORD3 derived entirely form the k_vFullViewPlane constant. I found out that the z component has the FOV correction factor that is needed when correcting in View Space (which is what happens in the PS) so I pass that forward. To start with I copied the struct into the PS and was using the k_vFullViewPlane variable from there - this worked for some shaders, but not all. For the ones that did not work, the value was either always 0 so no correction was applied, or it changed to zero at some view angles which led to shadow/light 'snapping'. Because of this, I reverted most of them to use the TEXCOORD3 passing approach. I have had other issues with this particular struct (b(12) actually) not having any values in the VS for the Particle fixes, so I am forced to use a hardcoded magic number that only works for one FOV (normal gameplay) and not the benchmark (higher fov) or when using the bow (lower fov).
bo3b said:No worries, I think it's good to explain some of these things in these threads, because it makes it easier for other people to learn as well, and they can be found with google searches. Sometimes we won't get back to you because of being too busy, but we always want to try to explain things.
instead or is it necessary to create the r23 variable?
Yep, you can do the simpler version. This is an artifact of copy and paste where early on we didn't quite understand how flexible HLSL is, and were using techniques that came from the ASM side, where you have to do it via temporary variables.
This fix is similar to the blood spatters in Alien, where the output itself needs to be unchanged, but we want to modify the follow-on uses of that variable to make it stereo.
ForgottenProdigy said:
2. Something else new that I saw was that you guys straight up created a new variable to be exported. Here's the full code for the shader:
...
I'm talking about the "float4 v4 : TEXCOORD3" whose z parameter was used for the stereo fix. How did you know that that could help to fix the shader for 3d?
This is actually fixing the problem in the corresponding PixelShader. The variable was added in the VertexShader associated with this effect, and is passing in the .z parameter as a specific matrix value to be used in the PixelShader. The VS had the proper matrix, the PS did not, so this is one way to pass that on where it's needed.
For whatever reason, this seems to work more often in DX11/HLSL than in the ASM versions. Sometimes it just doesn't work in ASM, and it's not clear why.
ForgottenProdigy said:
3. Can I assume that this line:
is just manual decompiler fix or is it part of the 3d fix? I'm leaning on the decompiler fix side.
Yes, this is part of the back-and-forth that Mike and I do on fixes. Sometimes we find stuff that is broken because the Decompiler generated bad code, and I work out how to fix the code generation.
This one is actually the opposite, the unrolled version is actually wrong, the rolled up version is correct. We have some in-progress stuff that we don't bother to clean up, as long as we know it's working.
The unrolled version can do something like "r1.x = r1.x ? r2.x : r3.x", then in the next line, use r1.x again, and generate bad results. Since the output can possibly the test parameter, it's safer and generates the proper ASM to roll it back up. I hesitantly changed a bunch of these, because Chiri believes that they need to be unrolled, and wrote it that way originally. I've tested a lot of code, and am confident enough to leave them rolled up.
For the last part of the question, I'll leave that to Mike, as I don't know what it's doing either.
Regarding the last part... As bo3b notes we sometimes have artifacts of experimentation left in the code. If you work it through this code is exactly the same as just fixing the r0.xyzw variable, so I could not be bothered to put it back. There are a couple of shaders I found early that required one of the o1 or o2 variables to use the non-shifted r0, that's why I created the duplicate r20 variable. I then applied this fix to several other similar shaders, only to find that it screwed them up so I had to revert back. VS are much less consistent in their patterns than PS, so this happens a lot. On average though, autofixing and then correcting the few things that break is still far quicker and more efficient than individually tracking every shader down.
Regarding the v4 variable I pass in. You will see some VS in the shaderfixes that pass out a TEXCOORD3 derived entirely form the k_vFullViewPlane constant. I found out that the z component has the FOV correction factor that is needed when correcting in View Space (which is what happens in the PS) so I pass that forward. To start with I copied the struct into the PS and was using the k_vFullViewPlane variable from there - this worked for some shaders, but not all. For the ones that did not work, the value was either always 0 so no correction was applied, or it changed to zero at some view angles which led to shadow/light 'snapping'. Because of this, I reverted most of them to use the TEXCOORD3 passing approach. I have had other issues with this particular struct (b(12) actually) not having any values in the VS for the Particle fixes, so I am forced to use a hardcoded magic number that only works for one FOV (normal gameplay) and not the benchmark (higher fov) or when using the bow (lower fov).
[quote="4everAwake"]Continued from here: [url]https://forums.geforce.com/default/topic/766890/3d-vision/bo3bs-school-for-shaderhackers/post/4365642/#4365642[/url]
I have the debug & unbuffered flags set to 1 and export_hlsl is set to 3. Now the game crashes immediately. [/quote]
OK, thanks for that log. This one has a single shader that decompiles OK, then crashes on the next one it sees.
This looks like a parse failure where it creates an exception, but that should have been caught by my exception handler and reported.
Do you have any debugging tools installed that might interfere with exception handling?
One last thing to try for me would be to set the affinity flag so that it runs mostly single threaded. This can help me tell if it might be some multi-threaded problem. Set all the flags to 1 in the Logging section, but especially force_cpu_affinity=1 for this. Thanks for the help.
Edit: BTW, this debug build is worth trying in this case, because it might catch the crash earlier with an Assert, and includes a multi-threading Decompiler patch we needed for Mordor crashes.
https://github.com/bo3b/3Dmigoto/releases/download/0.99.2-beta/3Dmigoto-Debug-0.99.2.zip
I have the debug & unbuffered flags set to 1 and export_hlsl is set to 3. Now the game crashes immediately.
OK, thanks for that log. This one has a single shader that decompiles OK, then crashes on the next one it sees.
This looks like a parse failure where it creates an exception, but that should have been caught by my exception handler and reported.
Do you have any debugging tools installed that might interfere with exception handling?
One last thing to try for me would be to set the affinity flag so that it runs mostly single threaded. This can help me tell if it might be some multi-threaded problem. Set all the flags to 1 in the Logging section, but especially force_cpu_affinity=1 for this. Thanks for the help.
Ok I'm using version 0.99.2. I have all flags in the Logging section set to 1 and export_hlsl still set to 3. Now when I run the game, a dialog box pops up "Video Card does not meet the minimum requirements for DX 11 Switching to DX 9". The game still starts, but I'm not sure if 3dMigoto is hooked (nothing blinks out when I cycle through shaders).
Ok I'm using version 0.99.2. I have all flags in the Logging section set to 1 and export_hlsl still set to 3. Now when I run the game, a dialog box pops up "Video Card does not meet the minimum requirements for DX 11 Switching to DX 9". The game still starts, but I'm not sure if 3dMigoto is hooked (nothing blinks out when I cycle through shaders).
Totally weird. I have no idea what happened there to make it decide that it wasn't DX11. This might be the peril of working on a pre-release game, not sure.
Once it decided to switch to DX9 the logging stops because there is no longer any DX9 hook in 3Dmigoto.
It might be the affinity flag that makes it think to switch to DX9, hard to say. Worth experimenting with force_cpu_affinity=0, but still use the debug version of 0.99.2.
Totally weird. I have no idea what happened there to make it decide that it wasn't DX11. This might be the peril of working on a pre-release game, not sure.
Once it decided to switch to DX9 the logging stops because there is no longer any DX9 hook in 3Dmigoto.
It might be the affinity flag that makes it think to switch to DX9, hard to say. Worth experimenting with force_cpu_affinity=0, but still use the debug version of 0.99.2.
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
BTW. The first line was a warning not an error. The key distinction being that the warnings, especially for truncation, almost never matter.
Here is the hand-fixed code that will compile and generate the same ASM.
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
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
1080 Ti - i7 5820k - 16Gb RAM - Win 10 version 1607 - ASUS VG236H (1920x1080@120Hz)
The code there is the oldest we've got, and I will update the fix at some point with a more modern version.
Until then, you can use any recent release of the 3Dmigoto, but best bet would be to use the reently updated AC4 dlls: https://github.com/bo3b/3Dmigoto/releases/tag/0.98-beta
Use everything from that fix, except for the ShaderFixes folder. The AC3 ShaderFixes folder will still work with this latest code.
This latest code base fixes some requirements we had earlier, no need for KB platform update, and it works OK on 8.1 now. Your crashes are nearly sure to be one of those two problems.
Using that AC4 version, you can edit the .ini file to enable hunting=1, and it should work pretty well. You might need to also enable force_cpu_affinity=1 while hunting, as AC3 had a weird flickering shader when selected.
Let me know if that doesn't work for you.
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 wanna remove these white outlines around NPCs:
http://i.minus.com/ibwL6VOBJ5y9rK.png
I've done it for all the DX9 Assassins Creeds with Helix wrapper, now I'm trying to do it for the DX11 games :)
Well it doesn't crash anymore, but shader hunting doesn't seem to be working, nothing happens when I press the numpad keys. (I've set hunting=1)
Thanks for you help
1080 Ti - i7 5820k - 16Gb RAM - Win 10 version 1607 - ASUS VG236H (1920x1080@120Hz)
Since then I've also implemented constants, so we can make your change an optional setting via the .ini file.
I went ahead and tested it, to see how it works with the current codebase. It looks good to me.
Runs without crashing, shaderhunting was working OK for me. I did get the flicker on shaders, instead of blanking them, and had to set the affinity flag as well to make it searchable. (really hammers performance of course).
I also got to be reminded why I hate both Steam and UPlay now, because they both have to launch, and both want to put up overlays. All the people involved with this double DRM thing are evil, hateful people.
Did you disable the fake-3D with ctrl-alt-F11? I don't think shader hunting works in CM. That's all I can think of at the moment, the newer code base is simpler and much more compatible with all games.
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
So that's in development? Maybe I should just wait for that instead :P
1080 Ti - i7 5820k - 16Gb RAM - Win 10 version 1607 - ASUS VG236H (1920x1080@120Hz)
I used the AC4 dlls, and it worked well on AC3.
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
1.For this part:
Can't you just put
instead or is it necessary to create the r23 variable?
2. Something else new that I saw was that you guys straight up created a new variable to be exported. Here's the full code for the shader:
I'm talking about the "float4 v4 : TEXCOORD3" whose z parameter was used for the stereo fix. How did you know that that could help to fix the shader for 3d?
3. Can I assume that this line:
being converted to
is just manual decompiler fix or is it part of the 3d fix? I'm leaning on the decompiler fix side.
4. I'm really confused by this part of a fix:
that becomes:
Can you maybe give me a simple breakdown of one would arrive to this fix?
If my questions are annoying you bo3b/mike then just tell me so and I won't post any more. I'm just curious on how 3d fixes work.
Thanks.
Yep, you can do the simpler version. This is an artifact of copy and paste where early on we didn't quite understand how flexible HLSL is, and were using techniques that came from the ASM side, where you have to do it via temporary variables.
This fix is similar to the blood spatters in Alien, where the output itself needs to be unchanged, but we want to modify the follow-on uses of that variable to make it stereo.
This is actually fixing the problem in the corresponding PixelShader. The variable was added in the VertexShader associated with this effect, and is passing in the .z parameter as a specific matrix value to be used in the PixelShader. The VS had the proper matrix, the PS did not, so this is one way to pass that on where it's needed.
For whatever reason, this seems to work more often in DX11/HLSL than in the ASM versions. Sometimes it just doesn't work in ASM, and it's not clear why.
Yes, this is part of the back-and-forth that Mike and I do on fixes. Sometimes we find stuff that is broken because the Decompiler generated bad code, and I work out how to fix the code generation.
This one is actually the opposite, the unrolled version is actually wrong, the rolled up version is correct. We have some in-progress stuff that we don't bother to clean up, as long as we know it's working.
The unrolled version can do something like "r1.x = r1.x ? r2.x : r3.x", then in the next line, use r1.x again, and generate bad results. Since the output can possibly the test parameter, it's safer and generates the proper ASM to roll it back up. I hesitantly changed a bunch of these, because Chiri believes that they need to be unrolled, and wrote it that way originally. I've tested a lot of code, and am confident enough to leave them rolled up.
For the last part of the question, I'll leave that to Mike, as I don't know what it's doing either.
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 have the debug & unbuffered flags set to 1 and export_hlsl is set to 3. Now the game crashes immediately.
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
Regarding the last part... As bo3b notes we sometimes have artifacts of experimentation left in the code. If you work it through this code is exactly the same as just fixing the r0.xyzw variable, so I could not be bothered to put it back. There are a couple of shaders I found early that required one of the o1 or o2 variables to use the non-shifted r0, that's why I created the duplicate r20 variable. I then applied this fix to several other similar shaders, only to find that it screwed them up so I had to revert back. VS are much less consistent in their patterns than PS, so this happens a lot. On average though, autofixing and then correcting the few things that break is still far quicker and more efficient than individually tracking every shader down.
Regarding the v4 variable I pass in. You will see some VS in the shaderfixes that pass out a TEXCOORD3 derived entirely form the k_vFullViewPlane constant. I found out that the z component has the FOV correction factor that is needed when correcting in View Space (which is what happens in the PS) so I pass that forward. To start with I copied the struct into the PS and was using the k_vFullViewPlane variable from there - this worked for some shaders, but not all. For the ones that did not work, the value was either always 0 so no correction was applied, or it changed to zero at some view angles which led to shadow/light 'snapping'. Because of this, I reverted most of them to use the TEXCOORD3 passing approach. I have had other issues with this particular struct (b(12) actually) not having any values in the VS for the Particle fixes, so I am forced to use a hardcoded magic number that only works for one FOV (normal gameplay) and not the benchmark (higher fov) or when using the bow (lower fov).
Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278
OK, thanks for that log. This one has a single shader that decompiles OK, then crashes on the next one it sees.
This looks like a parse failure where it creates an exception, but that should have been caught by my exception handler and reported.
Do you have any debugging tools installed that might interfere with exception handling?
One last thing to try for me would be to set the affinity flag so that it runs mostly single threaded. This can help me tell if it might be some multi-threaded problem. Set all the flags to 1 in the Logging section, but especially force_cpu_affinity=1 for this. Thanks for the help.
Edit: BTW, this debug build is worth trying in this case, because it might catch the crash earlier with an Assert, and includes a multi-threading Decompiler patch we needed for Mordor crashes.
https://github.com/bo3b/3Dmigoto/releases/download/0.99.2-beta/3Dmigoto-Debug-0.99.2.zip
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
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
Once it decided to switch to DX9 the logging stops because there is no longer any DX9 hook in 3Dmigoto.
It might be the affinity flag that makes it think to switch to DX9, hard to say. Worth experimenting with force_cpu_affinity=0, but still use the debug version of 0.99.2.
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