In general to adjust a UI depth, you need to do something similar to this in the vertex shader:
[code]
def c220, 0, 1, 0.0625, 0.5 // Add the usual stereo constant definition
// ...
dcl_position o1 // Note which o* register is named in dcl_position
// ...
// Find where the output position register is set:
// dp4 o1.w, v0, c3
// dp4 o1.z, v0, c2
// dp4 o1.y, v0, c1
// dp4 o1.x, v0, c0
// And replace it with a free temporary register, e.g:
// (assuming r30 is not used elsewhere in this shader)
dp4 r30.w, v0, c3
dp4 r30.z, v0, c2
dp4 r30.y, v0, c1
dp4 r30.x, v0, c0
// ...
// Then at the end of the shader, add something like this
// In this case c200.z is Const3, which I use to allow it to be adjusted
// by keybindings in much the same way as we learned in lesson 3.
// 1.0 will be infinity, 0.0 will be screen depth, and you can choose
// any value between, or even negative values to pop out of the screen.
texldl r31, c220.z, s0 // r31.x = separation
mad r30.x, r31.x, c200.z, r30.x // X = X + separation * c200.z
// Copy the temporary register to the original output position register:
mov o1, r30
[/code]
You might run into issues where adjusting the depth also adjusts something you didn't want. I'm sure bo3b will cover this in more detail when the lesson is up, but here's a few examples from my fixes which you might be interested in looking at.
- In The Forest, 90% of the UI was already at a good depth, but a few HUD icons were at screen depth, so here I only do the depth adjustment if the original depth was equal to 1 (in some cases this might be 0 instead):
https://github.com/DarkStarSword/3d-fixes/blob/95efcbd69f9a4ad49e2285c81aafe6df5e7e2f8d/The%20Forest/ShaderOverride/VertexShaders/0DC90B2E.txt
- In The Book of Unwritten Tales 2, the UI depth adjustment had the unfortunate side-effect of moving text on the menu to the right, so for this shader I check the texture CRC and make sure I don't adjust it whenever the menu text is being drawn:
https://github.com/DarkStarSword/3d-fixes/blob/master/BoUT2/ShaderOverride/VertexShaders/0DC90B2E.txt
see also the bCalcTexCRCatStart = true and [VS10F9DBCC] section in the ini:
https://github.com/DarkStarSword/3d-fixes/blob/master/BoUT2/DX9Settings.ini
- I ran into a similar issue in World of Diving where a number of things moved to the right, however one particular texture proved impossible to track down (the CRC changed every time the game was launched). This last texture was only visible while the diving computer was on-screen while the tab key was being held, so here I disable it on blacklisted textures AND whenever the tab key is held:
https://github.com/DarkStarSword/3d-fixes/blob/master/World%20of%20Diving/ShaderOverride/VertexShaders/A8D32517.txt
- Things can get even more crazy. This shader from Montague's Mount affected part of the UI, the lens flare *AND* the halo around lights, the three of which need completely different things done. Here I check the texture to distinguish between UI and flare/halo, but the flares and halos use the same texture, so I test the depth to distinguish between them:
https://github.com/DarkStarSword/3d-fixes/blob/c8956ee23d6ad7518dd31b1bbe6c2467b10c158c/Montague%27s%20Mount/ShaderOverride/VertexShaders/CD61F9B3.txt
If you were particularly observant, you may have noticed the CRC for the UI shader in The Forest and The Book of Unwritten Tales 2 is identical. These two games are indeed using the same shader which is not a huge surprise given they use the same engine, however both required a slightly different fix depending on exactly what the game was doing and what side-effects arose.
dcl_position o1 // Note which o* register is named in dcl_position
// ...
// Find where the output position register is set:
// dp4 o1.w, v0, c3
// dp4 o1.z, v0, c2
// dp4 o1.y, v0, c1
// dp4 o1.x, v0, c0
// And replace it with a free temporary register, e.g:
// (assuming r30 is not used elsewhere in this shader)
dp4 r30.w, v0, c3
dp4 r30.z, v0, c2
dp4 r30.y, v0, c1
dp4 r30.x, v0, c0
// ...
// Then at the end of the shader, add something like this
// In this case c200.z is Const3, which I use to allow it to be adjusted
// by keybindings in much the same way as we learned in lesson 3.
// 1.0 will be infinity, 0.0 will be screen depth, and you can choose
// any value between, or even negative values to pop out of the screen.
texldl r31, c220.z, s0 // r31.x = separation
mad r30.x, r31.x, c200.z, r30.x // X = X + separation * c200.z
// Copy the temporary register to the original output position register:
mov o1, r30
You might run into issues where adjusting the depth also adjusts something you didn't want. I'm sure bo3b will cover this in more detail when the lesson is up, but here's a few examples from my fixes which you might be interested in looking at.
- I ran into a similar issue in World of Diving where a number of things moved to the right, however one particular texture proved impossible to track down (the CRC changed every time the game was launched). This last texture was only visible while the diving computer was on-screen while the tab key was being held, so here I disable it on blacklisted textures AND whenever the tab key is held:
https://github.com/DarkStarSword/3d-fixes/blob/master/World%20of%20Diving/ShaderOverride/VertexShaders/A8D32517.txt
If you were particularly observant, you may have noticed the CRC for the UI shader in The Forest and The Book of Unwritten Tales 2 is identical. These two games are indeed using the same shader which is not a huge surprise given they use the same engine, however both required a slightly different fix depending on exactly what the game was doing and what side-effects arose.
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="3d4dd"]BTW I did not use UseRenderedShaders = true as this causes the game to crash.[/quote]
I have found in many games I get crashes using that if I move the camera (e.g. by moving the mouse, or while in a cutscene) while a shader is disabled. In this case, pressing minus on the number pad will reset the shaders making moving the mouse/camera safe again. In Dreamfall Chapters I was usually able to use this trick (also - I discovered I could pause the game in cutscenes), however in particularly complex & dynamic scenes (such as Europolis) I would often get crashes even while not moving the camera (fortunately by that stage of the game I had fixed most of the shaders already).
[quote]Another interesting finding: I was hunting a shader for a HUD element that is unique to FF XIII-2 and doesn't share the VS for the other ones. Cycling through the shaders I got the following result:
Shader # 453 CRC 77704446 => HUD element visible
Shader # 454 CRC 77704446 => HUD element disabled
Shader # 455 CRC 77704446 => HUD element visible
So there are shaders with different numbers but the same CRC and only one disables the HUD element...?[/quote]
This almost always means that the same shader has been used for multiple different things in the scene. Often they are all broken and the one fix will help all of them, but occasionally you may need a way to distinguish between them to only apply the fix to some instances, such as I did above to check the texture CRC or depth. Helix mod can also distinguish them by adding an index to the filename, but I'm not sure how well that works in practice. There is a small possibility of a hash collision leading to two completely different shaders to have the same CRC, but it should be quite rare and not something I'd worry about unless you actually run into it.
[quote]The shader is the same I had to modify to remove a halo issue with some fog. It might be possible that the HUD element and the fog share the same VS as the PS that disables the HUD also affects the fog.[/quote]
What often happens here is that two distinct shaders (from the developer's point of view) have compiled to the exact same assembly and have the same checksum, so Helix mod cannot distinguish between them. If you only need to fix one and doing so breaks the other, you need to find some other way to distinguish between them. In this case I'd suggest trying the depth since there is a reasonable chance that whenever the depth is 1 it will be a UI element, otherwise it will be fog. If that doesn't work you may need to test something else, like the texture being used.
[quote]Another observation was the fact that a VS that was disabled with the debug.dll while the game was running only affected Mogry (a little monster) but no human characters. When the same shader was placed in the override folder also parts of human characters were missing when the game was started.
[/quote]
This will be another case of the above - the same shader is used for multiple items, and when running through with the debug dll it can disable each instance individually, but when the shader is used from ShaderOverride it will affect all instances using that same shader unless you can distinguish between them.
3d4dd said:BTW I did not use UseRenderedShaders = true as this causes the game to crash.
I have found in many games I get crashes using that if I move the camera (e.g. by moving the mouse, or while in a cutscene) while a shader is disabled. In this case, pressing minus on the number pad will reset the shaders making moving the mouse/camera safe again. In Dreamfall Chapters I was usually able to use this trick (also - I discovered I could pause the game in cutscenes), however in particularly complex & dynamic scenes (such as Europolis) I would often get crashes even while not moving the camera (fortunately by that stage of the game I had fixed most of the shaders already).
Another interesting finding: I was hunting a shader for a HUD element that is unique to FF XIII-2 and doesn't share the VS for the other ones. Cycling through the shaders I got the following result:
Shader # 453 CRC 77704446 => HUD element visible
Shader # 454 CRC 77704446 => HUD element disabled
Shader # 455 CRC 77704446 => HUD element visible
So there are shaders with different numbers but the same CRC and only one disables the HUD element...?
This almost always means that the same shader has been used for multiple different things in the scene. Often they are all broken and the one fix will help all of them, but occasionally you may need a way to distinguish between them to only apply the fix to some instances, such as I did above to check the texture CRC or depth. Helix mod can also distinguish them by adding an index to the filename, but I'm not sure how well that works in practice. There is a small possibility of a hash collision leading to two completely different shaders to have the same CRC, but it should be quite rare and not something I'd worry about unless you actually run into it.
The shader is the same I had to modify to remove a halo issue with some fog. It might be possible that the HUD element and the fog share the same VS as the PS that disables the HUD also affects the fog.
What often happens here is that two distinct shaders (from the developer's point of view) have compiled to the exact same assembly and have the same checksum, so Helix mod cannot distinguish between them. If you only need to fix one and doing so breaks the other, you need to find some other way to distinguish between them. In this case I'd suggest trying the depth since there is a reasonable chance that whenever the depth is 1 it will be a UI element, otherwise it will be fog. If that doesn't work you may need to test something else, like the texture being used.
Another observation was the fact that a VS that was disabled with the debug.dll while the game was running only affected Mogry (a little monster) but no human characters. When the same shader was placed in the override folder also parts of human characters were missing when the game was started.
This will be another case of the above - the same shader is used for multiple items, and when running through with the debug dll it can disable each instance individually, but when the shader is used from ShaderOverride it will affect all instances using that same shader unless you can distinguish between them.
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: Awesome summary. I don't have anything to add to your description.
I added your cool find of NumPad- for game crashes to the gotchas list on Helix docs. Thanks!
@DarkStarSword: Thank You for Your excellent explanations! Indeed I already had a look at Your fix for The Forest and World of Diving before I asked my question ;) My problem is that I can't find that pattern with
dp4 o1.w, v0, c3
dp4 o1.z, v0, c2
dp4 o1.y, v0, c1
dp4 o1.x, v0, c0
in any of the VS I got when hunting the HUD shaders. Now I will try to find it by searching the dumpall folder. What is specific for this pattern? I guess that o1 could also be o0, o2, etc. Same with v0. And that there are other c than c0-c3? Is it characteristic that You have the same o with .w, .z, .y, .x and allways the same v? And I guess that there could be a r instead of o, v, c?
I will also try NumPad-. It is really annoying to have to cycle through 1000 shader when there are only 100 used.
Regarding fixes for cutscenes: in FF XIII(-2) You also can pause cutscenes but unfortunately cycling through the shaders has no effect when the scenery is frozen this way. And cycling through over hundred shader in realtime when the issue is only visible for 1-2 sec is impossible. But I have found another solution: I discovered that the shaders to fix halo issues in FF XIII are very similar (similar parameters used, similar complexity/file size). So I have searched the dumpall folder of FF XIII-2 for these pattern and added the prime directive fix to them "on spec". And indeed now the fog issues in cutscenes disappeared. Which raises another question: there are many fog effects in the game that work out of the box without a fix. Can I ruin these shaders when I ad the prime directive to them or does it simply has no effect then?
@DarkStarSword: Thank You for Your excellent explanations! Indeed I already had a look at Your fix for The Forest and World of Diving before I asked my question ;) My problem is that I can't find that pattern with
dp4 o1.w, v0, c3
dp4 o1.z, v0, c2
dp4 o1.y, v0, c1
dp4 o1.x, v0, c0
in any of the VS I got when hunting the HUD shaders. Now I will try to find it by searching the dumpall folder. What is specific for this pattern? I guess that o1 could also be o0, o2, etc. Same with v0. And that there are other c than c0-c3? Is it characteristic that You have the same o with .w, .z, .y, .x and allways the same v? And I guess that there could be a r instead of o, v, c?
I will also try NumPad-. It is really annoying to have to cycle through 1000 shader when there are only 100 used.
Regarding fixes for cutscenes: in FF XIII(-2) You also can pause cutscenes but unfortunately cycling through the shaders has no effect when the scenery is frozen this way. And cycling through over hundred shader in realtime when the issue is only visible for 1-2 sec is impossible. But I have found another solution: I discovered that the shaders to fix halo issues in FF XIII are very similar (similar parameters used, similar complexity/file size). So I have searched the dumpall folder of FF XIII-2 for these pattern and added the prime directive fix to them "on spec". And indeed now the fog issues in cutscenes disappeared. Which raises another question: there are many fog effects in the game that work out of the box without a fix. Can I ruin these shaders when I ad the prime directive to them or does it simply has no effect then?
My original display name is 3d4dd - for some reason Nvidia changed it..?!
[quote="3d4dd"]@DarkStarSword: Thank You for Your excellent explanations! Indeed I already had a look at Your fix for The Forest and World of Diving before I asked my question ;) My problem is that I can't find that pattern with
dp4 o1.w, v0, c3
dp4 o1.z, v0, c2
dp4 o1.y, v0, c1
dp4 o1.x, v0, c0
in any of the VS I got when hunting the shaders. Now I will try to find it by searching the dumpall folder.[/quote]For a UI depth adjustment you don't need to look for any particular pattern so long as you can identify the vertex shader. I just grabbed that as an example, but the important part was just the use of the o* register that matched the dcl_position o* declaration at the top of the shader.
That pattern of four dp4 instructions with four sequentially numbered constant registers (not necessarily in order) will become very important to look out for in more advanced fixes (such as shadow fixes) - it is one of two patterns that signify a matrix multiply where the shader is transforming from one coordinate system into another (I don't recall the other pattern off the top of my head, only that it involved mul and add instructions and is used when a matrix is stored in row-major order).
That particular UI shader is clearly multiplying the input coordinates by a matrix, but it's also quite common for a UI shader to pass the coordinates straight through without transforming them, in which case you won't see that pattern. You might see a mov, mul, add or maybe even something else - the only thing you need to look out for in a UI shader is the output position register.
[quote]I will also try NumPad-. It is really annoying to have to cycle through 1000 shader when there are only 100 used.[/quote]Yeah, definitely :)
[quote]Regarding fixes for cutscenes: in FF XIII(-2) You also can pause cutscenes but unfortunately cycling through the shaders has no effect when the scenery is frozen this way. And cycling through over hundred shader in realtime when the issue is only visible for 1-2 sec is impossible.[/quote]That's unfortunate :( I've seen some games take a screenshot when they are paused and then display that instead of rendering the game, which might be what is happening here. Unfortunately in this case the pause trick won't work.
[quote]But I have found another solution: I discovered that the shaders to fix halo issues in FF XII are very similar (similar parameters used, similar complexity/file size). So I have searched the dumpall folder for these pattern and added the prime directive fix to them "on spec". And indeed now the fog issues in cutscenes disappeared.[/quote]That's great :)
I've used a similar approach to pre-emptively fix lighting shaders in Unity games once I had worked out the pattern to fix them, so I didn't have to keep tracking down each individual one as I came across them.
[quote]Which raises another question: there are many fog effects in the game that work out of the box without a fix. Can I ruin these shaders when I ad the prime directive to them or does it simply has no effect then?[/quote]Potentially yes, applying a fix to something that was working may break it, but other times it might be ok. You might have to make a judgement call on whether it's worth the risk or not, and whether it's going to save you time to do the pre-emptive fix and then manually fix up anything that broke. I've started doing this with Unity games, since every surface shader is broken in much the same way - in The Forest I've only had to manually fix one shader that broke after the auto fix (this is why I was able to do the first version of that fix in a day, despite it having so many broken shaders).
I'd suggest leaving a comment in the shader that you can search for so you know which ones are possible culprits in case something does break (if you've seen any of the shaders I've used my shadertool.py to fix you may have noticed that it inserts a comment with the command line I ran it with, and this is the reason I made it do that).
Another risk with a pre-emptive fix is making an error in a shader and breaking it, but not being able to check since you don't know where it was actually used. Be sure to check the LOG.txt for any errors, especially if anything weird starts happening (like effects disappearing or changing in bizarre inexplicable ways when reloading shaders with F10).
3d4dd said:@DarkStarSword: Thank You for Your excellent explanations! Indeed I already had a look at Your fix for The Forest and World of Diving before I asked my question ;) My problem is that I can't find that pattern with
dp4 o1.w, v0, c3
dp4 o1.z, v0, c2
dp4 o1.y, v0, c1
dp4 o1.x, v0, c0
in any of the VS I got when hunting the shaders. Now I will try to find it by searching the dumpall folder.
For a UI depth adjustment you don't need to look for any particular pattern so long as you can identify the vertex shader. I just grabbed that as an example, but the important part was just the use of the o* register that matched the dcl_position o* declaration at the top of the shader.
That pattern of four dp4 instructions with four sequentially numbered constant registers (not necessarily in order) will become very important to look out for in more advanced fixes (such as shadow fixes) - it is one of two patterns that signify a matrix multiply where the shader is transforming from one coordinate system into another (I don't recall the other pattern off the top of my head, only that it involved mul and add instructions and is used when a matrix is stored in row-major order).
That particular UI shader is clearly multiplying the input coordinates by a matrix, but it's also quite common for a UI shader to pass the coordinates straight through without transforming them, in which case you won't see that pattern. You might see a mov, mul, add or maybe even something else - the only thing you need to look out for in a UI shader is the output position register.
I will also try NumPad-. It is really annoying to have to cycle through 1000 shader when there are only 100 used.
Yeah, definitely :)
Regarding fixes for cutscenes: in FF XIII(-2) You also can pause cutscenes but unfortunately cycling through the shaders has no effect when the scenery is frozen this way. And cycling through over hundred shader in realtime when the issue is only visible for 1-2 sec is impossible.
That's unfortunate :( I've seen some games take a screenshot when they are paused and then display that instead of rendering the game, which might be what is happening here. Unfortunately in this case the pause trick won't work.
But I have found another solution: I discovered that the shaders to fix halo issues in FF XII are very similar (similar parameters used, similar complexity/file size). So I have searched the dumpall folder for these pattern and added the prime directive fix to them "on spec". And indeed now the fog issues in cutscenes disappeared.
That's great :)
I've used a similar approach to pre-emptively fix lighting shaders in Unity games once I had worked out the pattern to fix them, so I didn't have to keep tracking down each individual one as I came across them.
Which raises another question: there are many fog effects in the game that work out of the box without a fix. Can I ruin these shaders when I ad the prime directive to them or does it simply has no effect then?
Potentially yes, applying a fix to something that was working may break it, but other times it might be ok. You might have to make a judgement call on whether it's worth the risk or not, and whether it's going to save you time to do the pre-emptive fix and then manually fix up anything that broke. I've started doing this with Unity games, since every surface shader is broken in much the same way - in The Forest I've only had to manually fix one shader that broke after the auto fix (this is why I was able to do the first version of that fix in a day, despite it having so many broken shaders).
I'd suggest leaving a comment in the shader that you can search for so you know which ones are possible culprits in case something does break (if you've seen any of the shaders I've used my shadertool.py to fix you may have noticed that it inserts a comment with the command line I ran it with, and this is the reason I made it do that).
Another risk with a pre-emptive fix is making an error in a shader and breaking it, but not being able to check since you don't know where it was actually used. Be sure to check the LOG.txt for any errors, especially if anything weird starts happening (like effects disappearing or changing in bizarre inexplicable ways when reloading shaders with F10).
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
Thank You again for Your help! So I didn't search for a matrix code but took a second look at the HUD and menu shaders I have hunted. I had already tried to use the formula X = X + separation * constant on their dcl_position o* but this had no effect on the depth. Only in the shader for the quest marker icon and several fog effects (77704446) I could observe a change for the depth of the marker (and also unwanted side effects on the fog...). But the marker had not a constant depth to the screen as I expected but changed it's depth depending on the distance to the marked object. So I just tried to use the prime directive formula (Xnew = Xold + Separation * (W - Convergence)) on the dcl_position o* and voila: the marker not only had depth but even was placed correctly on the object :) So I used the prime directive formula also on the other HUD elements and menus and they all were pushed to a (fixed) depth and now look exactly as the menus in FF XIII. Their depth is always the same regardless which convergence I use. It would be nice if it also would adapt to the actual convergence settings... But now it is more important to separate the quest marker from the many other elements the shader (77704446) is used for (fog, glow effects, subtitels for the intro video, etc.). I hope I can manage this by using texture CRC. I will study Your fix for The Book of Unwritten Tales 2.
Unfortunately I could not find a way to fix the position of 2D speech bubbles icons on characters You can talk to. As soon as I place the correspondent shader in the override folder the icons disappear - even when I use the original shader without any changes.
Thank You again for Your help! So I didn't search for a matrix code but took a second look at the HUD and menu shaders I have hunted. I had already tried to use the formula X = X + separation * constant on their dcl_position o* but this had no effect on the depth. Only in the shader for the quest marker icon and several fog effects (77704446) I could observe a change for the depth of the marker (and also unwanted side effects on the fog...). But the marker had not a constant depth to the screen as I expected but changed it's depth depending on the distance to the marked object. So I just tried to use the prime directive formula (Xnew = Xold + Separation * (W - Convergence)) on the dcl_position o* and voila: the marker not only had depth but even was placed correctly on the object :) So I used the prime directive formula also on the other HUD elements and menus and they all were pushed to a (fixed) depth and now look exactly as the menus in FF XIII. Their depth is always the same regardless which convergence I use. It would be nice if it also would adapt to the actual convergence settings... But now it is more important to separate the quest marker from the many other elements the shader (77704446) is used for (fog, glow effects, subtitels for the intro video, etc.). I hope I can manage this by using texture CRC. I will study Your fix for The Book of Unwritten Tales 2.
Unfortunately I could not find a way to fix the position of 2D speech bubbles icons on characters You can talk to. As soon as I place the correspondent shader in the override folder the icons disappear - even when I use the original shader without any changes.
My original display name is 3d4dd - for some reason Nvidia changed it..?!
[quote="3d4dd"]Thank You again for Your help! So I didn't search for a matrix code but took a second look at the HUD and menu shaders I have hunted. I had already tried to use the formula X = X + separation * constant on their dcl_position o* but this had no effect on the depth.[/quote]Interesting. If these are the right shaders I would have expected some movement when the constant is non-zero. I often start with a template DX9Settings.ini with the number row keys set up to adjust Const3 to any value between 0.0 and 1.0 in 0.1 increments so I can use it in UI shaders and adjust it on the fly. It might be worth checking the LOG.txt to make sure they don't have any errors, but it sounds like you were able to get them working.
[quote]Only in the shader for the quest marker icon and several fog effects (77704446) I could observe a change for the depth of the marker (and also unwanted side effects on the fog...). But the marker had not a constant depth to the screen as I expected but changed it's depth depending on the distance to the marked object. So I just tried to use the prime directive formula (Xnew = Xold + Separation * (W - Convergence)) on the dcl_position o* and voila: the marker not only had depth but even was placed correctly on the object :)[/quote]Curious - I wonder if the driver's heuristics were deciding not to stereoise them for some reason? Anyway, glad you were able to fix it :)
[quote]So I used the prime directive formula also on the other HUD elements and menus and they all were pushed to a (fixed) depth and now look exactly as the menus in FF XIII. Their depth is always the same regardless which convergence I use. It would be nice if it also would adapt to the actual convergence settings... But now it is more important to separate the quest marker from the many other elements the shader (77704446) is used for (fog, glow effects, subtitels for the intro video, etc.). I hope I can manage this by using texture CRC. I will study Your fix for The Book of Unwritten Tales 2.[/quote]To get started hunting for texture CRCs, you need bCalcTexCRCatStart = true in the ini. The up/down arrow keys will cycle textures by default, but you can change them with PrevTexKey and NextTexKey if they interfere with the game.
For the most part textures will go black while they are disabled (so I'm not sure how to hunt a texture that is already black :-/), and once you have found the right one you should write down the CRC displayed in the red text (if they are shorter than 8 characters, pad them with zeros in the same way we do for shaders).
You will need to add a section similar to the following to the ini file:
[code]
[VS77704446]
CheckTexCRC = true
ValForDefined = 1
ValNotDefined = 0
TexCounterReg = 251
UseDefinedOnly = false
DefinedTexturesVS = 01234567;89ABCDEF;
[/code]
The DefinedTexturesVS list needs to be filled out with the texture CRCs you found. You have two choices - you either need to list all the textures where you [b]DO[/b] want the depth adjustment to be enabled (whitelisting), or list those where you [b]DON'T[/b] want the adjustment to be enabled (blacklisting), but [b]not both[/b]. If you can only find textures for some of the effects that might force your decision, or if you find that one way would require you to keep finding more and more textures it might be easier to go the other way (e.g. for a while in Dreamfall Chapters I was whitelisting every texture used on an inventory object, but that didn't seem smart as I'd have to keep finding more and more textures, so I blacklisted the inventory background instead).
It's probably worthwhile leaving a comment in the ini with what CRC corresponds with what. It's also a good idea to leave a comment for the textures you didn't inlcude in the DefiendTexturesVS list as well, so if find you need to invert the test later on you don't have to hunt them all again.
In the shader you will be able to determine if the texture was in the list or not by testing the x component of the constant register defined by TexCounterReg (c251.x in this example). If it is in the list, it will have the value in ValForDefined (1.0 in this example), otherwise it will have the value defined by ValNotDefined (0.0 in this example). (be aware, some of my fixes have ValNotDefined=1 and ValForDefined=0 so the tests in the assembly are also the other way - I don't really have a good reason for doing it this way).
Then, in the shader you add an if_eq around the stereo adjustment, something like:
[code]
def c220, 0, 1, 0.0625, 0.5 // Added a 0 and 1 in .x and .y of this constant
// ...
// We can't use two constant registers in the same instruction, so copy
// TexCounterReg to a temporary register first:
mov r29.x, c251.x
// Test if the texture is whitelisted if TexCounterReg.x == ValForDefined
// For blacklisting, check if TexCounterReg.x == ValNotDefined instead
if_eq r29.x, c220.y
// Whatever needs to be conditional, e.g. a UI depth adjustment:
texldl r31, c220.z, s0
mad r30.x, r31.x, c200.z, r30.x
endif
// Anything that needs to always happen, e.g. copying the temporary position
// register to the output position register:
mov o1, r30
[/code]
[quote]Unfortunately I could not find a way to fix the position of 2D speech bubbles icons on characters You can talk to. As soon as I place the correspondent shader in the override folder the icons disappear - even when I use the original shader without any changes.[/quote]Check the LOG.txt for any errors relating to them. Are these vs_3_0 shaders, or a different version? If they are not vs_3_0 you may need to convert them to shader model 3, which you can do by hand, or automatically with Mana's tool:
http://helixmod.blogspot.com.au/2013/05/vs11vs20-vs30-converter.html
If you check out my 3d-fixes repository (either using git, or just hitting download zip on github) and install Python 3 you can also use my shadertool.py script to convert them to shader model 3 automatically, which handles a few cases better (official announcement coming when it's a bit more polished). Run it with -i on a shader to copy it to the ShaderOverride directory and automatically convert it, use --help to see the rest of the options it supports.
3d4dd said:Thank You again for Your help! So I didn't search for a matrix code but took a second look at the HUD and menu shaders I have hunted. I had already tried to use the formula X = X + separation * constant on their dcl_position o* but this had no effect on the depth.
Interesting. If these are the right shaders I would have expected some movement when the constant is non-zero. I often start with a template DX9Settings.ini with the number row keys set up to adjust Const3 to any value between 0.0 and 1.0 in 0.1 increments so I can use it in UI shaders and adjust it on the fly. It might be worth checking the LOG.txt to make sure they don't have any errors, but it sounds like you were able to get them working.
Only in the shader for the quest marker icon and several fog effects (77704446) I could observe a change for the depth of the marker (and also unwanted side effects on the fog...). But the marker had not a constant depth to the screen as I expected but changed it's depth depending on the distance to the marked object. So I just tried to use the prime directive formula (Xnew = Xold + Separation * (W - Convergence)) on the dcl_position o* and voila: the marker not only had depth but even was placed correctly on the object :)
Curious - I wonder if the driver's heuristics were deciding not to stereoise them for some reason? Anyway, glad you were able to fix it :)
So I used the prime directive formula also on the other HUD elements and menus and they all were pushed to a (fixed) depth and now look exactly as the menus in FF XIII. Their depth is always the same regardless which convergence I use. It would be nice if it also would adapt to the actual convergence settings... But now it is more important to separate the quest marker from the many other elements the shader (77704446) is used for (fog, glow effects, subtitels for the intro video, etc.). I hope I can manage this by using texture CRC. I will study Your fix for The Book of Unwritten Tales 2.
To get started hunting for texture CRCs, you need bCalcTexCRCatStart = true in the ini. The up/down arrow keys will cycle textures by default, but you can change them with PrevTexKey and NextTexKey if they interfere with the game.
For the most part textures will go black while they are disabled (so I'm not sure how to hunt a texture that is already black :-/), and once you have found the right one you should write down the CRC displayed in the red text (if they are shorter than 8 characters, pad them with zeros in the same way we do for shaders).
You will need to add a section similar to the following to the ini file:
The DefinedTexturesVS list needs to be filled out with the texture CRCs you found. You have two choices - you either need to list all the textures where you DO want the depth adjustment to be enabled (whitelisting), or list those where you DON'T want the adjustment to be enabled (blacklisting), but not both. If you can only find textures for some of the effects that might force your decision, or if you find that one way would require you to keep finding more and more textures it might be easier to go the other way (e.g. for a while in Dreamfall Chapters I was whitelisting every texture used on an inventory object, but that didn't seem smart as I'd have to keep finding more and more textures, so I blacklisted the inventory background instead).
It's probably worthwhile leaving a comment in the ini with what CRC corresponds with what. It's also a good idea to leave a comment for the textures you didn't inlcude in the DefiendTexturesVS list as well, so if find you need to invert the test later on you don't have to hunt them all again.
In the shader you will be able to determine if the texture was in the list or not by testing the x component of the constant register defined by TexCounterReg (c251.x in this example). If it is in the list, it will have the value in ValForDefined (1.0 in this example), otherwise it will have the value defined by ValNotDefined (0.0 in this example). (be aware, some of my fixes have ValNotDefined=1 and ValForDefined=0 so the tests in the assembly are also the other way - I don't really have a good reason for doing it this way).
Then, in the shader you add an if_eq around the stereo adjustment, something like:
def c220, 0, 1, 0.0625, 0.5 // Added a 0 and 1 in .x and .y of this constant
// ...
// We can't use two constant registers in the same instruction, so copy
// TexCounterReg to a temporary register first:
mov r29.x, c251.x
// Test if the texture is whitelisted if TexCounterReg.x == ValForDefined
// For blacklisting, check if TexCounterReg.x == ValNotDefined instead
if_eq r29.x, c220.y
// Whatever needs to be conditional, e.g. a UI depth adjustment:
texldl r31, c220.z, s0
mad r30.x, r31.x, c200.z, r30.x
endif
// Anything that needs to always happen, e.g. copying the temporary position
// register to the output position register:
mov o1, r30
Unfortunately I could not find a way to fix the position of 2D speech bubbles icons on characters You can talk to. As soon as I place the correspondent shader in the override folder the icons disappear - even when I use the original shader without any changes.
Check the LOG.txt for any errors relating to them. Are these vs_3_0 shaders, or a different version? If they are not vs_3_0 you may need to convert them to shader model 3, which you can do by hand, or automatically with Mana's tool:
http://helixmod.blogspot.com.au/2013/05/vs11vs20-vs30-converter.html
If you check out my 3d-fixes repository (either using git, or just hitting download zip on github) and install Python 3 you can also use my shadertool.py script to convert them to shader model 3 automatically, which handles a few cases better (official announcement coming when it's a bit more polished). Run it with -i on a shader to copy it to the ShaderOverride directory and automatically convert it, use --help to see the rest of the options it supports.
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"]Curious - I wonder if the driver's heuristics were deciding not to stereoise them for some reason? Anyway, glad you were able to fix it :)
[/quote]
I also got the feeling that the HUD and menus are not 2D objects but originally have some depth. As mentioned above all the HUD elements and menus in FF XIII were pushed to depth out of the box. And now that I have used the prime directive on FF XIII-2 they look the same as in FF XIII.
Thank You for Your detailed instructions regarding the texture CRCs! I have used it on the quest marker and it worked - most of the time. Under certain circumstances (distance to object, viewing angle) the texture recognition doesn't seem to work and the marker gets 2D again. I have used bCalcTexCRCatStart = true and hunted the CRC in these situations but the displayed CRC is always the same. Are the routines for texture hunting and texture identification within the shaders different?
BTW is there a way to determine the texture CRC also for PS? I couldn't find DefinedTexturesPS...
In some situations I also use the convergence as a trigger. I will make different presets (exploration, 3D-cutscenes, 2D-cutscenes etc.) and a special one that will be used when the game starts and the crystarium is used. This offers the best depth values for menu elements and the background and solves the problem that most of the shaders for menus, videos and backgrounds also affect other elements as fog during the gameplay. As it is not possible to find a CRC for a video I use the preset as trigger to determine if the user is actually in the start menu or playing.
[quote="DarkStarSword"]Check the LOG.txt for any errors relating to them. Are these vs_3_0 shaders, or a different version?[/quote]
The log says:
[code]CreateVertexShader CRC: 0xFA9322CC
pD3DXAssembleShaderFromFile
Shader overrode CRC: 0xFA9322CC
luaL_openlibs
luaL_loadfile cannot open PSscript.lua: No such file or directory [/code]
Which is the usual report I guess. The shader is a normal vs_3_0. Nethertheless as soon as it is in the override folder (even without any modifications) the speech bubbles disappear. So I can't fix their depth. As a workaround I want to offer a hotkey to blend out and blend in the 2D speech bubbles using the PS. As the PS also is connected to other elements that should be visible in the crystarium it would be nice if I could use texture CRCs also for the PS.
Anyway it is quite astonishing (and annoying) to see how many completely different aspects of the game are controlled by only one shader. An extreme example is VS 77704446 which seems to be responsible for every second issue I find in the game...
DarkStarSword said:Curious - I wonder if the driver's heuristics were deciding not to stereoise them for some reason? Anyway, glad you were able to fix it :)
I also got the feeling that the HUD and menus are not 2D objects but originally have some depth. As mentioned above all the HUD elements and menus in FF XIII were pushed to depth out of the box. And now that I have used the prime directive on FF XIII-2 they look the same as in FF XIII.
Thank You for Your detailed instructions regarding the texture CRCs! I have used it on the quest marker and it worked - most of the time. Under certain circumstances (distance to object, viewing angle) the texture recognition doesn't seem to work and the marker gets 2D again. I have used bCalcTexCRCatStart = true and hunted the CRC in these situations but the displayed CRC is always the same. Are the routines for texture hunting and texture identification within the shaders different?
BTW is there a way to determine the texture CRC also for PS? I couldn't find DefinedTexturesPS...
In some situations I also use the convergence as a trigger. I will make different presets (exploration, 3D-cutscenes, 2D-cutscenes etc.) and a special one that will be used when the game starts and the crystarium is used. This offers the best depth values for menu elements and the background and solves the problem that most of the shaders for menus, videos and backgrounds also affect other elements as fog during the gameplay. As it is not possible to find a CRC for a video I use the preset as trigger to determine if the user is actually in the start menu or playing.
DarkStarSword said:Check the LOG.txt for any errors relating to them. Are these vs_3_0 shaders, or a different version?
The log says:
CreateVertexShader CRC: 0xFA9322CC
pD3DXAssembleShaderFromFile
Shader overrode CRC: 0xFA9322CC
luaL_openlibs
luaL_loadfile cannot open PSscript.lua: No such file or directory
Which is the usual report I guess. The shader is a normal vs_3_0. Nethertheless as soon as it is in the override folder (even without any modifications) the speech bubbles disappear. So I can't fix their depth. As a workaround I want to offer a hotkey to blend out and blend in the 2D speech bubbles using the PS. As the PS also is connected to other elements that should be visible in the crystarium it would be nice if I could use texture CRCs also for the PS.
Anyway it is quite astonishing (and annoying) to see how many completely different aspects of the game are controlled by only one shader. An extreme example is VS 77704446 which seems to be responsible for every second issue I find in the game...
My original display name is 3d4dd - for some reason Nvidia changed it..?!
[quote="3d4dd"]I have used it on the quest marker and it worked - most of the time. Under certain circumstances (distance to object, viewing angle) the texture recognition doesn't seem to work and the marker gets 2D again. I have used bCalcTexCRCatStart = true and hunted the CRC in these situations but the displayed CRC is always the same. Are the routines for texture hunting and texture identification within the shaders different?[/quote]Hmmm, that's a problem. I'm not sure what would be happening there and this isn't something I've run into, but given distance is a factor I'm [i]guessing[/i] mip-maps might be the culprit here - does the marker get smaller when it's further, or just deeper?
The CRC that helix mod displays in the red text is calculated when the texture is first created, but that does not get updated if the texture is altered later (which I believe is why I can't track down one texture in World of Diving). The CRCs that the shaders check for are calculated when the shader is actually used, so if the texture has changed it won't match, and it wouldn't surprise me at all if a mip-map causes a similar issue.
If this is the case there are a few things you might try, but I have no idea if any of these will work:
- You can try inverting the test and blacklisting the CRCs of the fog instead
- You might try setting CalcTexCRCatUpdate = true (which is used in the UpdateTexture() DirectX call) and seeing if you get a different CRC when hunting after the marker goes 2D
- You might try setting ResetCRCatReload = true (which is used in the GetSurfaceLevel() and LockRect() DirectX calls) and seeing if you get a different CRC when hunting after the marker goes 2D
- You might try pressing the button defined by ReloadTexturesListKey (defaults to F8). I'm not really sure what this does.
- You might try the alternate method to get texture CRCs, which is by pressing the button defined by SaveTextureLogKey (defaults to F12) while the marker is 2D. If you get a crash you will either need to change this to a different button, change the screenshot button in Steam, or disable the Steam overlay by removing GameOverlayRenderer.dll after launching Steam (the screenshot function in Steam seems to have a conflict with recent versions of Helix mod). In theory this will give you a TEXTURELOG.txt which will give you the CRCs the shader saw, however it has never worked for me and I have always ended up with log file that listed BeginScene and EndScene, but nothing else.
[quote]BTW is there a way to determine the texture CRC also for PS? I couldn't find DefinedTexturesPS...[/quote]Yes, DefinedTexturesPS is correct and can be used in PSnnnnnnnn sections in the ini. From my analysis of the DLL the VSnnnnnnnn and PSnnnnnnnn sections share a common code path for parsing, so they support most of the same settings as each other, but with VS in any setting name changed to PS for pixel shaders.
[quote]The log says:
<snip>
Which is the usual report I guess. The shader is a normal vs_3_0. Nethertheless as soon as it is in the override folder (even without any modifications) the speech bubbles disappear.[/quote]Yep, that log looks normal. I'm not sure what would be happening here... do they have a preshader section by any chance? Maybe post the complete shader in a [code] block and we can try to spot anything that may be causing an issue.
[quote]So I can't fix their depth. As a workaround I want to offer a hotkey to blend out and blend in the 2D speech bubbles using the PS. As the PS also is connected to other elements that should be visible in the crystarium it would be nice if I could use texture CRCs also for the PS.[/quote]Worth a shot - as above you should be able to use DefinedTexturesPS for this.
[quote]Anyway it is quite astonishing (and annoying) to see how many completely different aspects of the game are controlled by only one shader. An extreme example is VS 77704446 which seems to be responsible for every second issue I find in the game...[/quote]I know the feeling. It sounds like you have run into a pretty extreme case of this. Would I be correct in guessing that 77704446 is a fairly simple shader? It tends to be that the simpler shaders (particularly vertex shaders) are more likely to have this issue as multiple high level effects may all use a similar vertex shaders that compile to the same assembly if they do most of their processing in the pixel shader.
3d4dd said:I have used it on the quest marker and it worked - most of the time. Under certain circumstances (distance to object, viewing angle) the texture recognition doesn't seem to work and the marker gets 2D again. I have used bCalcTexCRCatStart = true and hunted the CRC in these situations but the displayed CRC is always the same. Are the routines for texture hunting and texture identification within the shaders different?
Hmmm, that's a problem. I'm not sure what would be happening there and this isn't something I've run into, but given distance is a factor I'm guessing mip-maps might be the culprit here - does the marker get smaller when it's further, or just deeper?
The CRC that helix mod displays in the red text is calculated when the texture is first created, but that does not get updated if the texture is altered later (which I believe is why I can't track down one texture in World of Diving). The CRCs that the shaders check for are calculated when the shader is actually used, so if the texture has changed it won't match, and it wouldn't surprise me at all if a mip-map causes a similar issue.
If this is the case there are a few things you might try, but I have no idea if any of these will work:
- You can try inverting the test and blacklisting the CRCs of the fog instead
- You might try setting CalcTexCRCatUpdate = true (which is used in the UpdateTexture() DirectX call) and seeing if you get a different CRC when hunting after the marker goes 2D
- You might try setting ResetCRCatReload = true (which is used in the GetSurfaceLevel() and LockRect() DirectX calls) and seeing if you get a different CRC when hunting after the marker goes 2D
- You might try pressing the button defined by ReloadTexturesListKey (defaults to F8). I'm not really sure what this does.
- You might try the alternate method to get texture CRCs, which is by pressing the button defined by SaveTextureLogKey (defaults to F12) while the marker is 2D. If you get a crash you will either need to change this to a different button, change the screenshot button in Steam, or disable the Steam overlay by removing GameOverlayRenderer.dll after launching Steam (the screenshot function in Steam seems to have a conflict with recent versions of Helix mod). In theory this will give you a TEXTURELOG.txt which will give you the CRCs the shader saw, however it has never worked for me and I have always ended up with log file that listed BeginScene and EndScene, but nothing else.
BTW is there a way to determine the texture CRC also for PS? I couldn't find DefinedTexturesPS...
Yes, DefinedTexturesPS is correct and can be used in PSnnnnnnnn sections in the ini. From my analysis of the DLL the VSnnnnnnnn and PSnnnnnnnn sections share a common code path for parsing, so they support most of the same settings as each other, but with VS in any setting name changed to PS for pixel shaders.
The log says:
<snip>
Which is the usual report I guess. The shader is a normal vs_3_0. Nethertheless as soon as it is in the override folder (even without any modifications) the speech bubbles disappear.
Yep, that log looks normal. I'm not sure what would be happening here... do they have a preshader section by any chance? Maybe post the complete shader in a [code]block and we can try to spot anything that may be causing an issue.
So I can't fix their depth. As a workaround I want to offer a hotkey to blend out and blend in the 2D speech bubbles using the PS. As the PS also is connected to other elements that should be visible in the crystarium it would be nice if I could use texture CRCs also for the PS.
Worth a shot - as above you should be able to use DefinedTexturesPS for this.
Anyway it is quite astonishing (and annoying) to see how many completely different aspects of the game are controlled by only one shader. An extreme example is VS 77704446 which seems to be responsible for every second issue I find in the game...
I know the feeling. It sounds like you have run into a pretty extreme case of this. Would I be correct in guessing that 77704446 is a fairly simple shader? It tends to be that the simpler shaders (particularly vertex shaders) are more likely to have this issue as multiple high level effects may all use a similar vertex shaders that compile to the same assembly if they do most of their processing in the pixel shader.
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
Thank You for Your suggestion!
I encountered the mip-map issue when I was removing or replacing textures with texmod and had to hunt the textures for different distances. With texmod I always was able to get all kind of mip-map textures. So I used texmod to analyze the textures for the marker but it always had the same CRC. Then I tried the settings for helixmod You suggested but I got the same CRC, too. TEXTURELOG also showed only BeginScene and EndScene. The reason for swichting between 2D and 3D depth is definitevly the texture recognition as the marker is always placed correctly when I remove the texture filter and use the prime directive on every texture in VS77704446.
I even tried the blacklist solution - it's really crazy! I have told NOT to use the prime directive on glow effects from Mogry as it would mess them up but on every other texture (which should include the marker!). The result: the glow effects were correctly recognized and at correct depth in every situation. BUT there was still the 2D/3D switch for the marker, now with inverted behavior. This means that the CRC from the marker that is NOT in the blacklist is treated as if it was in the list!? I could understand if a CRC is not recognized for some reason in the whitelist solution. But to be "recognized" as a texture with a completely different CRC in the blacklist is very strange. Even using a fictional CRC in the blacklist had the same results. In contrary to this using the filter on the glow effect always worked correctly.
So my final conclusion is that VS77704446 when it processes the marker and asks for the value in TexCounterReg it gets an answer that has nothing to do with the presence or absence of textures but is influenced by... what so ever. When VS77704446 processes other elements as the glow effect or fog it get's the correct answer.
So I need to find another way than the texture CRC to distinguish in VS77704446 between the marker and other elements (glow, fog). I realized that the marker seems to be the only element for this shader that is displayed in 2D at screen depth. Glow, fog, etc. have halo issues (which can be fixed with prime directive on texccord) but are not 2D at screen depth.
So is there a code that allows me to determine if the x-values on screen are finally the same for both eyes and then use the prime directive on dcl_position for only this element?
This is the code for VS77704446 which includes my (not reliably working) white list code:
[code]// fog, quest marker, Mogry glow, time travel animation, .... EVERYTHING!?!?!?
// Generated by Microsoft (R) HLSL Shader Compiler 9.26.952.2844
//
// Parameters:
//
// float4 ModelBBoxOffSet;
// float4 ModelBBoxScale;
// float4 controlColor;
// float3 fogParam;
// bool isSkining;
// bool isUseInstancing;
// float4 jointMatrices[144];
// float4x4 textureMatrix0;
// float4x4 viewITMatrix;
// float4x4 worldITMatrix;
// float4x4 worldMatrix;
// float4x4 worldViewMatrix;
// float4x4 worldViewProjMatrix;
//
//
// Registers:
//
// Name Reg Size
// ------------------- ----- ----
// isSkining b0 1
// isUseInstancing b1 1
// worldMatrix c0 4
// worldITMatrix c4 3
// worldViewProjMatrix c8 4
// worldViewMatrix c12 4
// viewITMatrix c16 4
// jointMatrices c21 144
// ModelBBoxScale c169 1
// ModelBBoxOffSet c170 1
// textureMatrix0 c171 4
// fogParam c175 1
// controlColor c176 1
//
//
// Default values:
//
// ModelBBoxScale
// c169 = { 1, 1, 1, 1 };
//
// ModelBBoxOffSet
// c170 = { 0, 0, 0, 0 };
//
// fogParam
// c175 = { 0, 100, 1, 0 };
//
// controlColor
// c176 = { 1, 1, 1, 1 };
//
vs_3_0
def c200, 0, 1, 0.0625, 6 // 0.0625 prime directive reference value
def c7, 2, -1, 3, 1
def c20, 0, 0, 0, 0
dcl_2d s0 // Sampler used to fetch stereo params
dcl_position v0
dcl_color v1
dcl_normal v2
dcl_blendindices v3
dcl_texcoord6 v4
dcl_texcoord7 v5
dcl_texcoord v6
dcl_position o0
dcl_texcoord o1
dcl_texcoord1 o2
dcl_texcoord2 o3
dcl_texcoord3 o4.xyz
dcl_texcoord4 o5
dcl_texcoord6 o6
mad r0.xyz, v2, c7.x, c7.y
mov r1.xyz, c169
mad r1.xyz, v0, r1, c170
if b1
mov r1.w, v0.w
dp4 r0.w, v3, r1
dp4 r2.x, v4, r1
dp4 r1.z, v5, r1
dp3 r1.w, v3, r0
dp3 r2.y, v4, r0
dp3 r0.z, v5, r0
mov r1.x, r0.w
mov r1.y, r2.x
mov r3.x, v1.w
mov r0.x, r1.w
mov r0.y, r2.y
else
if b0
frc r2, v5
add r4, -r2, v5
slt r5, v5, -v5
slt r2, -r2, r2
mad r2, r5, r2, r4
mul r2, r2, c7.z
mova a0, r2
mul r2, v4.y, c21[a0.y]
mul r4, v4.y, c22[a0.y]
mul r5, v4.y, c23[a0.y]
mad r2, c21[a0.x], v4.x, r2
mad r4, c22[a0.x], v4.x, r4
mad r5, c23[a0.x], v4.x, r5
mad r2, c21[a0.z], v4.z, r2
mad r4, c22[a0.z], v4.z, r4
mad r5, c23[a0.z], v4.z, r5
mad r2, c21[a0.w], v4.w, r2
mad r4, c22[a0.w], v4.w, r4
mad r5, c23[a0.w], v4.w, r5
mov r6.xyz, r1
mov r6.w, v0.w
dp4 r1.x, r2, r6
dp4 r1.y, r4, r6
dp4 r1.z, r5, r6
dp3 r0.w, r2, r0
dp3 r1.w, r4, r0
dp3 r0.z, r5, r0
mov r3.x, c7.w
mov r0.x, r0.w
mov r0.y, r1.w
else
mov r3.x, v1.w
endif
endif
mul r2, r1.y, c1
mad r2, c0, r1.x, r2
mad r2, c2, r1.z, r2
mad r2, c3, v0.w, r2
mul r0.w, r1.y, c13.z
mad r0.w, c12.z, r1.x, r0.w
mad r0.w, c14.z, r1.z, r0.w
mad r0.w, c15.z, v0.w, r0.w
mul r4, r1.y, c9
mad r4, c8, r1.x, r4
mad r1, c10, r1.z, r4
mad r1, c11, v0.w, r1
mul r4.xyz, r0.y, c5
mad r4.xyz, c4, r0.x, r4
mad o4.xyz, c6, r0.z, r4
mul r0.xy, c172, v6.y
mad r0.xy, c171, v6.x, r0
add o5.xy, r0, c174
mov r4.x, -c16.w
mov r4.y, -c17.w
mov r4.z, -c18.w
mov r4.w, -c19.w
add r4, r2, r4
dp4 r0.x, r4, r4
rsq r0.x, r0.x
mul o6.xyz, r4, r0.x
add r0.x, -r0.w, -c175.x
add r0.y, -c175.x, c175.y
rcp r0.y, r0.y
mul_sat r0.x, r0.x, r0.y
pow r4.x, r0.x, c175.z
min o6.w, r4.x, c7.w
mov r3.yzw, v1.xxyz
mul o1, r3.yzwx, c176
// mov o0, r1
mov r0, r1 // using prime directive on r1 = r0
texldl r30, c200.z, s0
add r30.w, r0.w, -r30.y
mul r30.z, r30.x, r30.w
add r0.x, r0.x, r30.z
mov r13.x, c250.x // using prime directive for o0 (dcl_position) only for quest marker texture, 0 = defined
if_eq r13.x, c200.x
mov o0, r0
else
mov o0, r1
endif
mov o2, r2
// mov o3, r1
mov o3, r0 // using prime directive for o3 (dcl_texcoord2) for every texture to fix halo issues
mov o5.zw, c20.x
// approximately 96 instruction slots used
[/code]
And this is the original code of VSFA9322CC for the 2D speech bubbles that disables the bubbles even when I do not change the code at all:
[code]//
// Generated by Microsoft (R) HLSL Shader Compiler 9.26.952.2844
//
// Parameters:
//
// float4 ModelBBoxOffSet;
// float4 ModelBBoxScale;
// float4 controlColor;
// float3 fogParam;
// bool isSkining;
// bool isUseInstancing;
// float4 jointMatrices[144];
// float4x4 textureMatrix0;
// sampler2D vfxDepthMap;
// float4 vfxLensFlareAlphaUVInfo;
// float4x4 viewITMatrix;
// float4x4 worldITMatrix;
// float4x4 worldMatrix;
// float4x4 worldViewMatrix;
// float4x4 worldViewProjMatrix;
//
//
// Registers:
//
// Name Reg Size
// ----------------------- ----- ----
// isSkining b0 1
// isUseInstancing b1 1
// worldMatrix c0 4
// worldITMatrix c4 3
// worldViewProjMatrix c8 4
// worldViewMatrix c12 4
// viewITMatrix c16 4
// jointMatrices c21 144
// ModelBBoxScale c169 1
// ModelBBoxOffSet c170 1
// textureMatrix0 c171 4
// fogParam c175 1
// controlColor c176 1
// vfxLensFlareAlphaUVInfo c177 1
// vfxDepthMap s0 1
//
//
// Default values:
//
// ModelBBoxScale
// c169 = { 1, 1, 1, 1 };
//
// ModelBBoxOffSet
// c170 = { 0, 0, 0, 0 };
//
// fogParam
// c175 = { 0, 100, 1, 0 };
//
// controlColor
// c176 = { 1, 1, 1, 1 };
//
// vfxLensFlareAlphaUVInfo
// c177 = { 0, 0, 0, 0 };
//
vs_3_0
def c7, 2, -1, 3, 1
def c20, 0.166666672, 0.296294987, 0, 1
def c165, 0, 0.027777778, 0, 0
defi i0, 6, 0, 0, 0
dcl_position v0
dcl_color v1
dcl_normal v2
dcl_blendindices v3
dcl_texcoord6 v4
dcl_texcoord7 v5
dcl_texcoord v6
dcl_2d s0
dcl_position o0
dcl_texcoord o1
dcl_texcoord1 o2
dcl_texcoord2 o3
dcl_texcoord3 o4.xyz
dcl_texcoord4 o5
dcl_texcoord6 o6
mad r0.xyz, v2, c7.x, c7.y
mov r1.xyz, c169
mad r1.xyz, v0, r1, c170
if b1
mov r1.w, v0.w
dp4 r0.w, v3, r1
dp4 r2.x, v4, r1
dp4 r1.z, v5, r1
dp3 r1.w, v3, r0
dp3 r2.y, v4, r0
dp3 r0.z, v5, r0
mov r1.x, r0.w
mov r1.y, r2.x
mov r3.x, v1.w
mov r0.x, r1.w
mov r0.y, r2.y
else
if b0
frc r2, v5
add r4, -r2, v5
slt r5, v5, -v5
slt r2, -r2, r2
mad r2, r5, r2, r4
mul r2, r2, c7.z
mova a0, r2
mul r2, v4.y, c21[a0.y]
mul r4, v4.y, c22[a0.y]
mul r5, v4.y, c23[a0.y]
mad r2, c21[a0.x], v4.x, r2
mad r4, c22[a0.x], v4.x, r4
mad r5, c23[a0.x], v4.x, r5
mad r2, c21[a0.z], v4.z, r2
mad r4, c22[a0.z], v4.z, r4
mad r5, c23[a0.z], v4.z, r5
mad r2, c21[a0.w], v4.w, r2
mad r4, c22[a0.w], v4.w, r4
mad r5, c23[a0.w], v4.w, r5
mov r6.xyz, r1
mov r6.w, v0.w
dp4 r1.x, r2, r6
dp4 r1.y, r4, r6
dp4 r1.z, r5, r6
dp3 r0.w, r2, r0
dp3 r1.w, r4, r0
dp3 r0.z, r5, r0
mov r3.x, c7.w
mov r0.x, r0.w
mov r0.y, r1.w
else
mov r3.x, v1.w
endif
endif
mul r2, r1.y, c1
mad r2, c0, r1.x, r2
mad r2, c2, r1.z, r2
mad r2, c3, v0.w, r2
mul r0.w, r1.y, c13.z
mad r0.w, c12.z, r1.x, r0.w
mad r0.w, c14.z, r1.z, r0.w
mad r0.w, c15.z, v0.w, r0.w
mul r4, r1.y, c9
mad r4, c8, r1.x, r4
mad r1, c10, r1.z, r4
mad r1, c11, v0.w, r1
mul r4.xyz, r0.y, c5
mad r4.xyz, c4, r0.x, r4
mad o4.xyz, c6, r0.z, r4
mul r0.xy, c172, v6.y
mad r0.xy, c171, v6.x, r0
add o5.xy, r0, c174
mov r4.x, -c16.w
mov r4.y, -c17.w
mov r4.z, -c18.w
mov r4.w, -c19.w
add r4, r2, r4
dp4 r0.x, r4, r4
rsq r0.x, r0.x
mul o6.xyz, r4, r0.x
add r0.x, -r0.w, -c175.x
add r0.y, -c175.x, c175.y
rcp r0.y, r0.y
mul_sat r0.x, r0.x, r0.y
pow r4.x, r0.x, c175.z
min o6.w, r4.x, c7.w
mov r3.yzw, v1.xxyz
mul r0, r3.yzwx, c176
mov r3.xy, c20
mul r3.xy, r3, c177.w
mov r4.zw, c20
mov r3.zw, c20.z
rep i0
mad r4.y, r3.y, r3.w, c177.y
mov r5.x, c20.z
rep i0
mad r4.x, r3.x, r5.x, c177.x
texldl r6, r4, s0
add r4.x, r6.x, -c177.z
mul r5.y, r4.x, r4.x
rsq r5.y, r5.y
mul r4.x, r4.x, r5.y
max r4.x, r4.x, c20.z
add r3.z, r3.z, r4.x
add r5.x, r5.x, c7.w
endrep
add r3.w, r3.w, c7.w
endrep
mul r0.w, r0.w, r3.z
mul o1.w, r0.w, c165.y
mov o0, r1
mov o1.xyz, r0
mov o2, r2
mov o3, r1
mov o5.zw, c20.z
// approximately 126 instruction slots used (2 texture, 124 arithmetic)
[/code]
Thank You for Your help and patience! But don't spend too much time on it. When the marker only works correctly 50% of the time and the speech bubbles simply have to be turned on and off with hotkeys it is still better than being not fixed at all ;)
Thank You for Your suggestion!
I encountered the mip-map issue when I was removing or replacing textures with texmod and had to hunt the textures for different distances. With texmod I always was able to get all kind of mip-map textures. So I used texmod to analyze the textures for the marker but it always had the same CRC. Then I tried the settings for helixmod You suggested but I got the same CRC, too. TEXTURELOG also showed only BeginScene and EndScene. The reason for swichting between 2D and 3D depth is definitevly the texture recognition as the marker is always placed correctly when I remove the texture filter and use the prime directive on every texture in VS77704446.
I even tried the blacklist solution - it's really crazy! I have told NOT to use the prime directive on glow effects from Mogry as it would mess them up but on every other texture (which should include the marker!). The result: the glow effects were correctly recognized and at correct depth in every situation. BUT there was still the 2D/3D switch for the marker, now with inverted behavior. This means that the CRC from the marker that is NOT in the blacklist is treated as if it was in the list!? I could understand if a CRC is not recognized for some reason in the whitelist solution. But to be "recognized" as a texture with a completely different CRC in the blacklist is very strange. Even using a fictional CRC in the blacklist had the same results. In contrary to this using the filter on the glow effect always worked correctly.
So my final conclusion is that VS77704446 when it processes the marker and asks for the value in TexCounterReg it gets an answer that has nothing to do with the presence or absence of textures but is influenced by... what so ever. When VS77704446 processes other elements as the glow effect or fog it get's the correct answer.
So I need to find another way than the texture CRC to distinguish in VS77704446 between the marker and other elements (glow, fog). I realized that the marker seems to be the only element for this shader that is displayed in 2D at screen depth. Glow, fog, etc. have halo issues (which can be fixed with prime directive on texccord) but are not 2D at screen depth.
So is there a code that allows me to determine if the x-values on screen are finally the same for both eyes and then use the prime directive on dcl_position for only this element?
This is the code for VS77704446 which includes my (not reliably working) white list code:
// approximately 126 instruction slots used (2 texture, 124 arithmetic)
Thank You for Your help and patience! But don't spend too much time on it. When the marker only works correctly 50% of the time and the speech bubbles simply have to be turned on and off with hotkeys it is still better than being not fixed at all ;)
My original display name is 3d4dd - for some reason Nvidia changed it..?!
[quote="3d4dd"]So my final conclusion is that VS77704446 when it processes the marker and asks for the value in TexCounterReg (of course trying different registers, not only 250) it gets an answer that has nothing to do with the presence or absence of textures but is influenced by... what so ever. When VS77704446 processes other elements as the glow effect or fog it get's the correct answer.[/quote]Wow, something very funky is going on there, and I have absolutely no idea what it might be.
[quote]So is there a code that allows me to determine if the x-values on screen are finally the same for both eyes and then use the prime directive on dcl_position for only this element?[/quote]Best bet would be to test the w component of the position, which will be equal to 1 at screen depth, similar to this:
https://github.com/DarkStarSword/3d-fixes/blob/master/The%20Forest/ShaderOverride/VertexShaders/0DC90B2E.txt
If it turns out that it isn't 1 at screen depth, try 0. If it isn't that either change the condition to an if_ge (greater than or equal to) or if_le (less than or equal to) and adjust the value until you narrow down what it is.
[quote]This is the code for VS77704446 which includes my (not reliably working) white list code:[/quote]Wow, that's actually pretty surprising - I was expecting a fairly simple shader if it was used by so many effects, but this is quite the opposite.
[quote]And this is the original code of VSFA9322CC for the 2D speech bubbles that disables the bubbles even when I do not change the code at all:[/quote]I can't see anything obvious at first glance - I'll take a closer look tomorrow.
3d4dd said:So my final conclusion is that VS77704446 when it processes the marker and asks for the value in TexCounterReg (of course trying different registers, not only 250) it gets an answer that has nothing to do with the presence or absence of textures but is influenced by... what so ever. When VS77704446 processes other elements as the glow effect or fog it get's the correct answer.
Wow, something very funky is going on there, and I have absolutely no idea what it might be.
So is there a code that allows me to determine if the x-values on screen are finally the same for both eyes and then use the prime directive on dcl_position for only this element?
If it turns out that it isn't 1 at screen depth, try 0. If it isn't that either change the condition to an if_ge (greater than or equal to) or if_le (less than or equal to) and adjust the value until you narrow down what it is.
This is the code for VS77704446 which includes my (not reliably working) white list code:
Wow, that's actually pretty surprising - I was expecting a fairly simple shader if it was used by so many effects, but this is quite the opposite.
And this is the original code of VSFA9322CC for the 2D speech bubbles that disables the bubbles even when I do not change the code at all:
I can't see anything obvious at first glance - I'll take a closer look tomorrow.
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="3d4dd"]And this is the original code of VSFA9322CC for the 2D speech bubbles that disables the bubbles even when I do not change the code at all:
[code]<snip>
dcl_2d s0
[/code][/quote]That's most likely the problem - assuming you didn't add that then this vertex shader is already using sampler 0, which Helix mod is overriding. You can get around this by adding this section to your DX9Settings.ini:
[code]
[VSFA9322CC]
; This shader already uses s0, so use s3 instead.
; Quirk: Add 257 to sampler numbers (specific to vertex shaders)
DefVSSampler = 260
[/code]
Then you access the stereo sampler through s3 in that shader instead of s0
3d4dd said:And this is the original code of VSFA9322CC for the 2D speech bubbles that disables the bubbles even when I do not change the code at all:
<snip>
dcl_2d s0
That's most likely the problem - assuming you didn't add that then this vertex shader is already using sampler 0, which Helix mod is overriding. You can get around this by adding this section to your DX9Settings.ini:
[VSFA9322CC]
; This shader already uses s0, so use s3 instead.
; Quirk: Add 257 to sampler numbers (specific to vertex shaders)
DefVSSampler = 260
Then you access the stereo sampler through s3 in that shader instead of s0
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
Thank You for the information! I will try it out next.
Meanwhile I have tested texture filtering with PS. I used this code in DX9Settings.ini:
[code][PS8E67A6FA]
CheckTexCRC = true
ValForDefined = 0
ValNotDefined = 1
TexCounterReg = 251
UseDefinedOnly = false
DefinedTexturesPS = 136A973A;[/code]
and referred to it in the shader with:
[code]mov r30.x, c251.x[/code]
(equivalent to the code for VS).
But as soon as the PS contained this code it was ignored by helixmod from then on (even when I removed the code and reloaded the shader). I didn't make a difference whether the code was present when starting the game or introduced later. So the reference to TexCounterReg seems to brake the PS :( I have tested several PS with no effort. I have also tried different values for the TexCounterReg.
BTW: does it matter if I use different or the same register value for TexCounterReg when I have different shaders with texture filtering? At least with VS both seems to work.
Update: Good news! VSFA9322CC works with DefVSSampler = 260 now! A very important information that shaders that already contain dcl_2d s0 can cause trouble. I even think that I have seen other shaders which originally had dcl_2d s0 in their code. But I can't remember that they didn't work (maybe I have used them to disable effects and so it didn't matter when they were broken this way...). Now that I have access to the VS for the speech bubbles perhaps I don't need the texture filter for PS any more. Thank You so much for Your help!
Update: Using the prime directive on dcl_position in VSFA9322CC fixed the speech bubbles. They are not only pushed to depth but even correctly placed above the characters. And so far I could not observe negative side effects on other elements of the game :)
(equivalent to the code for VS).
But as soon as the PS contained this code it was ignored by helixmod from then on (even when I removed the code and reloaded the shader). I didn't make a difference whether the code was present when starting the game or introduced later. So the reference to TexCounterReg seems to brake the PS :( I have tested several PS with no effort. I have also tried different values for the TexCounterReg.
BTW: does it matter if I use different or the same register value for TexCounterReg when I have different shaders with texture filtering? At least with VS both seems to work.
Update: Good news! VSFA9322CC works with DefVSSampler = 260 now! A very important information that shaders that already contain dcl_2d s0 can cause trouble. I even think that I have seen other shaders which originally had dcl_2d s0 in their code. But I can't remember that they didn't work (maybe I have used them to disable effects and so it didn't matter when they were broken this way...). Now that I have access to the VS for the speech bubbles perhaps I don't need the texture filter for PS any more. Thank You so much for Your help!
Update: Using the prime directive on dcl_position in VSFA9322CC fixed the speech bubbles. They are not only pushed to depth but even correctly placed above the characters. And so far I could not observe negative side effects on other elements of the game :)
My original display name is 3d4dd - for some reason Nvidia changed it..?!
[quote="DarkStarSword"] Best bet would be to test the w component of the position, which will be equal to 1 at screen depth
[/quote]
Unfortunately this doesn't help. Just be sure: I compared r1.w (line 160 in VS77704446) which should be equal to o0.w to 0 or 1 (or values smaller/greater) to distinguish between the marker at screen depth and the other elements (glow, fog, etc.). The effect is that the differentiation then depends on the distance to the OBJECT that is marked with the icon. So the w-component in r1 (the original o0) doesn't represent the depth at which the ICON is displayd in the end. But r1.w seems to be connected to the depth of the OBJECT that is marked with the icon. I think the reason is the fact that this is not the usual shader for 2D HUD elements. This is why I had to use the prime directive on dcl_position and not the usual formula for 2D HUDs. We had also speculated that the shader per se would offer correct depth information for the icon but it is a driver mechanism that prevents the icon to be stereoised and so displays it at screen depth. I think this driver mechanism intervens after the Helixmod-shader so the shader "doesn't know" that the icon finally will be placed at screen depth and not above the object. This means that the w-component in this case won't help for the differentiation, right?
BTW are there profiles that handle HUD elements in a special way? I've tried the Aion profile - and EVERYTHING in the game was plain 2D. So the contrary to what I was looking for...
DarkStarSword said: Best bet would be to test the w component of the position, which will be equal to 1 at screen depth
Unfortunately this doesn't help. Just be sure: I compared r1.w (line 160 in VS77704446) which should be equal to o0.w to 0 or 1 (or values smaller/greater) to distinguish between the marker at screen depth and the other elements (glow, fog, etc.). The effect is that the differentiation then depends on the distance to the OBJECT that is marked with the icon. So the w-component in r1 (the original o0) doesn't represent the depth at which the ICON is displayd in the end. But r1.w seems to be connected to the depth of the OBJECT that is marked with the icon. I think the reason is the fact that this is not the usual shader for 2D HUD elements. This is why I had to use the prime directive on dcl_position and not the usual formula for 2D HUDs. We had also speculated that the shader per se would offer correct depth information for the icon but it is a driver mechanism that prevents the icon to be stereoised and so displays it at screen depth. I think this driver mechanism intervens after the Helixmod-shader so the shader "doesn't know" that the icon finally will be placed at screen depth and not above the object. This means that the w-component in this case won't help for the differentiation, right?
BTW are there profiles that handle HUD elements in a special way? I've tried the Aion profile - and EVERYTHING in the game was plain 2D. So the contrary to what I was looking for...
My original display name is 3d4dd - for some reason Nvidia changed it..?!
[quote="3d4dd"]But as soon as the PS contained this code it was ignored by helixmod from then on (even when I removed the code and reloaded the shader).
<snip>
Update: Using the prime directive on dcl_position in VSFA9322CC fixed the speech bubbles. They are not only pushed to depth but even correctly placed above the characters. And so far I could not observe negative side effects on other elements of the game :)[/quote]Glad you were able to get it working in the vertex shader :)
At a guess - the reason the pixel shader wasn't working was probably that pixel shaders don't have access to as many constant registers as vertex shaders, with c223 being the max usable (and it can be even less if the game has limited it further - sometimes it's not a bad idea to choose something around the values the shader is already using):
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172920(v=vs.85).aspx
I'll have a think about the markers. There might be a profile setting that can affect them, but I'm not sure what it would be. A little while back I extracted all the stereo settings from the driver and made a CustomSettingNames_en-EN.xml file you can use with nVidia Inspector to see all the stereo settings, so you might be able to find one that will help, but I'm not really sure where to begin (there are a lot of them and none of the names jump out at me as something that might help here, and even then I have no idea what values to try). Replace the xml file in nVidia Inspector with this one and take a look at the Stereo category:
https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/CustomSettingNames_en-EN.xml
I've been meaning to write a script to catalogue which of those values are used by different games and all the different possible values, which might help narrow down which settings are actually useful (so many things I've been meaning to do).
Here are my posts where I documented some of my experiments... StereoCutoff might be worth playing with maybe?:
[url]https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/post/4331640/#4331640[/url]
[url]https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/post/4339272/#4339272[/url]
3d4dd said:But as soon as the PS contained this code it was ignored by helixmod from then on (even when I removed the code and reloaded the shader).
<snip>
Update: Using the prime directive on dcl_position in VSFA9322CC fixed the speech bubbles. They are not only pushed to depth but even correctly placed above the characters. And so far I could not observe negative side effects on other elements of the game :)
Glad you were able to get it working in the vertex shader :)
At a guess - the reason the pixel shader wasn't working was probably that pixel shaders don't have access to as many constant registers as vertex shaders, with c223 being the max usable (and it can be even less if the game has limited it further - sometimes it's not a bad idea to choose something around the values the shader is already using):
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172920(v=vs.85).aspx
I'll have a think about the markers. There might be a profile setting that can affect them, but I'm not sure what it would be. A little while back I extracted all the stereo settings from the driver and made a CustomSettingNames_en-EN.xml file you can use with nVidia Inspector to see all the stereo settings, so you might be able to find one that will help, but I'm not really sure where to begin (there are a lot of them and none of the names jump out at me as something that might help here, and even then I have no idea what values to try). Replace the xml file in nVidia Inspector with this one and take a look at the Stereo category:
https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/CustomSettingNames_en-EN.xml
I've been meaning to write a script to catalogue which of those values are used by different games and all the different possible values, which might help narrow down which settings are actually useful (so many things I've been meaning to do).
You might run into issues where adjusting the depth also adjusts something you didn't want. I'm sure bo3b will cover this in more detail when the lesson is up, but here's a few examples from my fixes which you might be interested in looking at.
- In The Forest, 90% of the UI was already at a good depth, but a few HUD icons were at screen depth, so here I only do the depth adjustment if the original depth was equal to 1 (in some cases this might be 0 instead):
https://github.com/DarkStarSword/3d-fixes/blob/95efcbd69f9a4ad49e2285c81aafe6df5e7e2f8d/The%20Forest/ShaderOverride/VertexShaders/0DC90B2E.txt
- In The Book of Unwritten Tales 2, the UI depth adjustment had the unfortunate side-effect of moving text on the menu to the right, so for this shader I check the texture CRC and make sure I don't adjust it whenever the menu text is being drawn:
https://github.com/DarkStarSword/3d-fixes/blob/master/BoUT2/ShaderOverride/VertexShaders/0DC90B2E.txt
see also the bCalcTexCRCatStart = true and [VS10F9DBCC] section in the ini:
https://github.com/DarkStarSword/3d-fixes/blob/master/BoUT2/DX9Settings.ini
- I ran into a similar issue in World of Diving where a number of things moved to the right, however one particular texture proved impossible to track down (the CRC changed every time the game was launched). This last texture was only visible while the diving computer was on-screen while the tab key was being held, so here I disable it on blacklisted textures AND whenever the tab key is held:
https://github.com/DarkStarSword/3d-fixes/blob/master/World%20of%20Diving/ShaderOverride/VertexShaders/A8D32517.txt
- Things can get even more crazy. This shader from Montague's Mount affected part of the UI, the lens flare *AND* the halo around lights, the three of which need completely different things done. Here I check the texture to distinguish between UI and flare/halo, but the flares and halos use the same texture, so I test the depth to distinguish between them:
https://github.com/DarkStarSword/3d-fixes/blob/c8956ee23d6ad7518dd31b1bbe6c2467b10c158c/Montague%27s%20Mount/ShaderOverride/VertexShaders/CD61F9B3.txt
If you were particularly observant, you may have noticed the CRC for the UI shader in The Forest and The Book of Unwritten Tales 2 is identical. These two games are indeed using the same shader which is not a huge surprise given they use the same engine, however both required a slightly different fix depending on exactly what the game was doing and what side-effects arose.
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
I have found in many games I get crashes using that if I move the camera (e.g. by moving the mouse, or while in a cutscene) while a shader is disabled. In this case, pressing minus on the number pad will reset the shaders making moving the mouse/camera safe again. In Dreamfall Chapters I was usually able to use this trick (also - I discovered I could pause the game in cutscenes), however in particularly complex & dynamic scenes (such as Europolis) I would often get crashes even while not moving the camera (fortunately by that stage of the game I had fixed most of the shaders already).
This almost always means that the same shader has been used for multiple different things in the scene. Often they are all broken and the one fix will help all of them, but occasionally you may need a way to distinguish between them to only apply the fix to some instances, such as I did above to check the texture CRC or depth. Helix mod can also distinguish them by adding an index to the filename, but I'm not sure how well that works in practice. There is a small possibility of a hash collision leading to two completely different shaders to have the same CRC, but it should be quite rare and not something I'd worry about unless you actually run into it.
What often happens here is that two distinct shaders (from the developer's point of view) have compiled to the exact same assembly and have the same checksum, so Helix mod cannot distinguish between them. If you only need to fix one and doing so breaks the other, you need to find some other way to distinguish between them. In this case I'd suggest trying the depth since there is a reasonable chance that whenever the depth is 1 it will be a UI element, otherwise it will be fog. If that doesn't work you may need to test something else, like the texture being used.
This will be another case of the above - the same shader is used for multiple items, and when running through with the debug dll it can disable each instance individually, but when the shader is used from ShaderOverride it will affect all instances using that same shader unless you can distinguish between them.
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
I added your cool find of NumPad- for game crashes to the gotchas list on Helix docs. Thanks!
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
dp4 o1.w, v0, c3
dp4 o1.z, v0, c2
dp4 o1.y, v0, c1
dp4 o1.x, v0, c0
in any of the VS I got when hunting the HUD shaders. Now I will try to find it by searching the dumpall folder. What is specific for this pattern? I guess that o1 could also be o0, o2, etc. Same with v0. And that there are other c than c0-c3? Is it characteristic that You have the same o with .w, .z, .y, .x and allways the same v? And I guess that there could be a r instead of o, v, c?
I will also try NumPad-. It is really annoying to have to cycle through 1000 shader when there are only 100 used.
Regarding fixes for cutscenes: in FF XIII(-2) You also can pause cutscenes but unfortunately cycling through the shaders has no effect when the scenery is frozen this way. And cycling through over hundred shader in realtime when the issue is only visible for 1-2 sec is impossible. But I have found another solution: I discovered that the shaders to fix halo issues in FF XIII are very similar (similar parameters used, similar complexity/file size). So I have searched the dumpall folder of FF XIII-2 for these pattern and added the prime directive fix to them "on spec". And indeed now the fog issues in cutscenes disappeared. Which raises another question: there are many fog effects in the game that work out of the box without a fix. Can I ruin these shaders when I ad the prime directive to them or does it simply has no effect then?
My original display name is 3d4dd - for some reason Nvidia changed it..?!
That pattern of four dp4 instructions with four sequentially numbered constant registers (not necessarily in order) will become very important to look out for in more advanced fixes (such as shadow fixes) - it is one of two patterns that signify a matrix multiply where the shader is transforming from one coordinate system into another (I don't recall the other pattern off the top of my head, only that it involved mul and add instructions and is used when a matrix is stored in row-major order).
That particular UI shader is clearly multiplying the input coordinates by a matrix, but it's also quite common for a UI shader to pass the coordinates straight through without transforming them, in which case you won't see that pattern. You might see a mov, mul, add or maybe even something else - the only thing you need to look out for in a UI shader is the output position register.
Yeah, definitely :)
That's unfortunate :( I've seen some games take a screenshot when they are paused and then display that instead of rendering the game, which might be what is happening here. Unfortunately in this case the pause trick won't work.
That's great :)
I've used a similar approach to pre-emptively fix lighting shaders in Unity games once I had worked out the pattern to fix them, so I didn't have to keep tracking down each individual one as I came across them.
Potentially yes, applying a fix to something that was working may break it, but other times it might be ok. You might have to make a judgement call on whether it's worth the risk or not, and whether it's going to save you time to do the pre-emptive fix and then manually fix up anything that broke. I've started doing this with Unity games, since every surface shader is broken in much the same way - in The Forest I've only had to manually fix one shader that broke after the auto fix (this is why I was able to do the first version of that fix in a day, despite it having so many broken shaders).
I'd suggest leaving a comment in the shader that you can search for so you know which ones are possible culprits in case something does break (if you've seen any of the shaders I've used my shadertool.py to fix you may have noticed that it inserts a comment with the command line I ran it with, and this is the reason I made it do that).
Another risk with a pre-emptive fix is making an error in a shader and breaking it, but not being able to check since you don't know where it was actually used. Be sure to check the LOG.txt for any errors, especially if anything weird starts happening (like effects disappearing or changing in bizarre inexplicable ways when reloading shaders with F10).
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
Unfortunately I could not find a way to fix the position of 2D speech bubbles icons on characters You can talk to. As soon as I place the correspondent shader in the override folder the icons disappear - even when I use the original shader without any changes.
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Curious - I wonder if the driver's heuristics were deciding not to stereoise them for some reason? Anyway, glad you were able to fix it :)
To get started hunting for texture CRCs, you need bCalcTexCRCatStart = true in the ini. The up/down arrow keys will cycle textures by default, but you can change them with PrevTexKey and NextTexKey if they interfere with the game.
For the most part textures will go black while they are disabled (so I'm not sure how to hunt a texture that is already black :-/), and once you have found the right one you should write down the CRC displayed in the red text (if they are shorter than 8 characters, pad them with zeros in the same way we do for shaders).
You will need to add a section similar to the following to the ini file:
The DefinedTexturesVS list needs to be filled out with the texture CRCs you found. You have two choices - you either need to list all the textures where you DO want the depth adjustment to be enabled (whitelisting), or list those where you DON'T want the adjustment to be enabled (blacklisting), but not both. If you can only find textures for some of the effects that might force your decision, or if you find that one way would require you to keep finding more and more textures it might be easier to go the other way (e.g. for a while in Dreamfall Chapters I was whitelisting every texture used on an inventory object, but that didn't seem smart as I'd have to keep finding more and more textures, so I blacklisted the inventory background instead).
It's probably worthwhile leaving a comment in the ini with what CRC corresponds with what. It's also a good idea to leave a comment for the textures you didn't inlcude in the DefiendTexturesVS list as well, so if find you need to invert the test later on you don't have to hunt them all again.
In the shader you will be able to determine if the texture was in the list or not by testing the x component of the constant register defined by TexCounterReg (c251.x in this example). If it is in the list, it will have the value in ValForDefined (1.0 in this example), otherwise it will have the value defined by ValNotDefined (0.0 in this example). (be aware, some of my fixes have ValNotDefined=1 and ValForDefined=0 so the tests in the assembly are also the other way - I don't really have a good reason for doing it this way).
Then, in the shader you add an if_eq around the stereo adjustment, something like:
Check the LOG.txt for any errors relating to them. Are these vs_3_0 shaders, or a different version? If they are not vs_3_0 you may need to convert them to shader model 3, which you can do by hand, or automatically with Mana's tool:
http://helixmod.blogspot.com.au/2013/05/vs11vs20-vs30-converter.html
If you check out my 3d-fixes repository (either using git, or just hitting download zip on github) and install Python 3 you can also use my shadertool.py script to convert them to shader model 3 automatically, which handles a few cases better (official announcement coming when it's a bit more polished). Run it with -i on a shader to copy it to the ShaderOverride directory and automatically convert it, use --help to see the rest of the options it supports.
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
I also got the feeling that the HUD and menus are not 2D objects but originally have some depth. As mentioned above all the HUD elements and menus in FF XIII were pushed to depth out of the box. And now that I have used the prime directive on FF XIII-2 they look the same as in FF XIII.
Thank You for Your detailed instructions regarding the texture CRCs! I have used it on the quest marker and it worked - most of the time. Under certain circumstances (distance to object, viewing angle) the texture recognition doesn't seem to work and the marker gets 2D again. I have used bCalcTexCRCatStart = true and hunted the CRC in these situations but the displayed CRC is always the same. Are the routines for texture hunting and texture identification within the shaders different?
BTW is there a way to determine the texture CRC also for PS? I couldn't find DefinedTexturesPS...
In some situations I also use the convergence as a trigger. I will make different presets (exploration, 3D-cutscenes, 2D-cutscenes etc.) and a special one that will be used when the game starts and the crystarium is used. This offers the best depth values for menu elements and the background and solves the problem that most of the shaders for menus, videos and backgrounds also affect other elements as fog during the gameplay. As it is not possible to find a CRC for a video I use the preset as trigger to determine if the user is actually in the start menu or playing.
The log says:
Which is the usual report I guess. The shader is a normal vs_3_0. Nethertheless as soon as it is in the override folder (even without any modifications) the speech bubbles disappear. So I can't fix their depth. As a workaround I want to offer a hotkey to blend out and blend in the 2D speech bubbles using the PS. As the PS also is connected to other elements that should be visible in the crystarium it would be nice if I could use texture CRCs also for the PS.
Anyway it is quite astonishing (and annoying) to see how many completely different aspects of the game are controlled by only one shader. An extreme example is VS 77704446 which seems to be responsible for every second issue I find in the game...
My original display name is 3d4dd - for some reason Nvidia changed it..?!
The CRC that helix mod displays in the red text is calculated when the texture is first created, but that does not get updated if the texture is altered later (which I believe is why I can't track down one texture in World of Diving). The CRCs that the shaders check for are calculated when the shader is actually used, so if the texture has changed it won't match, and it wouldn't surprise me at all if a mip-map causes a similar issue.
If this is the case there are a few things you might try, but I have no idea if any of these will work:
- You can try inverting the test and blacklisting the CRCs of the fog instead
- You might try setting CalcTexCRCatUpdate = true (which is used in the UpdateTexture() DirectX call) and seeing if you get a different CRC when hunting after the marker goes 2D
- You might try setting ResetCRCatReload = true (which is used in the GetSurfaceLevel() and LockRect() DirectX calls) and seeing if you get a different CRC when hunting after the marker goes 2D
- You might try pressing the button defined by ReloadTexturesListKey (defaults to F8). I'm not really sure what this does.
- You might try the alternate method to get texture CRCs, which is by pressing the button defined by SaveTextureLogKey (defaults to F12) while the marker is 2D. If you get a crash you will either need to change this to a different button, change the screenshot button in Steam, or disable the Steam overlay by removing GameOverlayRenderer.dll after launching Steam (the screenshot function in Steam seems to have a conflict with recent versions of Helix mod). In theory this will give you a TEXTURELOG.txt which will give you the CRCs the shader saw, however it has never worked for me and I have always ended up with log file that listed BeginScene and EndScene, but nothing else.
Yes, DefinedTexturesPS is correct and can be used in PSnnnnnnnn sections in the ini. From my analysis of the DLL the VSnnnnnnnn and PSnnnnnnnn sections share a common code path for parsing, so they support most of the same settings as each other, but with VS in any setting name changed to PS for pixel shaders.
Yep, that log looks normal. I'm not sure what would be happening here... do they have a preshader section by any chance? Maybe post the complete shader in a [code]block and we can try to spot anything that may be causing an issue.
Worth a shot - as above you should be able to use DefinedTexturesPS for this.
I know the feeling. It sounds like you have run into a pretty extreme case of this. Would I be correct in guessing that 77704446 is a fairly simple shader? It tends to be that the simpler shaders (particularly vertex shaders) are more likely to have this issue as multiple high level effects may all use a similar vertex shaders that compile to the same assembly if they do most of their processing in the pixel shader.
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
I encountered the mip-map issue when I was removing or replacing textures with texmod and had to hunt the textures for different distances. With texmod I always was able to get all kind of mip-map textures. So I used texmod to analyze the textures for the marker but it always had the same CRC. Then I tried the settings for helixmod You suggested but I got the same CRC, too. TEXTURELOG also showed only BeginScene and EndScene. The reason for swichting between 2D and 3D depth is definitevly the texture recognition as the marker is always placed correctly when I remove the texture filter and use the prime directive on every texture in VS77704446.
I even tried the blacklist solution - it's really crazy! I have told NOT to use the prime directive on glow effects from Mogry as it would mess them up but on every other texture (which should include the marker!). The result: the glow effects were correctly recognized and at correct depth in every situation. BUT there was still the 2D/3D switch for the marker, now with inverted behavior. This means that the CRC from the marker that is NOT in the blacklist is treated as if it was in the list!? I could understand if a CRC is not recognized for some reason in the whitelist solution. But to be "recognized" as a texture with a completely different CRC in the blacklist is very strange. Even using a fictional CRC in the blacklist had the same results. In contrary to this using the filter on the glow effect always worked correctly.
So my final conclusion is that VS77704446 when it processes the marker and asks for the value in TexCounterReg it gets an answer that has nothing to do with the presence or absence of textures but is influenced by... what so ever. When VS77704446 processes other elements as the glow effect or fog it get's the correct answer.
So I need to find another way than the texture CRC to distinguish in VS77704446 between the marker and other elements (glow, fog). I realized that the marker seems to be the only element for this shader that is displayed in 2D at screen depth. Glow, fog, etc. have halo issues (which can be fixed with prime directive on texccord) but are not 2D at screen depth.
So is there a code that allows me to determine if the x-values on screen are finally the same for both eyes and then use the prime directive on dcl_position for only this element?
This is the code for VS77704446 which includes my (not reliably working) white list code:
And this is the original code of VSFA9322CC for the 2D speech bubbles that disables the bubbles even when I do not change the code at all:
Thank You for Your help and patience! But don't spend too much time on it. When the marker only works correctly 50% of the time and the speech bubbles simply have to be turned on and off with hotkeys it is still better than being not fixed at all ;)
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Best bet would be to test the w component of the position, which will be equal to 1 at screen depth, similar to this:
https://github.com/DarkStarSword/3d-fixes/blob/master/The%20Forest/ShaderOverride/VertexShaders/0DC90B2E.txt
If it turns out that it isn't 1 at screen depth, try 0. If it isn't that either change the condition to an if_ge (greater than or equal to) or if_le (less than or equal to) and adjust the value until you narrow down what it is.
Wow, that's actually pretty surprising - I was expecting a fairly simple shader if it was used by so many effects, but this is quite the opposite.
I can't see anything obvious at first glance - I'll take a closer look tomorrow.
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
Then you access the stereo sampler through s3 in that shader instead of s0
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
Meanwhile I have tested texture filtering with PS. I used this code in DX9Settings.ini:
and referred to it in the shader with:
(equivalent to the code for VS).
But as soon as the PS contained this code it was ignored by helixmod from then on (even when I removed the code and reloaded the shader). I didn't make a difference whether the code was present when starting the game or introduced later. So the reference to TexCounterReg seems to brake the PS :( I have tested several PS with no effort. I have also tried different values for the TexCounterReg.
BTW: does it matter if I use different or the same register value for TexCounterReg when I have different shaders with texture filtering? At least with VS both seems to work.
Update: Good news! VSFA9322CC works with DefVSSampler = 260 now! A very important information that shaders that already contain dcl_2d s0 can cause trouble. I even think that I have seen other shaders which originally had dcl_2d s0 in their code. But I can't remember that they didn't work (maybe I have used them to disable effects and so it didn't matter when they were broken this way...). Now that I have access to the VS for the speech bubbles perhaps I don't need the texture filter for PS any more. Thank You so much for Your help!
Update: Using the prime directive on dcl_position in VSFA9322CC fixed the speech bubbles. They are not only pushed to depth but even correctly placed above the characters. And so far I could not observe negative side effects on other elements of the game :)
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Unfortunately this doesn't help. Just be sure: I compared r1.w (line 160 in VS77704446) which should be equal to o0.w to 0 or 1 (or values smaller/greater) to distinguish between the marker at screen depth and the other elements (glow, fog, etc.). The effect is that the differentiation then depends on the distance to the OBJECT that is marked with the icon. So the w-component in r1 (the original o0) doesn't represent the depth at which the ICON is displayd in the end. But r1.w seems to be connected to the depth of the OBJECT that is marked with the icon. I think the reason is the fact that this is not the usual shader for 2D HUD elements. This is why I had to use the prime directive on dcl_position and not the usual formula for 2D HUDs. We had also speculated that the shader per se would offer correct depth information for the icon but it is a driver mechanism that prevents the icon to be stereoised and so displays it at screen depth. I think this driver mechanism intervens after the Helixmod-shader so the shader "doesn't know" that the icon finally will be placed at screen depth and not above the object. This means that the w-component in this case won't help for the differentiation, right?
BTW are there profiles that handle HUD elements in a special way? I've tried the Aion profile - and EVERYTHING in the game was plain 2D. So the contrary to what I was looking for...
My original display name is 3d4dd - for some reason Nvidia changed it..?!
At a guess - the reason the pixel shader wasn't working was probably that pixel shaders don't have access to as many constant registers as vertex shaders, with c223 being the max usable (and it can be even less if the game has limited it further - sometimes it's not a bad idea to choose something around the values the shader is already using):
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172920(v=vs.85).aspx
I'll have a think about the markers. There might be a profile setting that can affect them, but I'm not sure what it would be. A little while back I extracted all the stereo settings from the driver and made a CustomSettingNames_en-EN.xml file you can use with nVidia Inspector to see all the stereo settings, so you might be able to find one that will help, but I'm not really sure where to begin (there are a lot of them and none of the names jump out at me as something that might help here, and even then I have no idea what values to try). Replace the xml file in nVidia Inspector with this one and take a look at the Stereo category:
https://raw.githubusercontent.com/DarkStarSword/3d-fixes/master/CustomSettingNames_en-EN.xml
I've been meaning to write a script to catalogue which of those values are used by different games and all the different possible values, which might help narrow down which settings are actually useful (so many things I've been meaning to do).
Here are my posts where I documented some of my experiments... StereoCutoff might be worth playing with maybe?:
https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/post/4331640/#4331640
https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/post/4339272/#4339272
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