Thanks bo3b! I verified the shader works now. Now I have to practice separating textures.
Also, I set the hunting mode to 'Soft Disabled' and the game no longer crashes. So I'll just enable hunting whenever I need it and disable it right after.
Thanks bo3b! I verified the shader works now. Now I have to practice separating textures.
Also, I set the hunting mode to 'Soft Disabled' and the game no longer crashes. So I'll just enable hunting whenever I need it and disable it right after.
I need a bit of help with the new texture filtering feature. The story:
In Zelda Ocarina of Time (in Dolphin), there are just a few vertex shaders (around 11 in the area I'm trying) and a bunch more pixel shaders (around 26). I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.
It worked and it looks good. But there are so few vertex shaders that everyone of them has to affect a variety of things. Not only the sky was pushed to depth, but Navi's circular body also gained depth (it's farther than her wings), and heart pieces and the spiritual stones are also "disassembled" now.
Question number 1: are the coordinates that the pixel shader receives set in stone? I sometimes tried to change some of the inputs of the main method of the pixel shader right at the start of the main method, but it never worked. If the answer is yes, it's probably the reason the new texture filtering exists.
In the "ShaderUsage.txt" file, I identified the vertex and pixel shaders of the sky:
I need a bit of help with the new texture filtering feature. The story:
In Zelda Ocarina of Time (in Dolphin), there are just a few vertex shaders (around 11 in the area I'm trying) and a bunch more pixel shaders (around 26). I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.
It worked and it looks good. But there are so few vertex shaders that everyone of them has to affect a variety of things. Not only the sky was pushed to depth, but Navi's circular body also gained depth (it's farther than her wings), and heart pieces and the spiritual stones are also "disassembled" now.
Question number 1: are the coordinates that the pixel shader receives set in stone? I sometimes tried to change some of the inputs of the main method of the pixel shader, but it never worked. If the answer is yes, it's probably the reason the new texture filtering exists.
In the "ShaderUsage.txt" file, I identified the vertex and pixel shaders of the sky when I dumped the pixel shader again:
[code]
<PixelShader hash="b50a9fff61b7bf45">
<ParentVertexShaders>7592a24e6fae0825 </ParentVertexShaders>
<Register id=0 handle=0000000023ACF4D8>0000000000000000</Register>
<Register id=0 handle=0000000023ACF858>0000000000000000</Register>
<Register id=0 handle=0000000023ACFBD8>0000000000000000</Register>
<Register id=0 handle=0000000023ACFF58>0000000000000000</Register>
<Register id=0 handle=0000000023AD02D8>0000000000000000</Register>
<Register id=0 handle=0000000023AD0698>0000000000000000</Register>
<Register id=0 handle=0000000023B2F918>0000000000000000</Register>
<Register id=0 handle=0000000023B2FAD8>0000000000000000</Register>
<Register id=0 handle=0000000023B2FC98>0000000000000000</Register>
<Register id=0 handle=0000000023B2FE58>0000000000000000</Register>
<Register id=0 handle=0000000023B30018>0000000000000000</Register>
<Register id=0 handle=0000000023B31658>0000000000000000</Register>
<Register id=0 handle=0000000023B31818>0000000000000000</Register>
<Register id=0 handle=0000000023B319D8>0000000000000000</Register>
<Register id=0 handle=0000000023B31B98>0000000000000000</Register>
<Register id=0 handle=0000000023B31D58>0000000000000000</Register>
<Register id=0 handle=0000000023B31F18>0000000000000000</Register>
<Register id=0 handle=0000000023B320D8>0000000000000000</Register>
<Register id=0 handle=0000000023B32298>0000000000000000</Register>
<Register id=0 handle=0000000023B32458>0000000000000000</Register>
<Register id=0 handle=0000000023B32618>0000000000000000</Register>
<Register id=0 handle=0000000023B327D8>0000000000000000</Register>
<Register id=0 handle=0000000023B32998>0000000000000000</Register>
<Register id=0 handle=0000000023B32B58>0000000000000000</Register>
<Register id=0 handle=0000000023B32D18>0000000000000000</Register>
<Register id=0 handle=0000000023B32ED8>0000000000000000</Register>
<Register id=0 handle=0000000023B33098>0000000000000000</Register>
<Register id=0 handle=0000000023B33258>0000000000000000</Register>
<Register id=0 handle=0000000023B33418>0000000000000000</Register>
<Register id=0 handle=0000000023B37658>0000000000000000</Register>
<Register id=0 handle=0000000023B44298>0000000000000000</Register>
<Register id=0 handle=0000000023B44458>0000000000000000</Register>
<Register id=0 handle=0000000023B44618>0000000000000000</Register>
<Register id=0 handle=0000000023B447D8>0000000000000000</Register>
<Register id=0 handle=0000000023B44998>0000000000000000</Register>
<Register id=0 handle=0000000023B44B58>0000000000000000</Register>
<Register id=0 handle=0000000023B44D18>0000000000000000</Register>
<Register id=0 handle=0000000023B44ED8>0000000000000000</Register>
<Register id=0 handle=0000000023B5A298>0000000000000000</Register>
<Register id=0 handle=0000000023B5A458>0000000000000000</Register>
<Register id=0 handle=0000000023B5A618>0000000000000000</Register>
<Register id=0 handle=0000000023B5A7D8>0000000000000000</Register>
<Register id=0 handle=0000000023B5A998>0000000000000000</Register>
<Register id=0 handle=0000000023B5AB58>0000000000000000</Register>
<Register id=0 handle=0000000023B5AD18>0000000000000000</Register>
<Register id=0 handle=0000000023B5AED8>0000000000000000</Register>
<Register id=0 handle=0000000023B5C598>0000000000000000</Register>
<Register id=0 handle=0000000023B5C758>0000000000000000</Register>
<Register id=0 handle=0000000023B5C918>0000000000000000</Register>
<Register id=0 handle=0000000023B5CAD8>0000000000000000</Register>
<Register id=0 handle=0000000023B5CC98>0000000000000000</Register>
<Register id=0 handle=0000000023B5CE58>0000000000000000</Register>
<Register id=0 handle=0000000023B5D018>0000000000000000</Register>
<Register id=0 handle=0000000023B5D1D8>0000000000000000</Register>
<Register id=0 handle=0000000023B5D398>0000000000000000</Register>
<Register id=0 handle=0000000023B64A58>0000000000000000</Register>
<Register id=0 handle=0000000023B64C18>0000000000000000</Register>
<Register id=0 handle=0000000023B64DD8>0000000000000000</Register>
<Register id=0 handle=0000000023B64F98>0000000000000000</Register>
<Register id=0 handle=0000000023B65158>0000000000000000</Register>
<Register id=0 handle=0000000023B65318>0000000000000000</Register>
<Register id=0 handle=0000000023B66658>0000000000000000</Register>
<Register id=0 handle=0000000023B66818>0000000000000000</Register>
<Register id=0 handle=0000000023B669D8>0000000000000000</Register>
<Register id=0 handle=0000000023B66B98>0000000000000000</Register>
<Register id=0 handle=0000000023B66D58>0000000000000000</Register>
<Register id=0 handle=0000000023B66F18>0000000000000000</Register>
<Register id=0 handle=0000000023B670D8>0000000000000000</Register>
<Register id=0 handle=0000000023B67618>0000000000000000</Register>
<Register id=0 handle=0000000023B677D8>0000000000000000</Register>
<Register id=0 handle=0000000023B67998>0000000000000000</Register>
<Register id=0 handle=0000000023B67B58>0000000000000000</Register>
<Register id=0 handle=0000000023B67D18>0000000000000000</Register>
<Register id=0 handle=0000000023B67ED8>0000000000000000</Register>
<Register id=0 handle=0000000023B68098>0000000000000000</Register>
<Register id=0 handle=0000000023B72758>0000000000000000</Register>
<Register id=0 handle=0000000023B72AD8>0000000000000000</Register>
<Register id=0 handle=0000000023B72E58>0000000000000000</Register>
<Register id=0 handle=0000000037474898>0000000000000000</Register>
<Register id=0 handle=0000000037474A58>0000000000000000</Register>
<Register id=0 handle=0000000037474C18>0000000000000000</Register>
<Register id=0 handle=0000000037474DD8>0000000000000000</Register>
<Register id=0 handle=0000000037474F98>0000000000000000</Register>
<Register id=0 handle=0000000037475158>0000000000000000</Register>
<Register id=0 handle=0000000037475318>0000000000000000</Register>
<Register id=0 handle=00000000374754D8>0000000000000000</Register>
<Register id=0 handle=0000000037475698>0000000000000000</Register>
<Register id=0 handle=0000000037475858>0000000000000000</Register>
<Register id=0 handle=0000000037475A18>0000000000000000</Register>
<Register id=0 handle=0000000037475BD8>0000000000000000</Register>
<Register id=0 handle=0000000037475D98>0000000000000000</Register>
<Register id=0 handle=0000000037475F58>0000000000000000</Register>
<Register id=0 handle=0000000037476118>0000000000000000</Register>
<Register id=1 handle=0000000023ACF4D8>0000000000000000</Register>
<Register id=1 handle=0000000023ACF858>0000000000000000</Register>
<Register id=1 handle=0000000023ACFBD8>0000000000000000</Register>
<Register id=1 handle=0000000023ACFF58>0000000000000000</Register>
<Register id=1 handle=0000000023AD02D8>0000000000000000</Register>
<Register id=1 handle=0000000023AD0698>0000000000000000</Register>
<Register id=1 handle=0000000023B2F918>0000000000000000</Register>
<Register id=1 handle=0000000023B2FAD8>0000000000000000</Register>
<Register id=1 handle=0000000023B2FC98>0000000000000000</Register>
<Register id=1 handle=0000000023B2FE58>0000000000000000</Register>
<Register id=1 handle=0000000023B30018>0000000000000000</Register>
<Register id=1 handle=0000000023B31658>0000000000000000</Register>
<Register id=1 handle=0000000023B31818>0000000000000000</Register>
<Register id=1 handle=0000000023B319D8>0000000000000000</Register>
<Register id=1 handle=0000000023B31B98>0000000000000000</Register>
<Register id=1 handle=0000000023B31D58>0000000000000000</Register>
<Register id=1 handle=0000000023B31F18>0000000000000000</Register>
<Register id=1 handle=0000000023B320D8>0000000000000000</Register>
<Register id=1 handle=0000000023B32298>0000000000000000</Register>
<Register id=1 handle=0000000023B32458>0000000000000000</Register>
<Register id=1 handle=0000000023B32618>0000000000000000</Register>
<Register id=1 handle=0000000023B327D8>0000000000000000</Register>
<Register id=1 handle=0000000023B32998>0000000000000000</Register>
<Register id=1 handle=0000000023B32B58>0000000000000000</Register>
<Register id=1 handle=0000000023B32D18>0000000000000000</Register>
<Register id=1 handle=0000000023B32ED8>0000000000000000</Register>
<Register id=1 handle=0000000023B33098>0000000000000000</Register>
<Register id=1 handle=0000000023B33258>0000000000000000</Register>
<Register id=1 handle=0000000023B33418>0000000000000000</Register>
<Register id=1 handle=0000000023B37658>0000000000000000</Register>
<Register id=1 handle=0000000023B44298>0000000000000000</Register>
<Register id=1 handle=0000000023B44458>0000000000000000</Register>
<Register id=1 handle=0000000023B44618>0000000000000000</Register>
<Register id=1 handle=0000000023B447D8>0000000000000000</Register>
<Register id=1 handle=0000000023B44998>0000000000000000</Register>
<Register id=1 handle=0000000023B44B58>0000000000000000</Register>
<Register id=1 handle=0000000023B44D18>0000000000000000</Register>
<Register id=1 handle=0000000023B44ED8>0000000000000000</Register>
<Register id=1 handle=0000000023B5A298>0000000000000000</Register>
<Register id=1 handle=0000000023B5A458>0000000000000000</Register>
<Register id=1 handle=0000000023B5A618>0000000000000000</Register>
<Register id=1 handle=0000000023B5A7D8>0000000000000000</Register>
<Register id=1 handle=0000000023B5A998>0000000000000000</Register>
<Register id=1 handle=0000000023B5AB58>0000000000000000</Register>
<Register id=1 handle=0000000023B5AD18>0000000000000000</Register>
<Register id=1 handle=0000000023B5AED8>0000000000000000</Register>
<Register id=1 handle=0000000023B5C598>0000000000000000</Register>
<Register id=1 handle=0000000023B5C758>0000000000000000</Register>
<Register id=1 handle=0000000023B5C918>0000000000000000</Register>
<Register id=1 handle=0000000023B5CAD8>0000000000000000</Register>
<Register id=1 handle=0000000023B5CC98>0000000000000000</Register>
<Register id=1 handle=0000000023B5CE58>0000000000000000</Register>
<Register id=1 handle=0000000023B5D018>0000000000000000</Register>
<Register id=1 handle=0000000023B5D1D8>0000000000000000</Register>
<Register id=1 handle=0000000023B5D398>0000000000000000</Register>
<Register id=1 handle=0000000023B64A58>0000000000000000</Register>
<Register id=1 handle=0000000023B64C18>0000000000000000</Register>
<Register id=1 handle=0000000023B64DD8>0000000000000000</Register>
<Register id=1 handle=0000000023B64F98>0000000000000000</Register>
<Register id=1 handle=0000000023B65158>0000000000000000</Register>
<Register id=1 handle=0000000023B65318>0000000000000000</Register>
<Register id=1 handle=0000000023B66658>0000000000000000</Register>
<Register id=1 handle=0000000023B66818>0000000000000000</Register>
<Register id=1 handle=0000000023B669D8>0000000000000000</Register>
<Register id=1 handle=0000000023B66B98>0000000000000000</Register>
<Register id=1 handle=0000000023B66D58>0000000000000000</Register>
<Register id=1 handle=0000000023B66F18>0000000000000000</Register>
<Register id=1 handle=0000000023B670D8>0000000000000000</Register>
<Register id=1 handle=0000000023B67618>0000000000000000</Register>
<Register id=1 handle=0000000023B677D8>0000000000000000</Register>
<Register id=1 handle=0000000023B67998>0000000000000000</Register>
<Register id=1 handle=0000000023B67B58>0000000000000000</Register>
<Register id=1 handle=0000000023B67D18>0000000000000000</Register>
<Register id=1 handle=0000000023B67ED8>0000000000000000</Register>
<Register id=1 handle=0000000023B68098>0000000000000000</Register>
<Register id=1 handle=0000000023B72758>0000000000000000</Register>
<Register id=1 handle=0000000023B72AD8>0000000000000000</Register>
<Register id=1 handle=0000000023B731D8>0000000000000000</Register>
<Register id=1 handle=0000000037474898>0000000000000000</Register>
<Register id=1 handle=0000000037474A58>0000000000000000</Register>
<Register id=1 handle=0000000037474C18>0000000000000000</Register>
<Register id=1 handle=0000000037474DD8>0000000000000000</Register>
<Register id=1 handle=0000000037474F98>0000000000000000</Register>
<Register id=1 handle=0000000037475158>0000000000000000</Register>
<Register id=1 handle=0000000037475318>0000000000000000</Register>
<Register id=1 handle=00000000374754D8>0000000000000000</Register>
<Register id=1 handle=0000000037475698>0000000000000000</Register>
<Register id=1 handle=0000000037475858>0000000000000000</Register>
<Register id=1 handle=0000000037475A18>0000000000000000</Register>
<Register id=1 handle=0000000037475BD8>0000000000000000</Register>
<Register id=1 handle=0000000037475D98>0000000000000000</Register>
<Register id=1 handle=0000000037475F58>0000000000000000</Register>
<Register id=1 handle=0000000037476118>0000000000000000</Register>
<Register id=2 handle=0000000023B11298>0000000000000000</Register>
<Register id=3 handle=0000000023B11458>0000000000000000</Register>
<Register id=8 handle=00000000003DA198>9930231699ee2ba7</Register>
<Register id=120 handle=00000000003B9B98>0000000000000000</Register>
<Register id=125 handle=00000000003B9898>24a83fdae0465bcc</Register>
<DepthTarget handle=0000000023B26318>dc4dc0c77cb2b882</DepthTarget>
</PixelShader>
[/code]
I guess the textures of id=0 are the sky textures (they were a lot when I dumped them. It's a nightmare to identify and retexture them).
Question number 2 (well, more than one question): I don't understand this example:
[code]
[ShaderOverrideHUD1]
Hash=7ff9e9526ba34616 <---- Use the PS, not VS
x2=ps-t0
[/code]
I suppose that I have to put the ps hash (b50a9fff61b7bf45) after "Hash=", like when I disabled some pixel shaders there with other games.
- But what is "x2"? A constant defined in the IniParams section?
- Do I have to use "ps-t0" as is like that?
- Is "t0" the id of textures that won't be included in the shader fix, or are they the only ones that WILL be affected?
- In both cases, would I have to put "ps-t0-t1-t2..." if I wanted to disable/enable the coordinate override (enable or disable depending on the previous answer) in more than one texture id?
After the "x2=ps-t0" line I added "x=100" below, to see if multiplying the coordinates by "iniparams.x" would apply it only to the sky, but it was still applying to everything.
Sorry for having so many questions. I'm pretty new at this and to HLSL, and I'm sure I'm making many mistakes.
Edit: bonus curiosity. I've seen some pixel shaders that are disabled after being dumped, and then I saw they have this condition: "if (-1 != 0) discard;". I wonder why. I just comment that line and it works normally again.
Edit2: is there a way to make 3Dmigoto apply the shader fixes to people without 3D Vision? Even if the hunting mode HUD is there when my emitter is disconnected, the fixes don't load. I ask because I'm also adapting the HUD of the game to 16:9 (something that wouldn't be perfect just by editing textures), and that doesn't require stereo parameters.
Last edit: what I'm trying to do in the case of the sky is more like "apply this vertex shader change ONLY to this pixel shader". But affecting some textures of one pixel shader will also be useful for HUD things that I've changed in a pixel shader.
I need a bit of help with the new texture filtering feature. The story:
In Zelda Ocarina of Time (in Dolphin), there are just a few vertex shaders (around 11 in the area I'm trying) and a bunch more pixel shaders (around 26). I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.
It worked and it looks good. But there are so few vertex shaders that everyone of them has to affect a variety of things. Not only the sky was pushed to depth, but Navi's circular body also gained depth (it's farther than her wings), and heart pieces and the spiritual stones are also "disassembled" now.
Question number 1: are the coordinates that the pixel shader receives set in stone? I sometimes tried to change some of the inputs of the main method of the pixel shader right at the start of the main method, but it never worked. If the answer is yes, it's probably the reason the new texture filtering exists.
In the "ShaderUsage.txt" file, I identified the vertex and pixel shaders of the sky:
I need a bit of help with the new texture filtering feature. The story:
In Zelda Ocarina of Time (in Dolphin), there are just a few vertex shaders (around 11 in the area I'm trying) and a bunch more pixel shaders (around 26). I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.
It worked and it looks good. But there are so few vertex shaders that everyone of them has to affect a variety of things. Not only the sky was pushed to depth, but Navi's circular body also gained depth (it's farther than her wings), and heart pieces and the spiritual stones are also "disassembled" now.
Question number 1: are the coordinates that the pixel shader receives set in stone? I sometimes tried to change some of the inputs of the main method of the pixel shader, but it never worked. If the answer is yes, it's probably the reason the new texture filtering exists.
In the "ShaderUsage.txt" file, I identified the vertex and pixel shaders of the sky when I dumped the pixel shader again:
I guess the textures of id=0 are the sky textures (they were a lot when I dumped them. It's a nightmare to identify and retexture them).
Question number 2 (well, more than one question): I don't understand this example:
[ShaderOverrideHUD1]
Hash=7ff9e9526ba34616 <---- Use the PS, not VS
x2=ps-t0
I suppose that I have to put the ps hash (b50a9fff61b7bf45) after "Hash=", like when I disabled some pixel shaders there with other games.
- But what is "x2"? A constant defined in the IniParams section?
- Do I have to use "ps-t0" as is like that?
- Is "t0" the id of textures that won't be included in the shader fix, or are they the only ones that WILL be affected?
- In both cases, would I have to put "ps-t0-t1-t2..." if I wanted to disable/enable the coordinate override (enable or disable depending on the previous answer) in more than one texture id?
After the "x2=ps-t0" line I added "x=100" below, to see if multiplying the coordinates by "iniparams.x" would apply it only to the sky, but it was still applying to everything.
Sorry for having so many questions. I'm pretty new at this and to HLSL, and I'm sure I'm making many mistakes.
Edit: bonus curiosity. I've seen some pixel shaders that are disabled after being dumped, and then I saw they have this condition: "if (-1 != 0) discard;". I wonder why. I just comment that line and it works normally again.
Edit2: is there a way to make 3Dmigoto apply the shader fixes to people without 3D Vision? Even if the hunting mode HUD is there when my emitter is disconnected, the fixes don't load. I ask because I'm also adapting the HUD of the game to 16:9 (something that wouldn't be perfect just by editing textures), and that doesn't require stereo parameters.
Last edit: what I'm trying to do in the case of the sky is more like "apply this vertex shader change ONLY to this pixel shader". But affecting some textures of one pixel shader will also be useful for HUD things that I've changed in a pixel shader.
Rather than using texture filtering, I'd suggest using partner shader filtering:
[code]
[ShaderOverrideSkyVS]
Hash=7592a24e6fae0825
partner=b50a9fff61b7bf45
[/code]
That's the basic form of partner shader filtering - that tells 3DMigoto to use your replacement vertex shader only when the pixel shader that matches the partner hash is active, and will use the default from the game otherwise.
There's also an advanced form which I haven't advertised as it's not (yet) an explicit feature and is relying on the order that 3DMigoto shader overrides to work. Here is how I use this in Lichdom:
[code]
; Partner shader filtering. Currently relies on the fact that 3DMigoto
; processes the vertex shader override before the pixel shader override to set
; y2 to 0 when any non-specified pixel shader is in use. TODO: Implement single
; draw call duration in 3DMigoto to make this feature explicit.
; This shader is responsible for a few effects, one of which (the wet rocks
; around one of the waterfalls in the desert level) requires the stereo
; correction to be applied, the others don't.
[ShaderOverrideWetRocksDecalsEtcVS]
Hash = e40b51d48a2da321
y2 = 0
[ShaderOverrideWetRocksPS]
Hash = 6f40f49445e70982
y2 = 1
[/code]
Then in the vertex shader:
[code]
// Need to apply the stereo correction when this shader is used for wet rocks
// to stop them clipping, but don't want to apply it when the shader is used
// for decals. y2 is set to 1 only when the wet rocks pixel shader is active:
float4 wet_rocks = IniParams.Load(int2(2,0));
if (wet_rocks.y) {
// Apply stereo correction to prevent wet rocks clipping around desert waterfall:
float4 stereo = StereoParams.Load(0);
o0.x += stereo.x * (o0.w - stereo.y);
}
[/code]
The reason this works, is that the vertex shader override will always set y2 to 0 first, then if that pixel shader is active it will then set y2 to 1. This can be expanded if necessary to match more pixel shaders.
You can find examples of both forms of partner shader filtering in the Lichdom Battlemage fix:
https://github.com/DarkStarSword/3d-fixes/blob/master/Lichdom%20Battlemage/d3dx.ini
On to your other questions:
[quote]I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.[/quote]
That's a good approach that does not rely on getting the separation + convergence from Dolphin :) If you did have access to those values, a better approach would be to use x=x+separation*convergence which will move the sky to infinity (multiplying by 100 will move it back quite a way, but not necessarily to infinity).
[quote]Question number 1: are the coordinates that the pixel shader receives set in stone? I sometimes tried to change some of the inputs of the main method of the pixel shader right at the start of the main method, but it never worked. If the answer is yes, it's probably the reason the new texture filtering exists.[/quote]
The position will be set by this stage, but not the texture coordinates - depending on the effect adjusting the texcoords in the pixel shader may work so long as the position covers the whole effect, but in other cases the position will have to be adjusted in the vertex shader (or in some cases domain or geometry shader).
[quote]In the "ShaderUsage.txt" file, I identified the vertex and pixel shaders of the sky when I dumped the pixel shader again:
[code]
<PixelShader hash="b50a9fff61b7bf45">
<ParentVertexShaders>7592a24e6fae0825 </ParentVertexShaders>
<Register id=0 handle=0000000023ACF4D8>0000000000000000</Register>
<snip>
<Register id=1 handle=0000000037476118>0000000000000000</Register>
<Register id=2 handle=0000000023B11298>0000000000000000</Register>
<Register id=3 handle=0000000023B11458>0000000000000000</Register>
<Register id=8 handle=00000000003DA198>9930231699ee2ba7</Register>
<snip>
</PixelShader>
[/code][/quote]
This is curious - none of the textures in slots 0, 1, 2 or 3 had hashes calculated by 3DMigoto (all are 0000000000000000). These may be 1 dimensional textures, which we don't currently calculate a hash for and currently cannot be used for texture filtering. If they are 2D or 3D textures we would need to work out why they weren't hashed. Texture slot 8 does have a hash, but as only a single texture was ever set in that slot it would be useless for filtering as well.
[quote]Question number 2 (well, more than one question): I don't understand this example:
[code]
[ShaderOverrideHUD1]
Hash=7ff9e9526ba34616 <---- Use the PS, not VS
x2=ps-t0
[/code]
I suppose that I have to put the ps hash (b50a9fff61b7bf45) after "Hash=", like when I disabled some pixel shaders there with other games.[/quote]
It is actually intended to be the vertex shader hash (well - whichever shader you are adjusting), but it just so happens that either hash will work (there is something strange happening in Crysis which prevents the vertex shader hash working there so DHR used the pixel shader hash. Not sure why yet - the vertex shader hash works fine in Far Cry 4 and Lichdom).
[quote]- But what is "x2"? A constant defined in the IniParams section?[/quote]
Yes - I added extra capacity to the IniParams texture so the new features could use it and not have to worry about running out of slots. In the ini file these use the form x,y,z,w,x1,y1,z1,w1,x2,y2,...,z7,w7 (32 slots total). In the shader you use this form to load the extended slots - the number matches the first value in the int2(...), and the letter is the component of that register:
[code]float4 wet_rocks = IniParams.Load(int2(2,0));[/code]
[quote]- Do I have to use "ps-t0" as is like that?[/quote]
That indicates which texture slot is being checked - in that example, it's checking the hash in "pixel shader texture slot 0". As a more esoteric example, you could check the texture in "domain shader texture slot 3" with ds-t3.
[quote]- Is "t0" the id of textures that won't be included in the shader fix, or are they the only ones that WILL be affected?[/quote]That's just the slot it checks - it will be up to your code in the shader to decide what to do based on the texture that is in that slot. You will also need to define [TextureOverride] sections for the textures of interest, which will define what value ends up in the ini param. If there is no TextureOverride for a given texture it will get 0, if there is a [TextureOverride] for it it will get 1 (by default). You can also set filter_index inside the [TextureOverride] section to set a different value if you need to do something more sophisticated.
[quote]- In both cases, would I have to put "ps-t0-t1-t2..." if I wanted to disable/enable the coordinate override (enable or disable depending on the previous answer) in more than one texture id?[/quote]
No, you would never use that form as you can only specify one texture slot per ini param (pretty sure I made 3DMigoto give you an error tone if you tried that). The logic to decide what to do based on the texture goes inside the shader giving you maximum flexibility to do whatever you need. If you did need to check additional texture slots (which DHR needed in the Crysis 3 fix) you would add them on a separate line and use a different ini param.
[quote]After the "x2=ps-t0" line I added "x=100" below, to see if multiplying the coordinates by "iniparams.x" would apply it only to the sky, but it was still applying to everything.[/quote]That would set x2 to the result of the texture filter and x to 100 whenever that shader is used - the later functionality is really intended for partner shader filtering and scene detection (coming soon). Those two lines are independent of each other as I'm trying to avoid having too much conditional logic in 3DMigoto itself (there is a *LOT* of subtly different things people may need to do, which would lead to a metric tonne of edge cases in 3DMigoto if I tried to implement all the logic there, and I don't want 3DMigoto to end up like the nvidia driver and break everything whenever we try to work around a new edge case).
[quote]Edit: bonus curiosity. I've seen some pixel shaders that are disabled after being dumped, and then I saw they have this condition: "if (-1 != 0) discard;". I wonder why. I just comment that line and it works normally again.[/quote]That looks like a decompiler bug as there is no way that conditional would have made it into the original shader - Bo3b?
[quote]Edit2: is there a way to make 3Dmigoto apply the shader fixes to people without 3D Vision? Even if the hunting mode HUD is there when my emitter is disconnected, the fixes don't load. I ask because I'm also adapting the HUD of the game to 16:9 (something that wouldn't be perfect just by editing textures), and that doesn't require stereo parameters.[/quote]
I know bo3b was trying to make it work without 3D Vision as another modder wanted to use it to just remove post processing effects, but it was obviously a lower priority... bo3b?
[quote]Last edit: what I'm trying to do in the case of the sky is more like "apply this vertex shader change ONLY to this pixel shader".[/quote]Exactly :) Glad to see you are thinking along the right lines, now you know about partner shader filtering hopefully you can put it to good use :)
[quote]But affecting some textures of one pixel shader will also be useful for HUD things that I've changed in a pixel shader.[/quote]Is that using this same shader or a different one? If it is this one we will need to work out why the textures didn't have their hashes calculated and you would need to use the advanced form of partner shader filtering I detailed above (as the simple form won't allow both of these features to be used together). If it's a different shader, check to see if it has texture hashes in the ShaderUsage.txt.
That's the basic form of partner shader filtering - that tells 3DMigoto to use your replacement vertex shader only when the pixel shader that matches the partner hash is active, and will use the default from the game otherwise.
There's also an advanced form which I haven't advertised as it's not (yet) an explicit feature and is relying on the order that 3DMigoto shader overrides to work. Here is how I use this in Lichdom:
; Partner shader filtering. Currently relies on the fact that 3DMigoto
; processes the vertex shader override before the pixel shader override to set
; y2 to 0 when any non-specified pixel shader is in use. TODO: Implement single
; draw call duration in 3DMigoto to make this feature explicit.
; This shader is responsible for a few effects, one of which (the wet rocks
; around one of the waterfalls in the desert level) requires the stereo
; correction to be applied, the others don't.
[ShaderOverrideWetRocksDecalsEtcVS]
Hash = e40b51d48a2da321
y2 = 0
[ShaderOverrideWetRocksPS]
Hash = 6f40f49445e70982
y2 = 1
Then in the vertex shader:
// Need to apply the stereo correction when this shader is used for wet rocks
// to stop them clipping, but don't want to apply it when the shader is used
// for decals. y2 is set to 1 only when the wet rocks pixel shader is active:
float4 wet_rocks = IniParams.Load(int2(2,0));
if (wet_rocks.y) {
// Apply stereo correction to prevent wet rocks clipping around desert waterfall:
float4 stereo = StereoParams.Load(0);
o0.x += stereo.x * (o0.w - stereo.y);
}
The reason this works, is that the vertex shader override will always set y2 to 0 first, then if that pixel shader is active it will then set y2 to 1. This can be expanded if necessary to match more pixel shaders.
I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.
That's a good approach that does not rely on getting the separation + convergence from Dolphin :) If you did have access to those values, a better approach would be to use x=x+separation*convergence which will move the sky to infinity (multiplying by 100 will move it back quite a way, but not necessarily to infinity).
Question number 1: are the coordinates that the pixel shader receives set in stone? I sometimes tried to change some of the inputs of the main method of the pixel shader right at the start of the main method, but it never worked. If the answer is yes, it's probably the reason the new texture filtering exists.
The position will be set by this stage, but not the texture coordinates - depending on the effect adjusting the texcoords in the pixel shader may work so long as the position covers the whole effect, but in other cases the position will have to be adjusted in the vertex shader (or in some cases domain or geometry shader).
In the "ShaderUsage.txt" file, I identified the vertex and pixel shaders of the sky when I dumped the pixel shader again:
This is curious - none of the textures in slots 0, 1, 2 or 3 had hashes calculated by 3DMigoto (all are 0000000000000000). These may be 1 dimensional textures, which we don't currently calculate a hash for and currently cannot be used for texture filtering. If they are 2D or 3D textures we would need to work out why they weren't hashed. Texture slot 8 does have a hash, but as only a single texture was ever set in that slot it would be useless for filtering as well.
Question number 2 (well, more than one question): I don't understand this example:
[ShaderOverrideHUD1]
Hash=7ff9e9526ba34616 <---- Use the PS, not VS
x2=ps-t0
I suppose that I have to put the ps hash (b50a9fff61b7bf45) after "Hash=", like when I disabled some pixel shaders there with other games.
It is actually intended to be the vertex shader hash (well - whichever shader you are adjusting), but it just so happens that either hash will work (there is something strange happening in Crysis which prevents the vertex shader hash working there so DHR used the pixel shader hash. Not sure why yet - the vertex shader hash works fine in Far Cry 4 and Lichdom).
- But what is "x2"? A constant defined in the IniParams section?
Yes - I added extra capacity to the IniParams texture so the new features could use it and not have to worry about running out of slots. In the ini file these use the form x,y,z,w,x1,y1,z1,w1,x2,y2,...,z7,w7 (32 slots total). In the shader you use this form to load the extended slots - the number matches the first value in the int2(...), and the letter is the component of that register:
float4 wet_rocks = IniParams.Load(int2(2,0));
- Do I have to use "ps-t0" as is like that?
That indicates which texture slot is being checked - in that example, it's checking the hash in "pixel shader texture slot 0". As a more esoteric example, you could check the texture in "domain shader texture slot 3" with ds-t3.
- Is "t0" the id of textures that won't be included in the shader fix, or are they the only ones that WILL be affected?
That's just the slot it checks - it will be up to your code in the shader to decide what to do based on the texture that is in that slot. You will also need to define [TextureOverride] sections for the textures of interest, which will define what value ends up in the ini param. If there is no TextureOverride for a given texture it will get 0, if there is a [TextureOverride] for it it will get 1 (by default). You can also set filter_index inside the [TextureOverride] section to set a different value if you need to do something more sophisticated.
- In both cases, would I have to put "ps-t0-t1-t2..." if I wanted to disable/enable the coordinate override (enable or disable depending on the previous answer) in more than one texture id?
No, you would never use that form as you can only specify one texture slot per ini param (pretty sure I made 3DMigoto give you an error tone if you tried that). The logic to decide what to do based on the texture goes inside the shader giving you maximum flexibility to do whatever you need. If you did need to check additional texture slots (which DHR needed in the Crysis 3 fix) you would add them on a separate line and use a different ini param.
After the "x2=ps-t0" line I added "x=100" below, to see if multiplying the coordinates by "iniparams.x" would apply it only to the sky, but it was still applying to everything.
That would set x2 to the result of the texture filter and x to 100 whenever that shader is used - the later functionality is really intended for partner shader filtering and scene detection (coming soon). Those two lines are independent of each other as I'm trying to avoid having too much conditional logic in 3DMigoto itself (there is a *LOT* of subtly different things people may need to do, which would lead to a metric tonne of edge cases in 3DMigoto if I tried to implement all the logic there, and I don't want 3DMigoto to end up like the nvidia driver and break everything whenever we try to work around a new edge case).
Edit: bonus curiosity. I've seen some pixel shaders that are disabled after being dumped, and then I saw they have this condition: "if (-1 != 0) discard;". I wonder why. I just comment that line and it works normally again.
That looks like a decompiler bug as there is no way that conditional would have made it into the original shader - Bo3b?
Edit2: is there a way to make 3Dmigoto apply the shader fixes to people without 3D Vision? Even if the hunting mode HUD is there when my emitter is disconnected, the fixes don't load. I ask because I'm also adapting the HUD of the game to 16:9 (something that wouldn't be perfect just by editing textures), and that doesn't require stereo parameters.
I know bo3b was trying to make it work without 3D Vision as another modder wanted to use it to just remove post processing effects, but it was obviously a lower priority... bo3b?
Last edit: what I'm trying to do in the case of the sky is more like "apply this vertex shader change ONLY to this pixel shader".
Exactly :) Glad to see you are thinking along the right lines, now you know about partner shader filtering hopefully you can put it to good use :)
But affecting some textures of one pixel shader will also be useful for HUD things that I've changed in a pixel shader.
Is that using this same shader or a different one? If it is this one we will need to work out why the textures didn't have their hashes calculated and you would need to use the advanced form of partner shader filtering I detailed above (as the simple form won't allow both of these features to be used together). If it's a different shader, check to see if it has texture hashes in the ShaderUsage.txt.
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
If you wanted to look at a practical example of texture filtering, here's an example from Far Cry 4 (this update has not been released on the blog yet):
https://github.com/bo3b/3Dmigoto/commit/9550f74f7d400470f40adb30188ea7862fa0d109
And a followup fix that added partner shader filtering among other things to fix up some new issues that the above adjustment created:
https://github.com/bo3b/3Dmigoto/commit/88dfaacd11ee496bb2edc839e1f203edfa147289
DHR also uses texture filtering in the Crysis 3 WIP which would be worth taking a look at.
Thanks for the answers! Partner shader filtering is just what I felt I needed. I'll answer your questions and comment some things when I get home. I'm at work and using my phone so I can't say much now. I'll double post in four hours or so.
Thanks for the answers! Partner shader filtering is just what I felt I needed. I'll answer your questions and comment some things when I get home. I'm at work and using my phone so I can't say much now. I'll double post in four hours or so.
Okay, now I'm using my PC so I can explain myself freely.
[quote=""]Rather than using texture filtering, I'd suggest using partner shader filtering:[/quote]
Thanks! It worked perfectly. And now I've seen that there's an example in the d3dx.ini. I don't know how I missed it before.
[quote=""]
You can find examples of both forms of partner shader filtering in the Lichdom Battlemage fix:
https://github.com/DarkStarSword/3d-fixes/blob/master/Lichdom%20Battlemage/d3dx.ini[/quote]
Thanks for the examples and explanation.
[quote=""]
[quote]I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.[/quote]
That's a good approach that does not rely on getting the separation + convergence from Dolphin :) If you did have access to those values, a better approach would be to use x=x+separation*convergence which will move the sky to infinity (multiplying by 100 will move it back quite a way, but not necessarily to infinity).[/quote]
Nah, using "v3.xyz+=v3.xyz+separation*convergence" doesn't push the sky to depth. Maybe because Dolphin uses its own separation and convergence? The values 3Dmigoto shown in the game are the Nvidia ones, and they don't affect the game at all.
Using "v3.xyz=v3.xyz*115" worked the best. Multiplying by 116 made the corners of the sky (it's very blocky) be behind a black surface. So 115 times the depth is the maximum it can go. And it's almost perfect at least.
[quote=""]
I'm trying to avoid having too much conditional logic in 3DMigoto itself[/quote]
Me too. I would prefer to fix everything in the shader files instead of the ini file, because I would like to use the same ini for multiple games. But because of the partner shader thing my dream is broken :p.
[quote=""][quote]Last edit: what I'm trying to do in the case of the sky is more like "apply this vertex shader change ONLY to this pixel shader".[/quote]Exactly :) Glad to see you are thinking along the right lines, now you know about partner shader filtering hopefully you can put it to good use :)[/quote]
All thanks to your advice :).
[quote=""][quote]But affecting some textures of one pixel shader will also be useful for HUD things that I've changed in a pixel shader.[/quote]Is that using this same shader or a different one?[/quote]
A different one. There's for example a pixel shader that affects almost all HUD elements, but I've been thinking about leaving the minimap texture intact, because the minimap arrows are controlled by a different vertex shader and I still haven't found a way to position them correctly. And other HUD things are moved too to the left, etc.
[quote=""]If it's a different shader, check to see if it has texture hashes in the ShaderUsage.txt.
[/quote]
I'll do.
I hope I can make the perfect 3D Ocarina of Time experience. And it will be a good practice for other games (Shadow Warrior, because I got stuck with the shadows).
Edit: by the way, I'm getting tired of driver and application crashes. The VRAM is filled quickly after a few times entering and exiting fullscreen. Every alt+enter adds a few hundred MB. I guess It's Dolphin's fault, because Shadow Warrior did the same.
I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.
That's a good approach that does not rely on getting the separation + convergence from Dolphin :) If you did have access to those values, a better approach would be to use x=x+separation*convergence which will move the sky to infinity (multiplying by 100 will move it back quite a way, but not necessarily to infinity).
Nah, using "v3.xyz+=v3.xyz+separation*convergence" doesn't push the sky to depth. Maybe because Dolphin uses its own separation and convergence? The values 3Dmigoto shown in the game are the Nvidia ones, and they don't affect the game at all.
Using "v3.xyz=v3.xyz*115" worked the best. Multiplying by 116 made the corners of the sky (it's very blocky) be behind a black surface. So 115 times the depth is the maximum it can go. And it's almost perfect at least.
said:
I'm trying to avoid having too much conditional logic in 3DMigoto itself
Me too. I would prefer to fix everything in the shader files instead of the ini file, because I would like to use the same ini for multiple games. But because of the partner shader thing my dream is broken :p.
said:
Last edit: what I'm trying to do in the case of the sky is more like "apply this vertex shader change ONLY to this pixel shader".
Exactly :) Glad to see you are thinking along the right lines, now you know about partner shader filtering hopefully you can put it to good use :)
All thanks to your advice :).
said:
But affecting some textures of one pixel shader will also be useful for HUD things that I've changed in a pixel shader.
Is that using this same shader or a different one?
A different one. There's for example a pixel shader that affects almost all HUD elements, but I've been thinking about leaving the minimap texture intact, because the minimap arrows are controlled by a different vertex shader and I still haven't found a way to position them correctly. And other HUD things are moved too to the left, etc.
said:If it's a different shader, check to see if it has texture hashes in the ShaderUsage.txt.
I'll do.
I hope I can make the perfect 3D Ocarina of Time experience. And it will be a good practice for other games (Shadow Warrior, because I got stuck with the shadows).
Edit: by the way, I'm getting tired of driver and application crashes. The VRAM is filled quickly after a few times entering and exiting fullscreen. Every alt+enter adds a few hundred MB. I guess It's Dolphin's fault, because Shadow Warrior did the same.
[quote][quote]In the "ShaderUsage.txt" file, I identified the vertex and pixel shaders of the sky when I dumped the pixel shader again:
[code]
<PixelShader hash="b50a9fff61b7bf45">
<ParentVertexShaders>7592a24e6fae0825 </ParentVertexShaders>
<Register id=0 handle=0000000023ACF4D8>0000000000000000</Register>
<snip>
<Register id=1 handle=0000000037476118>0000000000000000</Register>
<Register id=2 handle=0000000023B11298>0000000000000000</Register>
<Register id=3 handle=0000000023B11458>0000000000000000</Register>
<Register id=8 handle=00000000003DA198>9930231699ee2ba7</Register>
<snip>
</PixelShader>
[/code][/quote]This is curious - none of the textures in slots 0, 1, 2 or 3 had hashes calculated by 3DMigoto (all are 0000000000000000). These may be 1 dimensional textures, which we don't currently calculate a hash for and currently cannot be used for texture filtering. If they are 2D or 3D textures we would need to work out why they weren't hashed. Texture slot 8 does have a hash, but as only a single texture was ever set in that slot it would be useless for filtering as well.[/quote]
That is curious. It's always possible I broke something. If you are using 1.1.36, I put in some optimizations for performance that specifically bypass hash calculation for textures. It should always be working when hunting>0, but worth noting I modified that code recently.
Also worth checking the d3d11_log.txt file to see if those textures are generating exceptions. If the textures are not linearly mapped they will generate an exception which is caught and sets the hash to zero.
[quote][quote]Edit: bonus curiosity. I've seen some pixel shaders that are disabled after being dumped, and then I saw they have this condition: "if (-1 != 0) discard;". I wonder why. I just comment that line and it works normally again.[/quote]That looks like a decompiler bug as there is no way that conditional would have made it into the original shader - Bo3b?[/quote]
Yep, that sounds like a Decompiler problem. If you can give me the HLSL+ASM for the shader I can take a closer look. I haven't seen this one before.
[quote][quote]Edit2: is there a way to make 3Dmigoto apply the shader fixes to people without 3D Vision? Even if the hunting mode HUD is there when my emitter is disconnected, the fixes don't load. I ask because I'm also adapting the HUD of the game to 16:9 (something that wouldn't be perfect just by editing textures), and that doesn't require stereo parameters.[/quote]I know bo3b was trying to make it work without 3D Vision as another modder wanted to use it to just remove post processing effects, but it was obviously a lower priority... bo3b?[/quote]
Should work. Earlier I put in some checking to see if 3D was disabled and not crash based on that scenario. We might have broken that with recent changes of course, but it is intended to work for 2D as well.
This is curious - none of the textures in slots 0, 1, 2 or 3 had hashes calculated by 3DMigoto (all are 0000000000000000). These may be 1 dimensional textures, which we don't currently calculate a hash for and currently cannot be used for texture filtering. If they are 2D or 3D textures we would need to work out why they weren't hashed. Texture slot 8 does have a hash, but as only a single texture was ever set in that slot it would be useless for filtering as well.
That is curious. It's always possible I broke something. If you are using 1.1.36, I put in some optimizations for performance that specifically bypass hash calculation for textures. It should always be working when hunting>0, but worth noting I modified that code recently.
Also worth checking the d3d11_log.txt file to see if those textures are generating exceptions. If the textures are not linearly mapped they will generate an exception which is caught and sets the hash to zero.
Edit: bonus curiosity. I've seen some pixel shaders that are disabled after being dumped, and then I saw they have this condition: "if (-1 != 0) discard;". I wonder why. I just comment that line and it works normally again.
That looks like a decompiler bug as there is no way that conditional would have made it into the original shader - Bo3b?
Yep, that sounds like a Decompiler problem. If you can give me the HLSL+ASM for the shader I can take a closer look. I haven't seen this one before.
Edit2: is there a way to make 3Dmigoto apply the shader fixes to people without 3D Vision? Even if the hunting mode HUD is there when my emitter is disconnected, the fixes don't load. I ask because I'm also adapting the HUD of the game to 16:9 (something that wouldn't be perfect just by editing textures), and that doesn't require stereo parameters.
I know bo3b was trying to make it work without 3D Vision as another modder wanted to use it to just remove post processing effects, but it was obviously a lower priority... bo3b?
Should work. Earlier I put in some checking to see if 3D was disabled and not crash based on that scenario. We might have broken that with recent changes of course, but it is intended to work for 2D as well.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
[quote=""][quote][quote]I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.[/quote]That's a good approach that does not rely on getting the separation + convergence from Dolphin :) If you did have access to those values, a better approach would be to use x=x+separation*convergence which will move the sky to infinity (multiplying by 100 will move it back quite a way, but not necessarily to infinity).[/quote]
Nah, using "v3.xyz+=v3.xyz+separation*convergence" doesn't push the sky to depth. Maybe because Dolphin uses its own separation and convergence? The values 3Dmigoto shown in the game are the Nvidia ones, and they don't affect the game at all.
Using "v3.xyz=v3.xyz*115" worked the best. Multiplying by 116 made the corners of the sky (it's very blocky) be behind a black surface. So 115 times the depth is the maximum it can go. And it's almost perfect at least.[/quote]
Do you actually mean to += all xyz? Generally for skybox we only do the += .x parameter. What you are doing with "v3.xyz=v3.xyz*115" is 'puffing' up the skybox like a balloon in all dimensions. This can work and is what I did in the Psychonauts fix, but in general just doing the "v3.x+=separation*convergence" is the more correct form. (may not work here of course)
[quote][quote=""]I'm trying to avoid having too much conditional logic in 3DMigoto itself[/quote]
Me too. I would prefer to fix everything in the shader files instead of the ini file, because I would like to use the same ini for multiple games. But because of the partner shader thing my dream is broken :p.[/quote]
Ja, me too. We have some embedded conditional code that is getting at the edge of needing a rewrite because it's hard to know if we are breaking something else while fixing something.
[quote][quote=""]If it's a different shader, check to see if it has texture hashes in the ShaderUsage.txt.
[/quote]I'll do.
I hope I can make the perfect 3D Ocarina of Time experience. And it will be a good practice for other games (Shadow Warrior, because I got stuck with the shadows).
Edit: by the way, I'm getting tired of driver and application crashes. The VRAM is filled quickly after a few times entering and exiting fullscreen. Every alt+enter adds a few hundred MB. I guess It's Dolphin's fault, because Shadow Warrior did the same.[/quote][/quote]
This might be us actually. Helifax reported a similar problem that I haven't had a chance to look at. Same symptoms, leaking memory upon every alt-enter combo. There is an off chance we are leaking memory upon resets of the D3D11Device.
I think that DarkStarSword never sees this because he uses a second computer to edit live via network, without needing to switch out. I haven't seen this myself, but I do need to take a look since you are the second person to run into serious problems with it. (Probably game dependent because of how they handle device resets, but not an actual game problem.)
I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.
That's a good approach that does not rely on getting the separation + convergence from Dolphin :) If you did have access to those values, a better approach would be to use x=x+separation*convergence which will move the sky to infinity (multiplying by 100 will move it back quite a way, but not necessarily to infinity).
Nah, using "v3.xyz+=v3.xyz+separation*convergence" doesn't push the sky to depth. Maybe because Dolphin uses its own separation and convergence? The values 3Dmigoto shown in the game are the Nvidia ones, and they don't affect the game at all.
Using "v3.xyz=v3.xyz*115" worked the best. Multiplying by 116 made the corners of the sky (it's very blocky) be behind a black surface. So 115 times the depth is the maximum it can go. And it's almost perfect at least.
Do you actually mean to += all xyz? Generally for skybox we only do the += .x parameter. What you are doing with "v3.xyz=v3.xyz*115" is 'puffing' up the skybox like a balloon in all dimensions. This can work and is what I did in the Psychonauts fix, but in general just doing the "v3.x+=separation*convergence" is the more correct form. (may not work here of course)
said:I'm trying to avoid having too much conditional logic in 3DMigoto itself
Me too. I would prefer to fix everything in the shader files instead of the ini file, because I would like to use the same ini for multiple games. But because of the partner shader thing my dream is broken :p.
Ja, me too. We have some embedded conditional code that is getting at the edge of needing a rewrite because it's hard to know if we are breaking something else while fixing something.
said:If it's a different shader, check to see if it has texture hashes in the ShaderUsage.txt.
I'll do.
I hope I can make the perfect 3D Ocarina of Time experience. And it will be a good practice for other games (Shadow Warrior, because I got stuck with the shadows).
Edit: by the way, I'm getting tired of driver and application crashes. The VRAM is filled quickly after a few times entering and exiting fullscreen. Every alt+enter adds a few hundred MB. I guess It's Dolphin's fault, because Shadow Warrior did the same.
This might be us actually. Helifax reported a similar problem that I haven't had a chance to look at. Same symptoms, leaking memory upon every alt-enter combo. There is an off chance we are leaking memory upon resets of the D3D11Device.
I think that DarkStarSword never sees this because he uses a second computer to edit live via network, without needing to switch out. I haven't seen this myself, but I do need to take a look since you are the second person to run into serious problems with it. (Probably game dependent because of how they handle device resets, but not an actual game problem.)
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
[quote=""]
Do you actually mean to += all xyz? Generally for skybox we only do the += .x parameter. What you are doing with "v3.xyz=v3.xyz*115" is 'puffing' up the skybox like a balloon in all dimensions. This can work and is what I did in the Psychonauts fix, but in general just doing the "v3.x+=separation*convergence" is the more correct form. (may not work here of course)[/quote]
Nope, it doesn't work (either the stereo params aren't read properly or this skybox works different from usual). It looks the same as if I didn't try to fix it, but "v3.xyz=v3.xyz*115" works. By the way, if I only multiply one axis, it gets stretched in a really bad way.
[quote]
This might be us actually. Helifax reported a similar problem that I haven't had a chance to look at. Same symptoms, leaking memory upon every alt-enter combo. There is an off chance we are leaking memory upon resets of the D3D11Device.[/quote]
OK. I'll test this night if there are memory leaks without 3Dmigoto.
[quote]Yep, that sounds like a Decompiler problem. If you can give me the HLSL+ASM for the shader I can take a closer look. I haven't seen this one before.[/quote]
Here's an example at line 78:
[code]
//Zelda OOT: non moving hearts (normal).
cbuffer _Globals : register(b0)
{
int4 color[4] : packoffset(c0);
int4 k[4] : packoffset(c4);
int4 alphaRef : packoffset(c8);
float4 texdim[8] : packoffset(c9);
int4 czbias[2] : packoffset(c17);
int4 cindscale[2] : packoffset(c19);
int4 cindmtx[6] : packoffset(c21);
int4 cfogcolor : packoffset(c27);
int4 cfogi : packoffset(c28);
float4 cfogf[2] : packoffset(c29);
float4 czslope : packoffset(c31);
float4 cefbscale : packoffset(c32);
}
SamplerState samp0_s : register(s0);
Texture2DArray<float4> Tex0 : register(t0);
Texture2D<float4> StereoParams : register(t125);
Texture1D<float4> IniParams : register(t120);
void main(
float4 v0 : SV_Position0,
float4 v1 : COLOR0,
float4 v2 : COLOR1,
float4 v3 : TEXCOORD0,
float4 v4 : TEXCOORD1,
uint v5 : SV_RenderTargetArrayIndex0,
out float4 o0 : SV_Target0)
{
float4 r0,r1,r2,r3;
uint4 bitmask, uiDest;
float4 fDest;
r0.xy = texdim[0].zw * v3.xy;
r0.xy = float2(128,128) * r0.xy;
r0.xy = trunc(r0.xy);
r0.xy = texdim[0].xy * r0.xy;
r0.xy = float2(0.0078125,0.0078125) * r0.xy;
//This line changes the aspect ratio.
r0.x=r0.x*4/3;
r0.z = (uint)v5.x;
r0.xyzw = Tex0.Sample(samp0_s, r0.xyz).xyzw;
r0.xyzw = float4(255,255,255,255) * r0.xyzw;
r0.xyzw = round(r0.xyzw);
r0.xyzw = (int4)r0.xyzw;
r1.xyz = int3(255,255,255) & (int3)color[3].xyz;
r2.xyz = int3(255,255,255) & (int3)color[2].xyz;
r1.w = (int)r0.w & 255;
r0.w = color[2].w;
r3.xyzw = (int4)r0.xyzw & int4(255,255,255,255);
if (1 == 0) r0.x = 0; else if (1+7 < 32) { r0.x = (int)r0.x << (32-(1 + 7)); r0.x = (uint)r0.x >> (32-1); } else r0.x = (uint)r0.x >> 7;
if (1 == 0) r0.y = 0; else if (1+7 < 32) { r0.y = (int)r0.y << (32-(1 + 7)); r0.y = (uint)r0.y >> (32-1); } else r0.y = (uint)r0.y >> 7;
if (1 == 0) r0.z = 0; else if (1+7 < 32) { r0.z = (int)r0.z << (32-(1 + 7)); r0.z = (uint)r0.z >> (32-1); } else r0.z = (uint)r0.z >> 7;
if (1 == 0) r0.w = 0; else if (1+7 < 32) { r0.w = (int)r0.w << (32-(1 + 7)); r0.w = (uint)r0.w >> (32-1); } else r0.w = (uint)r0.w >> 7;
r0.xyzw = (int4)r0.xyzw | (int4)r3.xyzw;
bitmask.x = ((~(-1 << 8)) << 8) & 0xffffffff;
r3.x = (((uint)color[3].x << 8) & bitmask.x) | ((uint)0 & ~bitmask.x);
bitmask.y = ((~(-1 << 8)) << 8) & 0xffffffff;
r3.y = (((uint)color[3].y << 8) & bitmask.y) | ((uint)0 & ~bitmask.y);
bitmask.z = ((~(-1 << 8)) << 8) & 0xffffffff;
r3.z = (((uint)color[3].z << 8) & bitmask.z) | ((uint)0 & ~bitmask.z);
r1.xyz = (int3)-r1.xyz + (int3)r2.xyz;
r0.xyz = mad((int3)r1.xyz, (int3)r0.xyz, (int3)r3.xyz);
r0.xyz = (int3)r0.xyz + int3(128,128,128);
r0.xyz = (uint3)r0.xyz >> int3(8,8,8);
r0.xyz = max(int3(-1024,-1024,-1024), (int3)r0.xyz);
r2.xyz = min(int3(1023,1023,1023), (int3)r0.xyz);
r0.x = mad((int)r1.w, (int)r0.w, 128);
r2.w = (uint)r0.x >> 8;
r0.xyzw = (int4)r2.xyzw & int4(255,255,255,255);
r1.xy = (int2)alphaRef.xy < (int2)r0.ww;
r1.x = r1.y ? r1.x : 0;
r1.x = ~(int)r1.x;
//if (r1.x != 0) discard;
r0.xyzw = (int4)r0.xyzw;
o0.xyzw = float4(0.00392156886,0.00392156886,0.00392156886,0.00392156886) * r0.xyzw;
return;
}
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.30.9200.20789
//
// using 3Dmigoto v1.1.34 on Sun Aug 02 21:15:33 2015
//
//
// Buffer Definitions:
//
// cbuffer $Globals
// {
//
// int4 color[4]; // Offset: 0 Size: 64
// int4 k[4]; // Offset: 64 Size: 64 [unused]
// int4 alphaRef; // Offset: 128 Size: 16
// float4 texdim[8]; // Offset: 144 Size: 128
// int4 czbias[2]; // Offset: 272 Size: 32 [unused]
// int4 cindscale[2]; // Offset: 304 Size: 32 [unused]
// int4 cindmtx[6]; // Offset: 336 Size: 96 [unused]
// int4 cfogcolor; // Offset: 432 Size: 16 [unused]
// int4 cfogi; // Offset: 448 Size: 16 [unused]
// float4 cfogf[2]; // Offset: 464 Size: 32 [unused]
// float4 czslope; // Offset: 496 Size: 16 [unused]
// float4 cefbscale; // Offset: 512 Size: 16 [unused]
//
// }
//
//
// Resource Bindings:
//
// Name Type Format Dim Slot Elements
// ------------------------------ ---------- ------- ----------- ---- --------
// samp0 sampler NA NA 0 1
// Tex0 texture float4 2darray 0 1
// $Globals cbuffer NA NA 0 1
//
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Position 0 xyzw 0 POS float
// COLOR 0 xyzw 1 NONE float
// COLOR 1 xyzw 2 NONE float
// TEXCOORD 0 xyz 3 NONE float xy
// TEXCOORD 1 xyzw 4 NONE float
// SV_RenderTargetArrayIndex 0 x 5 RTINDEX uint x
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Target 0 xyzw 0 TARGET float xyzw
//
ps_5_0
dcl_globalFlags refactoringAllowed
dcl_constantbuffer cb0[10], immediateIndexed
dcl_sampler s0, mode_default
dcl_resource_texture2darray (float,float,float,float) t0
dcl_input_ps linear centroid v3.xy
dcl_input_ps_siv constant v5.x, rendertarget_array_index
dcl_output o0.xyzw
dcl_temps 4
mul r0.xy, v3.xyxx, cb0[9].zwzz
mul r0.xy, r0.xyxx, l(128.000000, 128.000000, 0.000000, 0.000000)
round_z r0.xy, r0.xyxx
mul r0.xy, r0.xyxx, cb0[9].xyxx
mul r0.xy, r0.xyxx, l(0.007813, 0.007813, 0.000000, 0.000000)
utof r0.z, v5.x
sample_indexable(texture2darray)(float,float,float,float) r0.xyzw, r0.xyzx, t0.xyzw, s0
mul r0.xyzw, r0.xyzw, l(255.000000, 255.000000, 255.000000, 255.000000)
round_ne r0.xyzw, r0.xyzw
ftoi r0.xyzw, r0.xyzw
and r1.xyz, l(255, 255, 255, 0), cb0[3].xyzx
and r2.xyz, l(255, 255, 255, 0), cb0[2].xyzx
and r1.w, r0.w, l(255)
mov r0.w, cb0[2].w
and r3.xyzw, r0.xyzw, l(255, 255, 255, 255)
ubfe r0.xyzw, l(1, 1, 1, 1), l(7, 7, 7, 7), r0.xyzw
or r0.xyzw, r0.xyzw, r3.xyzw
bfi r3.xyz, l(8, 8, 8, 0), l(8, 8, 8, 0), cb0[3].xyzx, l(0, 0, 0, 0)
iadd r1.xyz, -r1.xyzx, r2.xyzx
imad r0.xyz, r1.xyzx, r0.xyzx, r3.xyzx
iadd r0.xyz, r0.xyzx, l(128, 128, 128, 0)
ishr r0.xyz, r0.xyzx, l(8, 8, 8, 0)
imax r0.xyz, r0.xyzx, l(-1024, -1024, -1024, 0)
imin r2.xyz, r0.xyzx, l(1023, 1023, 1023, 0)
imad r0.x, r1.w, r0.w, l(128)
ishr r2.w, r0.x, l(8)
and r0.xyzw, r2.xyzw, l(255, 255, 255, 255)
ilt r1.xy, cb0[8].xyxx, r0.wwww
and r1.x, r1.y, r1.x
not r1.x, r1.x
discard_nz r1.x
itof r0.xyzw, r0.xyzw
mul o0.xyzw, r0.xyzw, l(0.003922, 0.003922, 0.003922, 0.003922)
ret
// Approximately 34 instruction slots used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
[/code]
[quote]Should work. Earlier I put in some checking to see if 3D was disabled and not crash based on that scenario. We might have broken that with recent changes of course, but it is intended to work for 2D as well.[/quote]
Weird, it's working now with the 3D emitter disconnected. Maybe a false alarm?
By the way, the key to temporarily disable all the fixes doesn't seem to always work when I'm making changes while playing. Some shaders remain fixed when I hold the key. I assigned it to F11, by the way.
Here is 3Dmigoto with the fixes I have for now for Zelda OOT. I've also included the "ShaderUsage.txt" file. Remember that it also contains shaders from other games, because I was also fixing Zelda TP, Zelda WW and Metroid Prime yesterday:
https://www.dropbox.com/s/lauy9huujlmy6ym/zeldaootfixes.7z?dl=0
Now I'm going to work. I'll be back home in 13 hours :(.
Edit: in case you want to try my fixes, the emulator is the Ishiiruka 413 build (https://forums.dolphin-emu.org/Thread-unofficial-ishiiruka-dolphin-custom-version), and the game is The Legend of Zelda, Collector's Edition (American version). I also use the texture pack port I made: https://forums.dolphin-emu.org/Thread-the-legend-of-zelda-collector-s-edition-hd-texture-pack-v0-4-patch-2-2015-05-04 (although I made a few different textures for the HUD these days).
said:
Do you actually mean to += all xyz? Generally for skybox we only do the += .x parameter. What you are doing with "v3.xyz=v3.xyz*115" is 'puffing' up the skybox like a balloon in all dimensions. This can work and is what I did in the Psychonauts fix, but in general just doing the "v3.x+=separation*convergence" is the more correct form. (may not work here of course)
Nope, it doesn't work (either the stereo params aren't read properly or this skybox works different from usual). It looks the same as if I didn't try to fix it, but "v3.xyz=v3.xyz*115" works. By the way, if I only multiply one axis, it gets stretched in a really bad way.
This might be us actually. Helifax reported a similar problem that I haven't had a chance to look at. Same symptoms, leaking memory upon every alt-enter combo. There is an off chance we are leaking memory upon resets of the D3D11Device.
OK. I'll test this night if there are memory leaks without 3Dmigoto.
Yep, that sounds like a Decompiler problem. If you can give me the HLSL+ASM for the shader I can take a closer look. I haven't seen this one before.
Should work. Earlier I put in some checking to see if 3D was disabled and not crash based on that scenario. We might have broken that with recent changes of course, but it is intended to work for 2D as well.
Weird, it's working now with the 3D emitter disconnected. Maybe a false alarm?
By the way, the key to temporarily disable all the fixes doesn't seem to always work when I'm making changes while playing. Some shaders remain fixed when I hold the key. I assigned it to F11, by the way.
Here is 3Dmigoto with the fixes I have for now for Zelda OOT. I've also included the "ShaderUsage.txt" file. Remember that it also contains shaders from other games, because I was also fixing Zelda TP, Zelda WW and Metroid Prime yesterday:
https://www.dropbox.com/s/lauy9huujlmy6ym/zeldaootfixes.7z?dl=0
Now I'm going to work. I'll be back home in 13 hours :(.
[quote="masterotaku"][quote=""]Do you actually mean to += all xyz? Generally for skybox we only do the += .x parameter. What you are doing with "v3.xyz=v3.xyz*115" is 'puffing' up the skybox like a balloon in all dimensions. This can work and is what I did in the Psychonauts fix, but in general just doing the "v3.x+=separation*convergence" is the more correct form. (may not work here of course)[/quote]
Nope, it doesn't work (either the stereo params aren't read properly or this skybox works different from usual). It looks the same as if I didn't try to fix it, but "v3.xyz=v3.xyz*115" works. By the way, if I only multiply one axis, it gets stretched in a really bad way.[/quote]
Ahh, you're not quite doing what I thought you meant - I was thinking you were adjusting the x,y,z *AND* w of the *output* position from the vertex shader, whereas you are adjusting the xyz of one of the *inputs*. Multiplying all four components of the output position by the same amount will adjust the depth without any stretching (because the perspective divide by w counters the multiply, so only the stereo correction changes).
Still, if what you have is working, go for it :)
Likewise the x+=separation*convergence would need to be applied to the output position, not the input - but you are correct that you would need the separation+convergence from Dolphin for that adjustment, not the values from 3DMigoto. I'm actually thinking it might be worthwhile submitting a patch to Dolphin to add nvapi support to synchronise their separation+convergence settings with nvidia's - since they use the same formula that would allow the values from 3DMigoto to work interchangeably and would mean the usual nvidia key bindings would work. nvapi could also possibly be used to zero out StereoTextureEnable to remove the conflict between 3D Vision Automatic and Dolphin without user intervention.
[quote]By the way, the key to temporarily disable all the fixes doesn't seem to always work when I'm making changes while playing. Some shaders remain fixed when I hold the key. I assigned it to F11, by the way.[/quote]
I've had this happen as well, but I haven't managed to work out how to reliably reproduce it to track down the cause. Anecdotally, I think I've had a shader that didn't compile (e.g. due to a syntax error) before this starts happening (possibly one already in ShaderFixes on launch, possibly when reloading... not sure), which might suggest that we have a bug in an error path... But there was enough weird stuff going on when this happened that I couldn't be sure it wasn't a driver bug mixing up shaders when I reloaded them. Definitely need to investigate this further - if you can reproduce this reliably please let us know!
[quote]Here is 3Dmigoto with the fixes I have for now for Zelda OOT.[/quote]
Sorry for the n00b question, but I'm not all that familiar with Dolphin - I have OOT on my Wii (not Wii U) virtual console - can I use that to try this fix? I guess I need to copy it off the Wii somehow - is there some documentation I should read on this? Despite working on the Wii U's CPU for bring up and testing in my day job, I never got around to doing any modding on my Wii.
I probably won't be able to look at this for at least another couple of weeks - moving to a new city...
said:Do you actually mean to += all xyz? Generally for skybox we only do the += .x parameter. What you are doing with "v3.xyz=v3.xyz*115" is 'puffing' up the skybox like a balloon in all dimensions. This can work and is what I did in the Psychonauts fix, but in general just doing the "v3.x+=separation*convergence" is the more correct form. (may not work here of course)
Nope, it doesn't work (either the stereo params aren't read properly or this skybox works different from usual). It looks the same as if I didn't try to fix it, but "v3.xyz=v3.xyz*115" works. By the way, if I only multiply one axis, it gets stretched in a really bad way.
Ahh, you're not quite doing what I thought you meant - I was thinking you were adjusting the x,y,z *AND* w of the *output* position from the vertex shader, whereas you are adjusting the xyz of one of the *inputs*. Multiplying all four components of the output position by the same amount will adjust the depth without any stretching (because the perspective divide by w counters the multiply, so only the stereo correction changes).
Still, if what you have is working, go for it :)
Likewise the x+=separation*convergence would need to be applied to the output position, not the input - but you are correct that you would need the separation+convergence from Dolphin for that adjustment, not the values from 3DMigoto. I'm actually thinking it might be worthwhile submitting a patch to Dolphin to add nvapi support to synchronise their separation+convergence settings with nvidia's - since they use the same formula that would allow the values from 3DMigoto to work interchangeably and would mean the usual nvidia key bindings would work. nvapi could also possibly be used to zero out StereoTextureEnable to remove the conflict between 3D Vision Automatic and Dolphin without user intervention.
By the way, the key to temporarily disable all the fixes doesn't seem to always work when I'm making changes while playing. Some shaders remain fixed when I hold the key. I assigned it to F11, by the way.
I've had this happen as well, but I haven't managed to work out how to reliably reproduce it to track down the cause. Anecdotally, I think I've had a shader that didn't compile (e.g. due to a syntax error) before this starts happening (possibly one already in ShaderFixes on launch, possibly when reloading... not sure), which might suggest that we have a bug in an error path... But there was enough weird stuff going on when this happened that I couldn't be sure it wasn't a driver bug mixing up shaders when I reloaded them. Definitely need to investigate this further - if you can reproduce this reliably please let us know!
Here is 3Dmigoto with the fixes I have for now for Zelda OOT.
Sorry for the n00b question, but I'm not all that familiar with Dolphin - I have OOT on my Wii (not Wii U) virtual console - can I use that to try this fix? I guess I need to copy it off the Wii somehow - is there some documentation I should read on this? Despite working on the Wii U's CPU for bring up and testing in my day job, I never got around to doing any modding on my Wii.
I probably won't be able to look at this for at least another couple of weeks - moving to a new city...
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=""]
Ahh, you're not quite doing what I thought you meant - I was thinking you were adjusting the x,y,z *AND* w of the *output* position from the vertex shader, whereas you are adjusting the xyz of one of the *inputs*. Multiplying all four components of the output position by the same amount will adjust the depth without any stretching (because the perspective divide by w counters the multiply, so only the stereo correction changes).[/quote]
Mmmm, I think I definitely tried the outputs first, but I'm gaining more knowledge every day, so maybe I did something wrong. In other pixel shaders I needed to make the changes before certain lines, because for example the same variable was doing different things after a few assignments. I better say an example, something in the line of (I'm still at work so I'm inventing this):
r0.xyzw="Something that changes position of an element"
r0.xyzw="Something that changes its color"
And the results are applied ingame without any kind of output between them, so if I did something like "r0.x=r0.x*2" it had a totally different effect if I put it before or after that second line. Is this an HLSL thing that I didn't know?
Anyway, I'll try to approach the sky vertex shader in a more correct way if possible. It was a consequence of trial and error that ended up being like that.
[quote=""]
I'm actually thinking it might be worthwhile submitting a patch to Dolphin to add nvapi support to synchronise their separation+convergence settings with nvidia's - since they use the same formula that would allow the values from 3DMigoto to work interchangeably and would mean the usual nvidia key bindings would work. nvapi could also possibly be used to zero out StereoTextureEnable to remove the conflict between 3D Vision Automatic and Dolphin without user intervention.[/quote]
That would be great, and it would allow fixes that would depend on the stereo parameters.
[quote=""]if you can reproduce this reliably please let us know![/quote]
I'll try. I think it happened after having some errors and correcting them. But I'm not sure.
[quote=""]
Sorry for the n00b question, but I'm not all that familiar with Dolphin - I have OOT on my Wii (not Wii U) virtual console - can I use that to try this fix? I guess I need to copy it off the Wii somehow - is there some documentation I should read on this? Despite working on the Wii U's CPU for bring up and testing in my day job, I never got around to doing any modding on my Wii.[/quote]
The Wii Virtual Console version.... I still haven't tried the fixes with other versions or games that contain Ocarina of Time. The texture pack worked, at least.
I think WADs can be copied to the SD card, so you can copy it to your PC and use Dolphin (that specific build I said). For Gamecube games, there are programs to dump them with the Homebrew Channel.
[quote=""]I probably won't be able to look at this for at least another couple of weeks - moving to a new city...[/quote]
Oh, good luck! And thanks for the help.
said:
Ahh, you're not quite doing what I thought you meant - I was thinking you were adjusting the x,y,z *AND* w of the *output* position from the vertex shader, whereas you are adjusting the xyz of one of the *inputs*. Multiplying all four components of the output position by the same amount will adjust the depth without any stretching (because the perspective divide by w counters the multiply, so only the stereo correction changes).
Mmmm, I think I definitely tried the outputs first, but I'm gaining more knowledge every day, so maybe I did something wrong. In other pixel shaders I needed to make the changes before certain lines, because for example the same variable was doing different things after a few assignments. I better say an example, something in the line of (I'm still at work so I'm inventing this):
r0.xyzw="Something that changes position of an element"
r0.xyzw="Something that changes its color"
And the results are applied ingame without any kind of output between them, so if I did something like "r0.x=r0.x*2" it had a totally different effect if I put it before or after that second line. Is this an HLSL thing that I didn't know?
Anyway, I'll try to approach the sky vertex shader in a more correct way if possible. It was a consequence of trial and error that ended up being like that.
said:
I'm actually thinking it might be worthwhile submitting a patch to Dolphin to add nvapi support to synchronise their separation+convergence settings with nvidia's - since they use the same formula that would allow the values from 3DMigoto to work interchangeably and would mean the usual nvidia key bindings would work. nvapi could also possibly be used to zero out StereoTextureEnable to remove the conflict between 3D Vision Automatic and Dolphin without user intervention.
That would be great, and it would allow fixes that would depend on the stereo parameters.
said:if you can reproduce this reliably please let us know!
I'll try. I think it happened after having some errors and correcting them. But I'm not sure.
said:
Sorry for the n00b question, but I'm not all that familiar with Dolphin - I have OOT on my Wii (not Wii U) virtual console - can I use that to try this fix? I guess I need to copy it off the Wii somehow - is there some documentation I should read on this? Despite working on the Wii U's CPU for bring up and testing in my day job, I never got around to doing any modding on my Wii.
The Wii Virtual Console version.... I still haven't tried the fixes with other versions or games that contain Ocarina of Time. The texture pack worked, at least.
I think WADs can be copied to the SD card, so you can copy it to your PC and use Dolphin (that specific build I said). For Gamecube games, there are programs to dump them with the Homebrew Channel.
said:I probably won't be able to look at this for at least another couple of weeks - moving to a new city...
Aaaah, I accidentally hit quote instead of edit. I double posted by mistake. New things I said:
The thing I'm afraid the most is the possibility of the shaders being different for each person (I think they differ with significantly different Dolphin builds). I think zero people reported anything about the fixes I made some weeks ago.
Aaaah, I accidentally hit quote instead of edit. I double posted by mistake. New things I said:
The thing I'm afraid the most is the possibility of the shaders being different for each person (I think they differ with significantly different Dolphin builds). I think zero people reported anything about the fixes I made some weeks ago.
[quote]In other pixel shaders I needed to make the changes before certain lines, because for example the same variable was doing different things after a few assignments. I better say an example, something in the line of (I'm still at work so I'm inventing this):
r0.xyzw="Something that changes position of an element"
r0.xyzw="Something that changes its color"
And the results are applied ingame without any kind of output between them, so if I did something like "r0.x=r0.x*2" it had a totally different effect if I put it before or after that second line. Is this an HLSL thing that I didn't know?[/quote]
Yeah, that's true of every programming language that uses sequential code (which is almost all of them). Imagine if you were solving a maths problem by hand - you would be using a notepad and writing down your workings as you go right? You can think of the lines in a program as doing something similar - the variables that start with a 'v' are analogous to the values given in a maths problem ("you have *5* apples"), variables that start with 'r' are used for the intermediate steps as you work something out ("I then give you another 3, then ask you to hand half your apples to Fred, then you eat one"), and the variables that start with 'o' are for the solution ("so how many apples do you have left?").
When you make a change in a shader you are changing something in that sequence, and the outcome will depend on what change you made and where (if you were to add an extra apple the result would be different depending on whether you added it before handing half the apples to Fred, or after).
One tip is that if you want to change an input you should do so near the start of the shader, but if you want to change an output you would do so near the end. If you need to change some intermediate step it will go somewhere in the middle.
In other pixel shaders I needed to make the changes before certain lines, because for example the same variable was doing different things after a few assignments. I better say an example, something in the line of (I'm still at work so I'm inventing this):
r0.xyzw="Something that changes position of an element"
r0.xyzw="Something that changes its color"
And the results are applied ingame without any kind of output between them, so if I did something like "r0.x=r0.x*2" it had a totally different effect if I put it before or after that second line. Is this an HLSL thing that I didn't know?
Yeah, that's true of every programming language that uses sequential code (which is almost all of them). Imagine if you were solving a maths problem by hand - you would be using a notepad and writing down your workings as you go right? You can think of the lines in a program as doing something similar - the variables that start with a 'v' are analogous to the values given in a maths problem ("you have *5* apples"), variables that start with 'r' are used for the intermediate steps as you work something out ("I then give you another 3, then ask you to hand half your apples to Fred, then you eat one"), and the variables that start with 'o' are for the solution ("so how many apples do you have left?").
When you make a change in a shader you are changing something in that sequence, and the outcome will depend on what change you made and where (if you were to add an extra apple the result would be different depending on whether you added it before handing half the apples to Fred, or after).
One tip is that if you want to change an input you should do so near the start of the shader, but if you want to change an output you would do so near the end. If you need to change some intermediate step it will go somewhere in the middle.
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=""]Aaaah, I accidentally hit quote instead of edit. I double posted by mistake. New things I said:
The thing I'm afraid the most is the possibility of the shaders being different for each person (I think they differ with significantly different Dolphin builds). I think zero people reported anything about the fixes I made some weeks ago.[/quote]Yeah, the best outcome will probably be to try to get the fixes in Dolphin itself, but I don't know enough about how it generates shaders to know if that is feasible - if Dolphin can tell the difference between a sky shader, a UI shader and a water shader we probably can, but if it can't that would be much harder. Your fix with 3DMigoto may end up being a stepping stone towards that end, but if nothing else it's not so bad to tell people to use a specific Dolphin release with your fix.
said:Aaaah, I accidentally hit quote instead of edit. I double posted by mistake. New things I said:
The thing I'm afraid the most is the possibility of the shaders being different for each person (I think they differ with significantly different Dolphin builds). I think zero people reported anything about the fixes I made some weeks ago.
Yeah, the best outcome will probably be to try to get the fixes in Dolphin itself, but I don't know enough about how it generates shaders to know if that is feasible - if Dolphin can tell the difference between a sky shader, a UI shader and a water shader we probably can, but if it can't that would be much harder. Your fix with 3DMigoto may end up being a stepping stone towards that end, but if nothing else it's not so bad to tell people to use a specific Dolphin release with your fix.
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
One thing worth noting that is a difference between the shaderhacker classes and 3Dmigoto- Since this is HLSL, you can modify the output variable directly.
So this is legal:
[code]o0.x += separation * convergence;[/code]
Whereas in ASM, you can't do that because the o0 register is write-only at the basic level. In HLSL the compiler takes care of complexity like that. (fewer 'gotchas')
Because of that flexibility, it's generally better to just modify the output register directly, as it makes it more clear exactly what is happening, as well as avoiding possible intervening steps that might alter the result. As DarkStarSword notes, try to put the code at the spot where you are trying to influence the result.
[quote]Edit: bonus curiosity. I've seen some pixel shaders that are disabled after being dumped, and then I saw they have this condition: "if (-1 != 0) discard;". I wonder why. I just comment that line and it works normally again.[/quote]
BTW, the code you posted just above does not show this. The line commented out is:
[code] //if (r1.x != 0) discard;[/code]
And the surrounding code looks correct to me. Don't know why avoiding the discard would help, but it can be part of how Dolphin works.
One thing worth noting that is a difference between the shaderhacker classes and 3Dmigoto- Since this is HLSL, you can modify the output variable directly.
So this is legal:
o0.x += separation * convergence;
Whereas in ASM, you can't do that because the o0 register is write-only at the basic level. In HLSL the compiler takes care of complexity like that. (fewer 'gotchas')
Because of that flexibility, it's generally better to just modify the output register directly, as it makes it more clear exactly what is happening, as well as avoiding possible intervening steps that might alter the result. As DarkStarSword notes, try to put the code at the spot where you are trying to influence the result.
Edit: bonus curiosity. I've seen some pixel shaders that are disabled after being dumped, and then I saw they have this condition: "if (-1 != 0) discard;". I wonder why. I just comment that line and it works normally again.
BTW, the code you posted just above does not show this. The line commented out is:
//if (r1.x != 0) discard;
And the surrounding code looks correct to me. Don't know why avoiding the discard would help, but it can be part of how Dolphin works.
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
Also, I set the hunting mode to 'Soft Disabled' and the game no longer crashes. So I'll just enable hunting whenever I need it and disable it right after.
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
In Zelda Ocarina of Time (in Dolphin), there are just a few vertex shaders (around 11 in the area I'm trying) and a bunch more pixel shaders (around 26). I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.
It worked and it looks good. But there are so few vertex shaders that everyone of them has to affect a variety of things. Not only the sky was pushed to depth, but Navi's circular body also gained depth (it's farther than her wings), and heart pieces and the spiritual stones are also "disassembled" now.
Question number 1: are the coordinates that the pixel shader receives set in stone? I sometimes tried to change some of the inputs of the main method of the pixel shader right at the start of the main method, but it never worked. If the answer is yes, it's probably the reason the new texture filtering exists.
In the "ShaderUsage.txt" file, I identified the vertex and pixel shaders of the sky:
I need a bit of help with the new texture filtering feature. The story:
In Zelda Ocarina of Time (in Dolphin), there are just a few vertex shaders (around 11 in the area I'm trying) and a bunch more pixel shaders (around 26). I managed to push the skybox to the infinite by multiplying its coordinates in the vertex shader by 100.
It worked and it looks good. But there are so few vertex shaders that everyone of them has to affect a variety of things. Not only the sky was pushed to depth, but Navi's circular body also gained depth (it's farther than her wings), and heart pieces and the spiritual stones are also "disassembled" now.
Question number 1: are the coordinates that the pixel shader receives set in stone? I sometimes tried to change some of the inputs of the main method of the pixel shader, but it never worked. If the answer is yes, it's probably the reason the new texture filtering exists.
In the "ShaderUsage.txt" file, I identified the vertex and pixel shaders of the sky when I dumped the pixel shader again:
I guess the textures of id=0 are the sky textures (they were a lot when I dumped them. It's a nightmare to identify and retexture them).
Question number 2 (well, more than one question): I don't understand this example:
I suppose that I have to put the ps hash (b50a9fff61b7bf45) after "Hash=", like when I disabled some pixel shaders there with other games.
- But what is "x2"? A constant defined in the IniParams section?
- Do I have to use "ps-t0" as is like that?
- Is "t0" the id of textures that won't be included in the shader fix, or are they the only ones that WILL be affected?
- In both cases, would I have to put "ps-t0-t1-t2..." if I wanted to disable/enable the coordinate override (enable or disable depending on the previous answer) in more than one texture id?
After the "x2=ps-t0" line I added "x=100" below, to see if multiplying the coordinates by "iniparams.x" would apply it only to the sky, but it was still applying to everything.
Sorry for having so many questions. I'm pretty new at this and to HLSL, and I'm sure I'm making many mistakes.
Edit: bonus curiosity. I've seen some pixel shaders that are disabled after being dumped, and then I saw they have this condition: "if (-1 != 0) discard;". I wonder why. I just comment that line and it works normally again.
Edit2: is there a way to make 3Dmigoto apply the shader fixes to people without 3D Vision? Even if the hunting mode HUD is there when my emitter is disconnected, the fixes don't load. I ask because I'm also adapting the HUD of the game to 16:9 (something that wouldn't be perfect just by editing textures), and that doesn't require stereo parameters.
Last edit: what I'm trying to do in the case of the sky is more like "apply this vertex shader change ONLY to this pixel shader". But affecting some textures of one pixel shader will also be useful for HUD things that I've changed in a pixel shader.
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
That's the basic form of partner shader filtering - that tells 3DMigoto to use your replacement vertex shader only when the pixel shader that matches the partner hash is active, and will use the default from the game otherwise.
There's also an advanced form which I haven't advertised as it's not (yet) an explicit feature and is relying on the order that 3DMigoto shader overrides to work. Here is how I use this in Lichdom:
Then in the vertex shader:
The reason this works, is that the vertex shader override will always set y2 to 0 first, then if that pixel shader is active it will then set y2 to 1. This can be expanded if necessary to match more pixel shaders.
You can find examples of both forms of partner shader filtering in the Lichdom Battlemage fix:
https://github.com/DarkStarSword/3d-fixes/blob/master/Lichdom%20Battlemage/d3dx.ini
On to your other questions:
That's a good approach that does not rely on getting the separation + convergence from Dolphin :) If you did have access to those values, a better approach would be to use x=x+separation*convergence which will move the sky to infinity (multiplying by 100 will move it back quite a way, but not necessarily to infinity).
The position will be set by this stage, but not the texture coordinates - depending on the effect adjusting the texcoords in the pixel shader may work so long as the position covers the whole effect, but in other cases the position will have to be adjusted in the vertex shader (or in some cases domain or geometry shader).
This is curious - none of the textures in slots 0, 1, 2 or 3 had hashes calculated by 3DMigoto (all are 0000000000000000). These may be 1 dimensional textures, which we don't currently calculate a hash for and currently cannot be used for texture filtering. If they are 2D or 3D textures we would need to work out why they weren't hashed. Texture slot 8 does have a hash, but as only a single texture was ever set in that slot it would be useless for filtering as well.
It is actually intended to be the vertex shader hash (well - whichever shader you are adjusting), but it just so happens that either hash will work (there is something strange happening in Crysis which prevents the vertex shader hash working there so DHR used the pixel shader hash. Not sure why yet - the vertex shader hash works fine in Far Cry 4 and Lichdom).
Yes - I added extra capacity to the IniParams texture so the new features could use it and not have to worry about running out of slots. In the ini file these use the form x,y,z,w,x1,y1,z1,w1,x2,y2,...,z7,w7 (32 slots total). In the shader you use this form to load the extended slots - the number matches the first value in the int2(...), and the letter is the component of that register:
That indicates which texture slot is being checked - in that example, it's checking the hash in "pixel shader texture slot 0". As a more esoteric example, you could check the texture in "domain shader texture slot 3" with ds-t3.
That's just the slot it checks - it will be up to your code in the shader to decide what to do based on the texture that is in that slot. You will also need to define [TextureOverride] sections for the textures of interest, which will define what value ends up in the ini param. If there is no TextureOverride for a given texture it will get 0, if there is a [TextureOverride] for it it will get 1 (by default). You can also set filter_index inside the [TextureOverride] section to set a different value if you need to do something more sophisticated.
No, you would never use that form as you can only specify one texture slot per ini param (pretty sure I made 3DMigoto give you an error tone if you tried that). The logic to decide what to do based on the texture goes inside the shader giving you maximum flexibility to do whatever you need. If you did need to check additional texture slots (which DHR needed in the Crysis 3 fix) you would add them on a separate line and use a different ini param.
That would set x2 to the result of the texture filter and x to 100 whenever that shader is used - the later functionality is really intended for partner shader filtering and scene detection (coming soon). Those two lines are independent of each other as I'm trying to avoid having too much conditional logic in 3DMigoto itself (there is a *LOT* of subtly different things people may need to do, which would lead to a metric tonne of edge cases in 3DMigoto if I tried to implement all the logic there, and I don't want 3DMigoto to end up like the nvidia driver and break everything whenever we try to work around a new edge case).
That looks like a decompiler bug as there is no way that conditional would have made it into the original shader - Bo3b?
I know bo3b was trying to make it work without 3D Vision as another modder wanted to use it to just remove post processing effects, but it was obviously a lower priority... bo3b?
Exactly :) Glad to see you are thinking along the right lines, now you know about partner shader filtering hopefully you can put it to good use :)
Is that using this same shader or a different one? If it is this one we will need to work out why the textures didn't have their hashes calculated and you would need to use the advanced form of partner shader filtering I detailed above (as the simple form won't allow both of these features to be used together). If it's a different shader, check to see if it has texture hashes in the ShaderUsage.txt.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
https://github.com/bo3b/3Dmigoto/commit/9550f74f7d400470f40adb30188ea7862fa0d109
And a followup fix that added partner shader filtering among other things to fix up some new issues that the above adjustment created:
https://github.com/bo3b/3Dmigoto/commit/88dfaacd11ee496bb2edc839e1f203edfa147289
DHR also uses texture filtering in the Crysis 3 WIP which would be worth taking a look at.
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
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
Thanks! It worked perfectly. And now I've seen that there's an example in the d3dx.ini. I don't know how I missed it before.
Thanks for the examples and explanation.
Nah, using "v3.xyz+=v3.xyz+separation*convergence" doesn't push the sky to depth. Maybe because Dolphin uses its own separation and convergence? The values 3Dmigoto shown in the game are the Nvidia ones, and they don't affect the game at all.
Using "v3.xyz=v3.xyz*115" worked the best. Multiplying by 116 made the corners of the sky (it's very blocky) be behind a black surface. So 115 times the depth is the maximum it can go. And it's almost perfect at least.
Me too. I would prefer to fix everything in the shader files instead of the ini file, because I would like to use the same ini for multiple games. But because of the partner shader thing my dream is broken :p.
All thanks to your advice :).
A different one. There's for example a pixel shader that affects almost all HUD elements, but I've been thinking about leaving the minimap texture intact, because the minimap arrows are controlled by a different vertex shader and I still haven't found a way to position them correctly. And other HUD things are moved too to the left, etc.
I'll do.
I hope I can make the perfect 3D Ocarina of Time experience. And it will be a good practice for other games (Shadow Warrior, because I got stuck with the shadows).
Edit: by the way, I'm getting tired of driver and application crashes. The VRAM is filled quickly after a few times entering and exiting fullscreen. Every alt+enter adds a few hundred MB. I guess It's Dolphin's fault, because Shadow Warrior did the same.
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
That is curious. It's always possible I broke something. If you are using 1.1.36, I put in some optimizations for performance that specifically bypass hash calculation for textures. It should always be working when hunting>0, but worth noting I modified that code recently.
Also worth checking the d3d11_log.txt file to see if those textures are generating exceptions. If the textures are not linearly mapped they will generate an exception which is caught and sets the hash to zero.
Yep, that sounds like a Decompiler problem. If you can give me the HLSL+ASM for the shader I can take a closer look. I haven't seen this one before.
Should work. Earlier I put in some checking to see if 3D was disabled and not crash based on that scenario. We might have broken that with recent changes of course, but it is intended to work for 2D as well.
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
Do you actually mean to += all xyz? Generally for skybox we only do the += .x parameter. What you are doing with "v3.xyz=v3.xyz*115" is 'puffing' up the skybox like a balloon in all dimensions. This can work and is what I did in the Psychonauts fix, but in general just doing the "v3.x+=separation*convergence" is the more correct form. (may not work here of course)
Ja, me too. We have some embedded conditional code that is getting at the edge of needing a rewrite because it's hard to know if we are breaking something else while fixing something.
This might be us actually. Helifax reported a similar problem that I haven't had a chance to look at. Same symptoms, leaking memory upon every alt-enter combo. There is an off chance we are leaking memory upon resets of the D3D11Device.
I think that DarkStarSword never sees this because he uses a second computer to edit live via network, without needing to switch out. I haven't seen this myself, but I do need to take a look since you are the second person to run into serious problems with it. (Probably game dependent because of how they handle device resets, but not an actual game problem.)
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
Nope, it doesn't work (either the stereo params aren't read properly or this skybox works different from usual). It looks the same as if I didn't try to fix it, but "v3.xyz=v3.xyz*115" works. By the way, if I only multiply one axis, it gets stretched in a really bad way.
OK. I'll test this night if there are memory leaks without 3Dmigoto.
Here's an example at line 78:
Weird, it's working now with the 3D emitter disconnected. Maybe a false alarm?
By the way, the key to temporarily disable all the fixes doesn't seem to always work when I'm making changes while playing. Some shaders remain fixed when I hold the key. I assigned it to F11, by the way.
Here is 3Dmigoto with the fixes I have for now for Zelda OOT. I've also included the "ShaderUsage.txt" file. Remember that it also contains shaders from other games, because I was also fixing Zelda TP, Zelda WW and Metroid Prime yesterday:
https://www.dropbox.com/s/lauy9huujlmy6ym/zeldaootfixes.7z?dl=0
Now I'm going to work. I'll be back home in 13 hours :(.
Edit: in case you want to try my fixes, the emulator is the Ishiiruka 413 build (https://forums.dolphin-emu.org/Thread-unofficial-ishiiruka-dolphin-custom-version), and the game is The Legend of Zelda, Collector's Edition (American version). I also use the texture pack port I made: https://forums.dolphin-emu.org/Thread-the-legend-of-zelda-collector-s-edition-hd-texture-pack-v0-4-patch-2-2015-05-04 (although I made a few different textures for the HUD these days).
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
Ahh, you're not quite doing what I thought you meant - I was thinking you were adjusting the x,y,z *AND* w of the *output* position from the vertex shader, whereas you are adjusting the xyz of one of the *inputs*. Multiplying all four components of the output position by the same amount will adjust the depth without any stretching (because the perspective divide by w counters the multiply, so only the stereo correction changes).
Still, if what you have is working, go for it :)
Likewise the x+=separation*convergence would need to be applied to the output position, not the input - but you are correct that you would need the separation+convergence from Dolphin for that adjustment, not the values from 3DMigoto. I'm actually thinking it might be worthwhile submitting a patch to Dolphin to add nvapi support to synchronise their separation+convergence settings with nvidia's - since they use the same formula that would allow the values from 3DMigoto to work interchangeably and would mean the usual nvidia key bindings would work. nvapi could also possibly be used to zero out StereoTextureEnable to remove the conflict between 3D Vision Automatic and Dolphin without user intervention.
I've had this happen as well, but I haven't managed to work out how to reliably reproduce it to track down the cause. Anecdotally, I think I've had a shader that didn't compile (e.g. due to a syntax error) before this starts happening (possibly one already in ShaderFixes on launch, possibly when reloading... not sure), which might suggest that we have a bug in an error path... But there was enough weird stuff going on when this happened that I couldn't be sure it wasn't a driver bug mixing up shaders when I reloaded them. Definitely need to investigate this further - if you can reproduce this reliably please let us know!
Sorry for the n00b question, but I'm not all that familiar with Dolphin - I have OOT on my Wii (not Wii U) virtual console - can I use that to try this fix? I guess I need to copy it off the Wii somehow - is there some documentation I should read on this? Despite working on the Wii U's CPU for bring up and testing in my day job, I never got around to doing any modding on my Wii.
I probably won't be able to look at this for at least another couple of weeks - moving to a new city...
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
Mmmm, I think I definitely tried the outputs first, but I'm gaining more knowledge every day, so maybe I did something wrong. In other pixel shaders I needed to make the changes before certain lines, because for example the same variable was doing different things after a few assignments. I better say an example, something in the line of (I'm still at work so I'm inventing this):
r0.xyzw="Something that changes position of an element"
r0.xyzw="Something that changes its color"
And the results are applied ingame without any kind of output between them, so if I did something like "r0.x=r0.x*2" it had a totally different effect if I put it before or after that second line. Is this an HLSL thing that I didn't know?
Anyway, I'll try to approach the sky vertex shader in a more correct way if possible. It was a consequence of trial and error that ended up being like that.
That would be great, and it would allow fixes that would depend on the stereo parameters.
I'll try. I think it happened after having some errors and correcting them. But I'm not sure.
The Wii Virtual Console version.... I still haven't tried the fixes with other versions or games that contain Ocarina of Time. The texture pack worked, at least.
I think WADs can be copied to the SD card, so you can copy it to your PC and use Dolphin (that specific build I said). For Gamecube games, there are programs to dump them with the Homebrew Channel.
Oh, good luck! And thanks for the help.
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
The thing I'm afraid the most is the possibility of the shaders being different for each person (I think they differ with significantly different Dolphin builds). I think zero people reported anything about the fixes I made some weeks ago.
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
Yeah, that's true of every programming language that uses sequential code (which is almost all of them). Imagine if you were solving a maths problem by hand - you would be using a notepad and writing down your workings as you go right? You can think of the lines in a program as doing something similar - the variables that start with a 'v' are analogous to the values given in a maths problem ("you have *5* apples"), variables that start with 'r' are used for the intermediate steps as you work something out ("I then give you another 3, then ask you to hand half your apples to Fred, then you eat one"), and the variables that start with 'o' are for the solution ("so how many apples do you have left?").
When you make a change in a shader you are changing something in that sequence, and the outcome will depend on what change you made and where (if you were to add an extra apple the result would be different depending on whether you added it before handing half the apples to Fred, or after).
One tip is that if you want to change an input you should do so near the start of the shader, but if you want to change an output you would do so near the end. If you need to change some intermediate step it will go somewhere in the middle.
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
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
So this is legal:
Whereas in ASM, you can't do that because the o0 register is write-only at the basic level. In HLSL the compiler takes care of complexity like that. (fewer 'gotchas')
Because of that flexibility, it's generally better to just modify the output register directly, as it makes it more clear exactly what is happening, as well as avoiding possible intervening steps that might alter the result. As DarkStarSword notes, try to put the code at the spot where you are trying to influence the result.
BTW, the code you posted just above does not show this. The line commented out is:
And the surrounding code looks correct to me. Don't know why avoiding the discard would help, but it can be part of how Dolphin works.
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