3Dmigoto now open-source...
  10 / 141    
I've been looking through the assasin's creed 4 fix posted and my own cached untouched shaders. I am now seeing some patterns in the fixing process. Although I do find it interesting that for that specific game, no vertex shaders are bigger than 6kb which left me with around 15 or so examples to look at. Now I've noticed that you always target the o.x variable. Which, according to this [code] out float4 o0 : SV_Position0[/code] represents the position of the object/vertices. Makes sense so far. The 4 in float 4 denotes 4 variables (all of which are flotation point variables) assigned to that specific variable. Which are o.(x,y,z,w). Now is there any reason as to why it's not wxyz? So you replace that part with a new variable r10 that has 4 float variables assigned to it. [code]float4 r10;[/code] All reasonable so far. Now why do you assign?: [code]float4 stereoParams = StereoParams.Load(0); [/code]
I've been looking through the assasin's creed 4 fix posted and my own cached untouched shaders. I am now seeing some patterns in the fixing process. Although I do find it interesting that for that specific game, no vertex shaders are bigger than 6kb which left me with around 15 or so examples to look at.

Now I've noticed that you always target the o.x variable. Which, according to this
out float4 o0 : SV_Position0
represents the position of the object/vertices. Makes sense so far.

The 4 in float 4 denotes 4 variables (all of which are flotation point variables) assigned to that specific variable. Which are o.(x,y,z,w). Now is there any reason as to why it's not wxyz?



So you replace that part with a new variable r10 that has 4 float variables assigned to it.
float4 r10;

All reasonable so far. Now why do you assign?:
float4 stereoParams = StereoParams.Load(0);

Posted 08/13/2014 03:41 PM   
Next up you just change up this part that was removed: [code] o0.x = dot(r0.xyzw, g_WorldViewProj._m00_m10_m20_m30); o0.y = dot(r0.xyzw, g_WorldViewProj._m01_m11_m21_m31); o0.z = dot(r0.xyzw, g_WorldViewProj._m02_m12_m22_m32); o0.w = dot(r0.xyzw, g_WorldViewProj._m03_m13_m23_m33);[/code] with this: [code]r10.x = dot(r0.xyzw, g_WorldViewProj._m00_m10_m20_m30); r10.y = dot(r0.xyzw, g_WorldViewProj._m01_m11_m21_m31); r10.z = dot(r0.xyzw, g_WorldViewProj._m02_m12_m22_m32); r10.w = dot(r0.xyzw, g_WorldViewProj._m03_m13_m23_m33);[/code] But then you later make them equal to each other [code]o0.xyzw = r10.xyzw; [/code] right after you add this to the r10: [code] r10.x += stereoParams.x * (stereoParams.y); [/code] So why not just edit the original o0.(xyzw)? ----------------------------------------------------------------------------------------------------------------------------------------- And can you explain what does this line exactly do?: [code]r10.x += stereoParams.x * (stereoParams.y); [/code] I used these pieces of code to understand the previous posts: http://www.diffchecker.com/f7dnmywi http://www.diffchecker.com/e5z7qjzg http://www.diffchecker.com/8tdo1zcx http://www.diffchecker.com/alrh8sm3
Next up you just change up this part that was removed:
o0.x = dot(r0.xyzw, g_WorldViewProj._m00_m10_m20_m30);
o0.y = dot(r0.xyzw, g_WorldViewProj._m01_m11_m21_m31);
o0.z = dot(r0.xyzw, g_WorldViewProj._m02_m12_m22_m32);
o0.w = dot(r0.xyzw, g_WorldViewProj._m03_m13_m23_m33);


with this:
r10.x = dot(r0.xyzw, g_WorldViewProj._m00_m10_m20_m30);
r10.y = dot(r0.xyzw, g_WorldViewProj._m01_m11_m21_m31);
r10.z = dot(r0.xyzw, g_WorldViewProj._m02_m12_m22_m32);
r10.w = dot(r0.xyzw, g_WorldViewProj._m03_m13_m23_m33);


But then you later make them equal to each other
o0.xyzw = r10.xyzw;


right after you add this to the r10:
r10.x +=  stereoParams.x * (stereoParams.y);

So why not just edit the original o0.(xyzw)?

-----------------------------------------------------------------------------------------------------------------------------------------


And can you explain what does this line exactly do?:
r10.x +=  stereoParams.x * (stereoParams.y);



I used these pieces of code to understand the previous posts:
http://www.diffchecker.com/f7dnmywi
http://www.diffchecker.com/e5z7qjzg
http://www.diffchecker.com/8tdo1zcx
http://www.diffchecker.com/alrh8sm3

Posted 08/13/2014 03:42 PM   
Now regarding HUD in the game, I see you add [code]Texture1D<float4> IniParams : register(t120); [/code] under [code] Texture2D<float4> StereoParams : register(t125); [/code] Why is that? -------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------- Then everything is the same as previous post and you assign a new variable for the piece of code added above. [code]float4 iniParams = IniParams.Load(0); [/code] Now this is where it gets tricky. In 2 of the fixes http://www.diffchecker.com/k3002qbn http://www.diffchecker.com/0wnty5qg you add this: [code] // if(r10.w == 1) if(r10.w == 1 && r10.z < 1) { r10.x += stereoParams.x * iniParams.x; } o0.xyzw = r10.xyzw;[/code] But for another fix http://www.diffchecker.com/ljo6jgd the line with the && gets replaced with: [code] if(r10.w == 1 || r10.z == 0)[/code] And then there's this one which changes everything once again: http://www.diffchecker.com/0xm6ngki I'd love an explanation to everything happening after assigning the r10.w variable.
Now regarding HUD in the game, I see you add
Texture1D<float4> IniParams : register(t120);

under
Texture2D<float4> StereoParams : register(t125);

Why is that?

--------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------


Then everything is the same as previous post and you assign a new variable for the piece of code added above.
float4 iniParams = IniParams.Load(0);


Now this is where it gets tricky. In 2 of the fixes

http://www.diffchecker.com/k3002qbn

http://www.diffchecker.com/0wnty5qg


you add this:
// if(r10.w == 1)
if(r10.w == 1 && r10.z < 1)
{
r10.x += stereoParams.x * iniParams.x;
}
o0.xyzw = r10.xyzw;


But for another fix

http://www.diffchecker.com/ljo6jgd


the line with the && gets replaced with:
if(r10.w == 1 || r10.z == 0)


And then there's this one which changes everything once again:

http://www.diffchecker.com/0xm6ngki


I'd love an explanation to everything happening after assigning the r10.w variable.

Posted 08/13/2014 03:42 PM   
[quote="ForgottenProdigy"]Posting the original post split up here as bo3b requested. Thanks for the info, I'm currently looking into the tutorials and such. I have 2 questions however: 1. How do you skip a vertex shader in something like watch dogs? I have 3 vertex and 1 pixel shader that I want to skip (they're all related to shadows if that changes anything). You said to make o2=0 and I have absolutely no idea what that means. 2. What do you mean by input and output parameters? Can you link to a webpage that shows them? So far I've found "http://msdn.microsoft.com/en-us/library/windows/desktop/bb509606(v=vs.85).aspx" but it doesn't make much sense to me. I feel like I need to learn the whole language to get it. [/quote]Thanks for doing this. The Q/A will help other people too. You are only the third person to fire up 3Dmigoto to take a look. :-> 1. Skip a shader? Do you mean disable a shader? While running the game, you use numpad 1,2 to cycle PS, and numpad 4,5 for VS. As they cycle you'll see them blink out. When you get one that you want to disable, you use the CopyOnMark feature of numpad 3 for PS, numpad 6 for VS. That will copy the currently blanked out shader to the ShaderFixes folder, ready for editing. Cycle once more to re-display the shader (so later you can see it disabled.) Alt-Tab out and open the file in NotePad++ or other editor. I leave the folder sorted by date, so last one marked is always on top. Then, here's a short example VS from WatchDogs. [code]// Shadows from buildings, trees. Shader active appears to be dependent upon settings. Texture2D<float4> StereoParams : register(t125); void main( float3 v0 : POSITION0, out float2 o0 : TEXCOORD0, out float4 o1 : SV_Position0) { o0.xy = v0.xy * float2(5.000000e-001,-5.000000e-001) + float2(5.000000e-001,5.000000e-001); o1.xy = v0.xy; o1.zw = float2(0.000000e+000,1.000000e+000); return; }[/code] I always add comments to the header to remind me what that specific shader was all about. Get into the habit of documenting your stuff, and it makes it easier to figure and less likely to get confused, as after awhile you are looking at twenty shaders at once. This helps you as much as other people, when you come back to it 60 days later and think, WTF? So in this case, there are two outputs, the texcoord0 and the position. For disabling a shader, the most common way is to zero out the SV_POSITION0 like: [code]// Shadows from buildings, trees. Shader active appears to be dependent upon settings. Texture2D<float4> StereoParams : register(t125); void main( float3 v0 : POSITION0, out float2 o0 : TEXCOORD0, out float4 o1 : SV_Position0) { o0.xy = v0.xy * float2(5.000000e-001,-5.000000e-001) + float2(5.000000e-001,5.000000e-001); o1.xy = v0.xy; o1.zw = float2(0.000000e+000,1.000000e+000); // bo3b: Disable shadows o1 = 0; return; }[/code] BTW, you can't do it exactly this way in ASM, but in HLSL it's simpler like this. Strictly speaking it's not necessary to set it to zero, but if we don't then when it's recompiled we get a warning that the output is not fully specified, and I don't like the distractions of warnings. Once you edit that and save the file, you alt-tab back into the game, and press F10 to reload any changed shaders in ShaderFixes, and you should see the effect magically blink out. 2. Input/output params. In this example, the Input parameter is the v0 position, and the two marked out are the output parameters. These input/output variables are the most important part of the shaders, the rest of the code will mostly be Klingon, but we can always see these. These give use the ability to change the behavior, because the routine only cares about the output. If we modify the output, stuff further downstream doesn't know or care. As long as we don't blow something up. Let me know if that doesn't answer this first question.
ForgottenProdigy said:Posting the original post split up here as bo3b requested.

Thanks for the info, I'm currently looking into the tutorials and such. I have 2 questions however:

1. How do you skip a vertex shader in something like watch dogs? I have 3 vertex and 1 pixel shader that I want to skip (they're all related to shadows if that changes anything).
You said to make o2=0 and I have absolutely no idea what that means.

2. What do you mean by input and output parameters? Can you link to a webpage that shows them? So far I've found "http://msdn.microsoft.com/en-us/library/windows/desktop/bb509606(v=vs.85).aspx" but it doesn't make much sense to me. I feel like I need to learn the whole language to get it.
Thanks for doing this. The Q/A will help other people too. You are only the third person to fire up 3Dmigoto to take a look. :->

1. Skip a shader?

Do you mean disable a shader? While running the game, you use numpad 1,2 to cycle PS, and numpad 4,5 for VS. As they cycle you'll see them blink out. When you get one that you want to disable, you use the CopyOnMark feature of numpad 3 for PS, numpad 6 for VS. That will copy the currently blanked out shader to the ShaderFixes folder, ready for editing. Cycle once more to re-display the shader (so later you can see it disabled.)

Alt-Tab out and open the file in NotePad++ or other editor. I leave the folder sorted by date, so last one marked is always on top.

Then, here's a short example VS from WatchDogs.

// Shadows from buildings, trees.  Shader active appears to be dependent upon settings.

Texture2D<float4> StereoParams : register(t125);

void main(
float3 v0 : POSITION0,
out float2 o0 : TEXCOORD0,
out float4 o1 : SV_Position0)
{
o0.xy = v0.xy * float2(5.000000e-001,-5.000000e-001) + float2(5.000000e-001,5.000000e-001);
o1.xy = v0.xy;
o1.zw = float2(0.000000e+000,1.000000e+000);
return;
}


I always add comments to the header to remind me what that specific shader was all about. Get into the habit of documenting your stuff, and it makes it easier to figure and less likely to get confused, as after awhile you are looking at twenty shaders at once. This helps you as much as other people, when you come back to it 60 days later and think, WTF?

So in this case, there are two outputs, the texcoord0 and the position. For disabling a shader, the most common way is to zero out the SV_POSITION0 like:

// Shadows from buildings, trees.  Shader active appears to be dependent upon settings.

Texture2D<float4> StereoParams : register(t125);

void main(
float3 v0 : POSITION0,
out float2 o0 : TEXCOORD0,
out float4 o1 : SV_Position0)
{
o0.xy = v0.xy * float2(5.000000e-001,-5.000000e-001) + float2(5.000000e-001,5.000000e-001);
o1.xy = v0.xy;
o1.zw = float2(0.000000e+000,1.000000e+000);

// bo3b: Disable shadows
o1 = 0;
return;
}

BTW, you can't do it exactly this way in ASM, but in HLSL it's simpler like this.

Strictly speaking it's not necessary to set it to zero, but if we don't then when it's recompiled we get a warning that the output is not fully specified, and I don't like the distractions of warnings.

Once you edit that and save the file, you alt-tab back into the game, and press F10 to reload any changed shaders in ShaderFixes, and you should see the effect magically blink out.


2. Input/output params.

In this example, the Input parameter is the v0 position, and the two marked out are the output parameters. These input/output variables are the most important part of the shaders, the rest of the code will mostly be Klingon, but we can always see these.

These give use the ability to change the behavior, because the routine only cares about the output. If we modify the output, stuff further downstream doesn't know or care. As long as we don't blow something up.

Let me know if that doesn't answer this first question.

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

Posted 08/13/2014 10:30 PM   
[quote="ForgottenProdigy"]I've been looking through the assasin's creed 4 fix posted and my own cached untouched shaders. I am now seeing some patterns in the fixing process. Although I do find it interesting that for that specific game, no vertex shaders are bigger than 6kb which left me with around 15 or so examples to look at. Now I've noticed that you always target the o.x variable. Which, according to this [code] out float4 o0 : SV_Position0[/code] represents the position of the object/vertices. Makes sense so far. The 4 in float 4 denotes 4 variables (all of which are flotation point variables) assigned to that specific variable. Which are o.(x,y,z,w). Now is there any reason as to why it's not wxyz? So you replace that part with a new variable r10 that has 4 float variables assigned to it. [code]float4 r10;[/code] All reasonable so far. Now why do you assign?: [code]float4 stereoParams = StereoParams.Load(0); [/code] [/quote]As Mike noted, the AC4 fix is a bit more involved than a lot of them, and also we learned more about easier ways to present stuff. You might take a look at my SR3 fix as the simplest example. There is no need to assign anything or create temporary variables in HLSL like the r10, because we have a real compiler and it takes care of all that. So, that makes it simpler because we can just put our code at the bottom of a shader and keep it in one spot. When we target the output like: [code]out float4 o0 : SV_Position0[/code] That is actually four pieces. x,y,z,w in that order. Changing the order is possible, but changes the results. That's called swizzling. In general, you must keep them in order, unless you have something specific you want to do. When I do something like: [code]o0 = 0;[/code] The compiler knows to assign all four pieces of the float4 (each x,y,z,w is a float), the same as if we wrote: [code]o0.xyzw = 0;[/code] I always go for simplest and clearest when there are different ways. The code: [code]Texture2D<float4> StereoParams : register(t125); float4 stereo = StereoParams.Load(0); [/code] Is the magic piece that we need to be able to get stereo information from the 3Dmigoto wrapper into the shader itself where we can use it. This is basically hooking together some NVidia stereo API calls to get the separation and convergence values into the shader, because we need them. The register t125 is assigned by 3Dmigoto to be the stereo information. You won't need to ever change this, it's just required to let the shader know this parameter is available and can be used to Load. I think the clearest way to define this is to use HLSL to our advantage and name stuff for what it actually is. We don't have that option in ASM, and we are improving as we go. The canonical version of the shader fix code is: [code]float4 stereo = StereoParams.Load(0); float separation = stereo.x; float convergence = stereo.y; o0.x += separation * (o0.w - convergence); [/code] Start with that, and you can put it all at the bottom of a shader for simplicity and clarity. (The register(t125) is always added automatically for you, in the right spot.)
ForgottenProdigy said:I've been looking through the assasin's creed 4 fix posted and my own cached untouched shaders. I am now seeing some patterns in the fixing process. Although I do find it interesting that for that specific game, no vertex shaders are bigger than 6kb which left me with around 15 or so examples to look at.

Now I've noticed that you always target the o.x variable. Which, according to this
out float4 o0 : SV_Position0
represents the position of the object/vertices. Makes sense so far.

The 4 in float 4 denotes 4 variables (all of which are flotation point variables) assigned to that specific variable. Which are o.(x,y,z,w). Now is there any reason as to why it's not wxyz?



So you replace that part with a new variable r10 that has 4 float variables assigned to it.
float4 r10;

All reasonable so far. Now why do you assign?:
float4 stereoParams = StereoParams.Load(0);


As Mike noted, the AC4 fix is a bit more involved than a lot of them, and also we learned more about easier ways to present stuff. You might take a look at my SR3 fix as the simplest example.

There is no need to assign anything or create temporary variables in HLSL like the r10, because we have a real compiler and it takes care of all that. So, that makes it simpler because we can just put our code at the bottom of a shader and keep it in one spot.

When we target the output like:
out float4 o0 : SV_Position0

That is actually four pieces. x,y,z,w in that order. Changing the order is possible, but changes the results. That's called swizzling. In general, you must keep them in order, unless you have something specific you want to do.

When I do something like:
o0 = 0;

The compiler knows to assign all four pieces of the float4 (each x,y,z,w is a float), the same as if we wrote:
o0.xyzw = 0;

I always go for simplest and clearest when there are different ways.


The code:
Texture2D<float4> StereoParams : register(t125);
float4 stereo = StereoParams.Load(0);

Is the magic piece that we need to be able to get stereo information from the 3Dmigoto wrapper into the shader itself where we can use it. This is basically hooking together some NVidia stereo API calls to get the separation and convergence values into the shader, because we need them. The register t125 is assigned by 3Dmigoto to be the stereo information. You won't need to ever change this, it's just required to let the shader know this parameter is available and can be used to Load.

I think the clearest way to define this is to use HLSL to our advantage and name stuff for what it actually is. We don't have that option in ASM, and we are improving as we go.

The canonical version of the shader fix code is:

float4 stereo = StereoParams.Load(0);
float separation = stereo.x;
float convergence = stereo.y;
o0.x += separation * (o0.w - convergence);

Start with that, and you can put it all at the bottom of a shader for simplicity and clarity. (The register(t125) is always added automatically for you, in the right spot.)

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

Posted 08/13/2014 11:09 PM   
[quote="ForgottenProdigy"]Next up you just change up this part that was removed: [code] o0.x = dot(r0.xyzw, g_WorldViewProj._m00_m10_m20_m30); ...[/code] with this: [code]r10.x = dot(r0.xyzw, g_WorldViewProj._m00_m10_m20_m30); ...[/code] But then you later make them equal to each other [code]o0.xyzw = r10.xyzw; [/code] right after you add this to the r10: [code] r10.x += stereoParams.x * (stereoParams.y); [/code] So why not just edit the original o0.(xyzw)?[/quote]As noted in the prior post, we didn't quite understand how much flexibility HLSL gave us early on, and we started by copying the techniques used for ASM where you have to assign to a temp variable like r10. Now things are more clear, and so the best way to do this is to just assign the o0 as you'd expect, and the compiler takes care of knowing what the last most important assignment is, and we can make the code simpler and more clear. Use my canonical example to start, as: [code]float4 stereo = StereoParams.Load(0); float separation = stereo.x; float convergence = stereo.y; o0.x += separation * (o0.w - convergence);[/code] I'd like us all to get in the habit of using that canonical code to start, because it will be far easier to understand when we use the actual formula specified by NVidia. (this took me months to translate that formula into what I saw in the ASM because the required bad variable names obfuscated the code.) Note that in the example you were looking at the o0.w piece is missing. I can't explain that complexity at the moment, but suffice it to say that the canonical version is where you start, but it's not always what is required. In this example, that is probably a skybox fix where the o0.w parameter makes things worse, and by experimentation Mike found that removing it was best.
ForgottenProdigy said:Next up you just change up this part that was removed:
o0.x = dot(r0.xyzw, g_WorldViewProj._m00_m10_m20_m30);
...


with this:
r10.x = dot(r0.xyzw, g_WorldViewProj._m00_m10_m20_m30);
...


But then you later make them equal to each other
o0.xyzw = r10.xyzw;


right after you add this to the r10:
r10.x +=  stereoParams.x * (stereoParams.y);

So why not just edit the original o0.(xyzw)?
As noted in the prior post, we didn't quite understand how much flexibility HLSL gave us early on, and we started by copying the techniques used for ASM where you have to assign to a temp variable like r10.

Now things are more clear, and so the best way to do this is to just assign the o0 as you'd expect, and the compiler takes care of knowing what the last most important assignment is, and we can make the code simpler and more clear.

Use my canonical example to start, as:

float4 stereo = StereoParams.Load(0);
float separation = stereo.x;
float convergence = stereo.y;
o0.x += separation * (o0.w - convergence);

I'd like us all to get in the habit of using that canonical code to start, because it will be far easier to understand when we use the actual formula specified by NVidia. (this took me months to translate that formula into what I saw in the ASM because the required bad variable names obfuscated the code.)


Note that in the example you were looking at the o0.w piece is missing. I can't explain that complexity at the moment, but suffice it to say that the canonical version is where you start, but it's not always what is required. In this example, that is probably a skybox fix where the o0.w parameter makes things worse, and by experimentation Mike found that removing it was best.

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

Posted 08/13/2014 11:22 PM   
Regarding: [code]o0.x += separation * (o0.w - convergence);[/code] This is what I'm calling the prime directive of stereoization, and to make more complicated fixes you need to understand why this works, and why changing the output.x changes the perceived depth. Adding more makes it deeper in screen, subtracting makes it shallower. x=0 makes it screen depth. Negative x's makes it pop-out. This is a good paper describing how it all works. Slide 49 describes the prime directive. [url]http://www.nvidia.com/content/GTC-2010/pdfs/2010_GTC2010.pdf[/url] And from the ASM side, the discussion why this all works- buried deep in comments on a game fix: [url]http://helixmod.blogspot.com/2012/12/darksiders-2010.html?showComment=1356789781459#c4261038469296882737[/url]
Regarding:

o0.x += separation * (o0.w - convergence);

This is what I'm calling the prime directive of stereoization, and to make more complicated fixes you need to understand why this works, and why changing the output.x changes the perceived depth. Adding more makes it deeper in screen, subtracting makes it shallower. x=0 makes it screen depth. Negative x's makes it pop-out.

This is a good paper describing how it all works. Slide 49 describes the prime directive.

http://www.nvidia.com/content/GTC-2010/pdfs/2010_GTC2010.pdf

And from the ASM side, the discussion why this all works- buried deep in comments on a game fix:

http://helixmod.blogspot.com/2012/12/darksiders-2010.html?showComment=1356789781459#c4261038469296882737

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

Posted 08/13/2014 11:28 PM   
How did you guys find all of the shaders to fix in ACIV and ACIII? There are a ridiculous 460 shaders in ACIII shaderFixes alone (the 3Dmigoto-AC3-0.6_Beta zip file). Also the the player shadow is made up of a bunch of shaders and the same applies to the whole environment. This must have been a LOT of work to fix. How long did it approximately take you guys to fix it? I just want to get a feel of how long it'll take for an average dx11 game to fix. Also did anyone manage to fix the watch dogs shadows? I tried for an hour or 2 and nothing. Either the shadow was broken or was broken and followed me around. Also tried to run migoto on 8.1 and pretty much every game failed except for watch dogs. I guess I should just use windows 7 for all migoto work. Far Cry 3 (dx11 version of exe) opened and I could cycle through shaders but there were horrible glitches everywhere (floor was raised to the heavens all around me, basically unplayable). Civ V opened but gave an error soon afterwards after the intro movie. The error screen had a black/white checkerboard pattern. That was interesting. Sniper Elite V3 doesn't even open. Red Faction Armageddon DX11 opens but crashes soon afterwards. Here are the contents of the dx 11 log: http://pastebin . com/0QXHQuBH Battlefield 4 doesn't launch using the x86 shortcut but the other one launches fine. But no shader cycling or shader caching. Hitman Absolution opens up and caches shaders but severe graphical glitches occur. (some triangle things blocking the screen and hitman's body is missing [clothes are there though]). Can cycle through shaders. Arkham Origins launches and can cycle through shaders but the bodies of batman and the enemies are missing. What I'm afraid of is that I see you make the migoto specific to each game. Does that mean that for every dx11 game that comes out, migoto needs to be updated to work for it or the fixes done now will stabilize migoto enough so the only thing we will need to worry about are the shaders itself?
How did you guys find all of the shaders to fix in ACIV and ACIII? There are a ridiculous 460 shaders in ACIII shaderFixes alone (the 3Dmigoto-AC3-0.6_Beta zip file).

Also the the player shadow is made up of a bunch of shaders and the same applies to the whole environment. This must have been a LOT of work to fix. How long did it approximately take you guys to fix it? I just want to get a feel of how long it'll take for an average dx11 game to fix.

Also did anyone manage to fix the watch dogs shadows? I tried for an hour or 2 and nothing. Either the shadow was broken or was broken and followed me around.

Also tried to run migoto on 8.1 and pretty much every game failed except for watch dogs. I guess I should just use windows 7 for all migoto work.

Far Cry 3 (dx11 version of exe) opened and I could cycle through shaders but there were horrible glitches everywhere (floor was raised to the heavens all around me, basically unplayable).

Civ V opened but gave an error soon afterwards after the intro movie. The error screen had a black/white checkerboard pattern. That was interesting.

Sniper Elite V3 doesn't even open.

Red Faction Armageddon DX11 opens but crashes soon afterwards. Here are the contents of the dx 11 log: http://pastebin . com/0QXHQuBH

Battlefield 4 doesn't launch using the x86 shortcut but the other one launches fine. But no shader cycling or shader caching.

Hitman Absolution opens up and caches shaders but severe graphical glitches occur. (some triangle things blocking the screen and hitman's body is missing [clothes are there though]). Can cycle through shaders.

Arkham Origins launches and can cycle through shaders but the bodies of batman and the enemies are missing.

What I'm afraid of is that I see you make the migoto specific to each game. Does that mean that for every dx11 game that comes out, migoto needs to be updated to work for it or the fixes done now will stabilize migoto enough so the only thing we will need to worry about are the shaders itself?

Posted 08/14/2014 04:54 AM   
[quote="ForgottenProdigy"]How did you guys find all of the shaders to fix in ACIV and ACIII? There are a ridiculous 460 shaders in ACIII shaderFixes alone (the 3Dmigoto-AC3-0.6_Beta zip file). Also the the player shadow is made up of a bunch of shaders and the same applies to the whole environment. This must have been a LOT of work to fix. How long did it approximately take you guys to fix it? I just want to get a feel of how long it'll take for an average dx11 game to fix.[/quote]There is a setting in d3dx.ini file further down of export_hlsl=1. If set to 1, it will dump every shader that the game sees as HLSL. It's not 100% successful, there are some Decompiler bugs still, so some will be busted. When we run across a shader that we need specifically, I will either fix that bug in the Decompiler, or sometimes hand-patch that shader to generate the proper ASM. For all these shaders, the Decompiler worked OK, and so there are a lot of copies of very similar shaders with the same problems. So, offline with an external tool like grep, or regular expressions in VS, or Python, or Mike has a VB script, he would run that against the 7000 shaders dumped, and it would pick up and script fix those 450 shaders. It's tricky to get it to only fix the stuff you want, but not too bad. So, the basic approach is to work out a fix for a specific shader, then look through the full dump to see if there are duplicates or similar shaders. Also of note, this is how Helix's Lua script works on DX9 games, where Helix coded the script to auto-fix stuff at runtime, instead of how we are doing it offline. How long does it take? The hard part is figuring out the actual fix required, and that is indeterminate time. Sometimes it cannot be fixed, like the blood decals in AC3. Once you have a basic fix, making it work on the rest of the shader dump is only a few hours. [quote="ForgottenProdigy"]Also did anyone manage to fix the watch dogs shadows? I tried for an hour or 2 and nothing. Either the shadow was broken or was broken and followed me around. Also tried to run migoto on 8.1 and pretty much every game failed except for watch dogs. I guess I should just use windows 7 for all migoto work. [/quote]I haven't looked into the shadows much except to note that it was working, as Mike is supremely expert here and said he'd take a look when he has time. I've got a lot of other things to look at, so if he's going to look at them, I look into other stuff like fixing Decompiler bugs. I would expect it to run better than that, even on 8.1, although both Mike and I only use Win7 because it's already freakin' hard and I don't need extra things to figure out. I know that current 3Dmigoto will run OK on 8.1 for playing, but for shader hunting I have no idea. And, not to be harsh, but I'm not going to put any effort into making shader-hunting work on 8.1 as it's not a good use of my time. If you have interest in trying that out and getting it to work, don't hesitate to jump into the code base on Github. The WD fix is x64, and isn't going to work on other stuff. I wouldn't expect it to crash, I'd just expect it to not load, but I'm not sure. I'll make a specific x32 package shortly that is my best code to date. [quote="ForgottenProdigy"]Far Cry 3 (dx11 version of exe) opened and I could cycle through shaders but there were horrible glitches everywhere (floor was raised to the heavens all around me, basically unplayable). Civ V opened but gave an error soon afterwards after the intro movie. The error screen had a black/white checkerboard pattern. That was interesting. Sniper Elite V3 doesn't even open. Red Faction Armageddon DX11 opens but crashes soon afterwards. Here are the contents of the dx 11 log: http://pastebin . com/0QXHQuBH Battlefield 4 doesn't launch using the x86 shortcut but the other one launches fine. But no shader cycling or shader caching. Hitman Absolution opens up and caches shaders but severe graphical glitches occur. (some triangle things blocking the screen and hitman's body is missing [clothes are there though]). Can cycle through shaders. Arkham Origins launches and can cycle through shaders but the bodies of batman and the enemies are missing.[/quote]Thanks for trying extra games, I haven't had a chance to try other stuff to see. I assume these are experiments, because FC3 already has a great DX9 fix, and in general I can't see that DX11 brought anything to the table except for more complexity. What your might be seeing with the missing bodies, and floors raised and stuff is that the Decompiler still has bugs, and can generate a bad shader that is then used in the game. We workaround these as I note above, because in general we don't want to change stuff that doesn't need to be changed. So typically, we dump all the shaders, but put them in a non-loading directory for searches. To see if this is happening, enable logging with calls=1, and look for errors in the log for Decompiles, or during recompiles. [quote="ForgottenProdigy"]What I'm afraid of is that I see you make the migoto specific to each game. Does that mean that for every dx11 game that comes out, migoto needs to be updated to work for it or the fixes done now will stabilize migoto enough so the only thing we will need to worry about are the shaders itself?[/quote]No, it's the latter. The Decompiler is the core of the tool, and it still has bugs and generates bad shaders and has missing opcodes and some other stuff. But, each game we fixed, it got better and more stable. On the first one AC3, I fixed something like 35 Decompiler bugs, AC4 had about 20 bugs, and SR games had about 5 bugs. On the other hand WatchDogs is the first SM5 game we've hit, and it has many serious problems including some that crash the Decompiler altogether (exception caught, shader skipped). So, it doesn't need to be set up for every game, but there has been a learning curve for me to get this working more smoothly with the different ways that games load. I've to put some deep thought into ways around some problems, which is why it no longer uses a dxgi dll, and shader hunting is much more stable that it was. Also, not to look for excuses, but nobody has looked at different DX11 games before, both Helix and Chiri only looked at a single game, and each game does have some subtle weirdness that broke some of their earlier ideas. A good example of that is WatchDogs, where NVidia specifically locks out the d3d11, so the proxy wrapper was bypassed in the game, making no shader dumping happen. This happened because the game linked directly against nvapi64.lib, and that would go straight to system32 for calls. Other x64 DX11 games don't do this (CoD:ghosts), so it's something unique about their approach. I've manged to figure out a way to bypass their bypass, but we can definitely expect this sort of game-specific craziness. Note that is true of Helix's DX9 dlls too, that's why there are multiple versions, some things are workaround for specific games. It won't always happen, and things from the same engine will be similar, but different engines typically do require some sort of tweaks.
ForgottenProdigy said:How did you guys find all of the shaders to fix in ACIV and ACIII? There are a ridiculous 460 shaders in ACIII shaderFixes alone (the 3Dmigoto-AC3-0.6_Beta zip file).

Also the the player shadow is made up of a bunch of shaders and the same applies to the whole environment. This must have been a LOT of work to fix. How long did it approximately take you guys to fix it? I just want to get a feel of how long it'll take for an average dx11 game to fix.
There is a setting in d3dx.ini file further down of export_hlsl=1. If set to 1, it will dump every shader that the game sees as HLSL. It's not 100% successful, there are some Decompiler bugs still, so some will be busted. When we run across a shader that we need specifically, I will either fix that bug in the Decompiler, or sometimes hand-patch that shader to generate the proper ASM.

For all these shaders, the Decompiler worked OK, and so there are a lot of copies of very similar shaders with the same problems. So, offline with an external tool like grep, or regular expressions in VS, or Python, or Mike has a VB script, he would run that against the 7000 shaders dumped, and it would pick up and script fix those 450 shaders. It's tricky to get it to only fix the stuff you want, but not too bad.

So, the basic approach is to work out a fix for a specific shader, then look through the full dump to see if there are duplicates or similar shaders.

Also of note, this is how Helix's Lua script works on DX9 games, where Helix coded the script to auto-fix stuff at runtime, instead of how we are doing it offline.

How long does it take? The hard part is figuring out the actual fix required, and that is indeterminate time. Sometimes it cannot be fixed, like the blood decals in AC3. Once you have a basic fix, making it work on the rest of the shader dump is only a few hours.


ForgottenProdigy said:Also did anyone manage to fix the watch dogs shadows? I tried for an hour or 2 and nothing. Either the shadow was broken or was broken and followed me around.

Also tried to run migoto on 8.1 and pretty much every game failed except for watch dogs. I guess I should just use windows 7 for all migoto work.
I haven't looked into the shadows much except to note that it was working, as Mike is supremely expert here and said he'd take a look when he has time. I've got a lot of other things to look at, so if he's going to look at them, I look into other stuff like fixing Decompiler bugs.

I would expect it to run better than that, even on 8.1, although both Mike and I only use Win7 because it's already freakin' hard and I don't need extra things to figure out. I know that current 3Dmigoto will run OK on 8.1 for playing, but for shader hunting I have no idea. And, not to be harsh, but I'm not going to put any effort into making shader-hunting work on 8.1 as it's not a good use of my time. If you have interest in trying that out and getting it to work, don't hesitate to jump into the code base on Github.

The WD fix is x64, and isn't going to work on other stuff. I wouldn't expect it to crash, I'd just expect it to not load, but I'm not sure. I'll make a specific x32 package shortly that is my best code to date.


ForgottenProdigy said:Far Cry 3 (dx11 version of exe) opened and I could cycle through shaders but there were horrible glitches everywhere (floor was raised to the heavens all around me, basically unplayable).

Civ V opened but gave an error soon afterwards after the intro movie. The error screen had a black/white checkerboard pattern. That was interesting.

Sniper Elite V3 doesn't even open.

Red Faction Armageddon DX11 opens but crashes soon afterwards. Here are the contents of the dx 11 log: http://pastebin . com/0QXHQuBH

Battlefield 4 doesn't launch using the x86 shortcut but the other one launches fine. But no shader cycling or shader caching.

Hitman Absolution opens up and caches shaders but severe graphical glitches occur. (some triangle things blocking the screen and hitman's body is missing [clothes are there though]). Can cycle through shaders.

Arkham Origins launches and can cycle through shaders but the bodies of batman and the enemies are missing.
Thanks for trying extra games, I haven't had a chance to try other stuff to see. I assume these are experiments, because FC3 already has a great DX9 fix, and in general I can't see that DX11 brought anything to the table except for more complexity.

What your might be seeing with the missing bodies, and floors raised and stuff is that the Decompiler still has bugs, and can generate a bad shader that is then used in the game. We workaround these as I note above, because in general we don't want to change stuff that doesn't need to be changed. So typically, we dump all the shaders, but put them in a non-loading directory for searches.

To see if this is happening, enable logging with calls=1, and look for errors in the log for Decompiles, or during recompiles.


ForgottenProdigy said:What I'm afraid of is that I see you make the migoto specific to each game. Does that mean that for every dx11 game that comes out, migoto needs to be updated to work for it or the fixes done now will stabilize migoto enough so the only thing we will need to worry about are the shaders itself?
No, it's the latter. The Decompiler is the core of the tool, and it still has bugs and generates bad shaders and has missing opcodes and some other stuff. But, each game we fixed, it got better and more stable. On the first one AC3, I fixed something like 35 Decompiler bugs, AC4 had about 20 bugs, and SR games had about 5 bugs.

On the other hand WatchDogs is the first SM5 game we've hit, and it has many serious problems including some that crash the Decompiler altogether (exception caught, shader skipped).

So, it doesn't need to be set up for every game, but there has been a learning curve for me to get this working more smoothly with the different ways that games load. I've to put some deep thought into ways around some problems, which is why it no longer uses a dxgi dll, and shader hunting is much more stable that it was.


Also, not to look for excuses, but nobody has looked at different DX11 games before, both Helix and Chiri only looked at a single game, and each game does have some subtle weirdness that broke some of their earlier ideas.

A good example of that is WatchDogs, where NVidia specifically locks out the d3d11, so the proxy wrapper was bypassed in the game, making no shader dumping happen. This happened because the game linked directly against nvapi64.lib, and that would go straight to system32 for calls. Other x64 DX11 games don't do this (CoD:ghosts), so it's something unique about their approach. I've manged to figure out a way to bypass their bypass, but we can definitely expect this sort of game-specific craziness.

Note that is true of Helix's DX9 dlls too, that's why there are multiple versions, some things are workaround for specific games. It won't always happen, and things from the same engine will be similar, but different engines typically do require some sort of tweaks.

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

Posted 08/14/2014 07:55 AM   
[quote="ForgottenProdigy"]Red Faction Armageddon DX11 opens but crashes soon afterwards. Here are the contents of the dx 11 log: http://pastebin . com/0QXHQuBH[/quote]So, hey, looking at this log, you are using Win8.1 and the dxgi.dll is not compatible with Win8.1 because Microsoft decided to change the API in a stupid way. It also broke SweetFx and other wrappers. For that older version of 3Dmigoto, dxgi was included because it was necessary for shader hunting to work. But that part won't work on Win8.1 because of the DXGI f*up. So that means you can't use those older releases for AC3 and AC4 on Win8.1 to look for shaders, you can only use it to play the game by deleting dxgi.dll. Since then, I've worked out a way to avoid dxgi.dll altogether, and newer code should work OK for shader hunting on Win8.1, although I haven't tried it. For 32 bit games, try the dlls with SR3, that is my most up to date code and has the dxgi fix. (or wait for me to build a new x32 standalone in the next couple of days. Need to finalize my class stuff first though.)
ForgottenProdigy said:Red Faction Armageddon DX11 opens but crashes soon afterwards. Here are the contents of the dx 11 log: http://pastebin . com/0QXHQuBH
So, hey, looking at this log, you are using Win8.1 and the dxgi.dll is not compatible with Win8.1 because Microsoft decided to change the API in a stupid way. It also broke SweetFx and other wrappers.

For that older version of 3Dmigoto, dxgi was included because it was necessary for shader hunting to work. But that part won't work on Win8.1 because of the DXGI f*up. So that means you can't use those older releases for AC3 and AC4 on Win8.1 to look for shaders, you can only use it to play the game by deleting dxgi.dll.

Since then, I've worked out a way to avoid dxgi.dll altogether, and newer code should work OK for shader hunting on Win8.1, although I haven't tried it.

For 32 bit games, try the dlls with SR3, that is my most up to date code and has the dxgi fix.

(or wait for me to build a new x32 standalone in the next couple of days. Need to finalize my class stuff first though.)

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

Posted 08/14/2014 08:15 AM   
Mike answered the question about the z distance and if statements in the AC fix. It's a way to separate out HUD elements without impacting game elements. Last question in your list I think was about the iniParams: [code]float4 iniParams = IniParams.Load(0);[/code] This comes directly from the d3dx.ini file, and are the constants available to any shader. So in the .ini: [code]; ------------------------------------------------------------------------------------------------------ ; Constants to pass directly to shaders as IniParams ; ------------------------------------------------------------------------------------------------------ [Constants] ; x = 0.8 ; y = 1.0 ; z = 1.2 ; w = 2.0 [/code] As noted, those are passed directly to the shader after the Load(0). So, anything you assign in the Constants section can be used in the shader code itself. We have only used it for pushing the HUD to depth, as a way to allow people to tune the HUD to their preference.
Mike answered the question about the z distance and if statements in the AC fix. It's a way to separate out HUD elements without impacting game elements.

Last question in your list I think was about the iniParams:

float4 iniParams = IniParams.Load(0);


This comes directly from the d3dx.ini file, and are the constants available to any shader.

So in the .ini:

; ------------------------------------------------------------------------------------------------------
; Constants to pass directly to shaders as IniParams
; ------------------------------------------------------------------------------------------------------
[Constants]
; x = 0.8
; y = 1.0
; z = 1.2
; w = 2.0

As noted, those are passed directly to the shader after the Load(0). So, anything you assign in the Constants section can be used in the shader code itself. We have only used it for pushing the HUD to depth, as a way to allow people to tune the HUD to their preference.

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

Posted 08/14/2014 08:20 AM   
When I start up saints row the third with the 3dmigoto 0.65 on windows 7 using the dx11 shortcut, it caches the shaders but the screen is fully black except for a few hud pieces. I deleted the old profile using nvidia inspector and made a new one to which I added the exe's for the game. I clicked apply after setting the new profile. I tried restarting the computer. Not sure what's up with the game.
When I start up saints row the third with the 3dmigoto 0.65 on windows 7 using the dx11 shortcut, it caches the shaders but the screen is fully black except for a few hud pieces. I deleted the old profile using nvidia inspector and made a new one to which I added the exe's for the game. I clicked apply after setting the new profile. I tried restarting the computer. Not sure what's up with the game.

Posted 08/15/2014 09:48 PM   
[quote="ForgottenProdigy"]When I start up saints row the third with the 3dmigoto 0.65 on windows 7 using the dx11 shortcut, it caches the shaders but the screen is fully black except for a few hud pieces. I deleted the old profile using nvidia inspector and made a new one to which I added the exe's for the game. I clicked apply after setting the new profile. I tried restarting the computer. Not sure what's up with the game.[/quote]Yep, that one is extra annoying. Saint's games are really odd in a lot of aspects. This is a bug in 3Dmigoto though, where when you generate an entire shader cache with "export_hlsl=1", that it will Decompile every shader that it sees. Bugs in the Decompiler can sometimes generate bogus HLSL code (about 1 out of 500 or so). They are then recompiled to use in the game, and the result can be this sort of glitch. This is getting better over time, but it's going to be a problem for awhile. Best strategy is to do the "export_hlsl=1" once, then, set it back to "export_hlsl=0" and move that cache of shaders to an unused folder (not named ShaderFixes or ShaderCache). That way you can search them, but they don't impact game play or looking for shaders. You then use the CopyOnMark feature when you find a shader to fix, then search for similar code structure in your alternate cache, to find all instances of your desired fix. You want to do that offline search anyway, because it's much, much faster than finding and fixing them one-by-one.
ForgottenProdigy said:When I start up saints row the third with the 3dmigoto 0.65 on windows 7 using the dx11 shortcut, it caches the shaders but the screen is fully black except for a few hud pieces. I deleted the old profile using nvidia inspector and made a new one to which I added the exe's for the game. I clicked apply after setting the new profile. I tried restarting the computer. Not sure what's up with the game.
Yep, that one is extra annoying. Saint's games are really odd in a lot of aspects.

This is a bug in 3Dmigoto though, where when you generate an entire shader cache with "export_hlsl=1", that it will Decompile every shader that it sees. Bugs in the Decompiler can sometimes generate bogus HLSL code (about 1 out of 500 or so). They are then recompiled to use in the game, and the result can be this sort of glitch.

This is getting better over time, but it's going to be a problem for awhile.

Best strategy is to do the "export_hlsl=1" once, then, set it back to "export_hlsl=0" and move that cache of shaders to an unused folder (not named ShaderFixes or ShaderCache). That way you can search them, but they don't impact game play or looking for shaders.

You then use the CopyOnMark feature when you find a shader to fix, then search for similar code structure in your alternate cache, to find all instances of your desired fix. You want to do that offline search anyway, because it's much, much faster than finding and fixing them one-by-one.

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

Posted 08/16/2014 12:04 AM   
Ok, now I got the game working but I keep getting errros with trying to fix shaders. First of all the game doesn't support autoreloading of shaders if they were moved into the folder after the game was opened. Then I've found a couple of shaders after hunting for quite a while. So I try to fix this one that is responsible for the halo of his main upper body. I try everything, stereo.x*(o0.w - stereo.y) stereo.x*(stereo.y) stereo.x*(-stereo.y) stereo.x*(o0.w - stereo.y)*(some variable) but it just won't do anything. I picked o0 because it's responsible for the svtarget0 and is the only shader being exported: [code]out float4 o0 : SV_Target0[/code] Plus putting [code]o0 = 0;[/code] makes it dissapear. So then I decide to cheat and look at the fixed files in the zip of SR3 that's on github. And to my surprise my shader isn't anywhere in the shader fixes folder. In fact, none of my 8 or so shaders that I've carefully picked after hours of hunting are there. Not a single one. I don't get what I'm doing wrong. Sigh. edit: I was like screw it, let's just play with the fix for now but when I uninstall the hunting version for the fixed 3d version the game starts up and just shows a black screen. Saints row [b]really[/b] doesn't want me to play it in proper 3d. Screw you too saints row. edit 2: launched it again a bit later and it works and runs a blazingly smooth 0.5 fps on my 780ti. We should change the catchphrase of can it run crysis to can it run saints row 3 in 3D?
Ok, now I got the game working but I keep getting errros with trying to fix shaders. First of all the game doesn't support autoreloading of shaders if they were moved into the folder after the game was opened.


Then I've found a couple of shaders after hunting for quite a while. So I try to fix this one that is responsible for the halo of his main upper body. I try everything,

stereo.x*(o0.w - stereo.y)
stereo.x*(stereo.y)
stereo.x*(-stereo.y)
stereo.x*(o0.w - stereo.y)*(some variable)

but it just won't do anything. I picked o0 because it's responsible for the svtarget0 and is the only shader being exported:
out float4 o0 : SV_Target0

Plus putting
o0 = 0;

makes it dissapear. So then I decide to cheat and look at the fixed files in the zip of SR3 that's on github. And to my surprise my shader isn't anywhere in the shader fixes folder. In fact, none of my 8 or so shaders that I've carefully picked after hours of hunting are there. Not a single one. I don't get what I'm doing wrong. Sigh.


edit: I was like screw it, let's just play with the fix for now but when I uninstall the hunting version for the fixed 3d version the game starts up and just shows a black screen. Saints row really doesn't want me to play it in proper 3d. Screw you too saints row.

edit 2: launched it again a bit later and it works and runs a blazingly smooth 0.5 fps on my 780ti. We should change the catchphrase of can it run crysis to can it run saints row 3 in 3D?

Posted 08/17/2014 04:47 AM   
[quote="ForgottenProdigy"]Ok, now I got the game working but I keep getting errros with trying to fix shaders. First of all the game doesn't support autoreloading of shaders if they were moved into the folder after the game was opened. Then I've found a couple of shaders after hunting for quite a while. So I try to fix this one that is responsible for the halo of his main upper body. I try everything, stereo.x*(o0.w - stereo.y) stereo.x*(stereo.y) stereo.x*(-stereo.y) stereo.x*(o0.w - stereo.y)*(some variable) but it just won't do anything. I picked o0 because it's responsible for the svtarget0 and is the only shader being exported: [code]out float4 o0 : SV_Target0[/code] Plus putting [code]o0 = 0;[/code] makes it dissapear. So then I decide to cheat and look at the fixed files in the zip of SR3 that's on github. And to my surprise my shader isn't anywhere in the shader fixes folder. In fact, none of my 8 or so shaders that I've carefully picked after hours of hunting are there. Not a single one. I don't get what I'm doing wrong. Sigh. edit: I was like screw it, let's just play with the fix for now but when I uninstall the hunting version for the fixed 3d version the game starts up and just shows a black screen. Saints row [b]really[/b] doesn't want me to play it in proper 3d. Screw you too saints row. edit 2: launched it again a bit later and it works and runs a blazingly smooth 0.5 fps on my 780ti. We should change the catchphrase of can it run crysis to can it run saints row 3 in 3D?[/quote]Yeah, these games are really odd. Glad to see you taking a look. It's definitely a bit weird, and there is more trial and error than I'd like with 3Dmigoto. For reloading the shaders live, that should work. This is how Mike and I look at stuff all the time. You don't do the manual move ala Helix though- I made it automatically copy the files to improve the experience. When you hit Num3 or Num6 to Mark a selected shader, it will automatically make a copy in ShaderFixes for you. You can then edit that live, without having to quit. Is this process not working for you? The halos on the body- are you running with SLI? Neither Mike nor I could figure out a way to fix the halos when running with single GPU. It's not clear at all why that would matter, but we tried pretty hard to make single GPU work. I seem to recall that black screen from single GPU as well, not sure. It could be that the shaders you found are in fact the right shaders for single GPU mode, and that there are different ones for SLI. Try to match the fix we made in the SR for the character halos- it doesn't follow the sequence you specify above. With that you are stereoizing the output, but usually the output o0 is already stereoized automatically by the driver. For the halo fix, you want to also steroize any texture that is associated with that o0 as well. Because it's the texture that is off, not the vertex. Show me the whole shader you've found, and let's take a look. If you can get it work in single GPU that would be fantastic. (Also by the way, you can search Github directly in case that's easier than downloading them.)
ForgottenProdigy said:Ok, now I got the game working but I keep getting errros with trying to fix shaders. First of all the game doesn't support autoreloading of shaders if they were moved into the folder after the game was opened.


Then I've found a couple of shaders after hunting for quite a while. So I try to fix this one that is responsible for the halo of his main upper body. I try everything,

stereo.x*(o0.w - stereo.y)
stereo.x*(stereo.y)
stereo.x*(-stereo.y)
stereo.x*(o0.w - stereo.y)*(some variable)

but it just won't do anything. I picked o0 because it's responsible for the svtarget0 and is the only shader being exported:
out float4 o0 : SV_Target0

Plus putting
o0 = 0;

makes it dissapear. So then I decide to cheat and look at the fixed files in the zip of SR3 that's on github. And to my surprise my shader isn't anywhere in the shader fixes folder. In fact, none of my 8 or so shaders that I've carefully picked after hours of hunting are there. Not a single one. I don't get what I'm doing wrong. Sigh.


edit: I was like screw it, let's just play with the fix for now but when I uninstall the hunting version for the fixed 3d version the game starts up and just shows a black screen. Saints row really doesn't want me to play it in proper 3d. Screw you too saints row.

edit 2: launched it again a bit later and it works and runs a blazingly smooth 0.5 fps on my 780ti. We should change the catchphrase of can it run crysis to can it run saints row 3 in 3D?
Yeah, these games are really odd. Glad to see you taking a look. It's definitely a bit weird, and there is more trial and error than I'd like with 3Dmigoto.

For reloading the shaders live, that should work. This is how Mike and I look at stuff all the time. You don't do the manual move ala Helix though- I made it automatically copy the files to improve the experience. When you hit Num3 or Num6 to Mark a selected shader, it will automatically make a copy in ShaderFixes for you. You can then edit that live, without having to quit. Is this process not working for you?


The halos on the body- are you running with SLI? Neither Mike nor I could figure out a way to fix the halos when running with single GPU. It's not clear at all why that would matter, but we tried pretty hard to make single GPU work.

I seem to recall that black screen from single GPU as well, not sure.


It could be that the shaders you found are in fact the right shaders for single GPU mode, and that there are different ones for SLI.

Try to match the fix we made in the SR for the character halos- it doesn't follow the sequence you specify above. With that you are stereoizing the output, but usually the output o0 is already stereoized automatically by the driver. For the halo fix, you want to also steroize any texture that is associated with that o0 as well. Because it's the texture that is off, not the vertex.

Show me the whole shader you've found, and let's take a look. If you can get it work in single GPU that would be fantastic.

(Also by the way, you can search Github directly in case that's easier than downloading them.)

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

Posted 08/17/2014 06:44 AM   
  10 / 141    
Scroll To Top