3Dmigoto now open-source...
  11 / 141    
[quote="bo3b"]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. [b]Is this process not working for you?[/b] 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.)[/quote] I'm using 3dmigoto 0.65 and I have to reload the d3dlog every time to find the marked shader, find the shader and copy the ps/vs_replace to shaderfixes every time. I'm using the 0.65 because it's the only non-game specific migoto that I've found on github. Also something very interesting is that you have no pixel shaders fixed in the fix. And I'm seeing a pattern in the fixes. Pretty much every fix has this. Basically anything that looks like this: [code] o0.xyzw = r2.xyzw; o2.xyzw = r2.xyzw;[/code] Fix the second float assigned. In this case o2. Or o1 in this example: [code] o0.xyzw = r2.xyzw; o1.xyzw = r2.xyzw;[/code] But in the shaders I've found not a single one has that pattern. Here are a few shaders (using dotcom (instead of .com) because I keep getting caught in the ban filter if I post links). http://pastebin dotcom/GdLkxsWk <- vertex http://pastebin dotcom/E91v63aa <- vertex http://pastebin dotcom/Ygx1VLZm <- pixel http://pastebin dotcom/wd4cf9it <- vertex When those shaders are disabled the item it applies to usually become semi-transparent. This is a very weird game.
bo3b said: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.)

I'm using 3dmigoto 0.65 and I have to reload the d3dlog every time to find the marked shader, find the shader and copy the ps/vs_replace to shaderfixes every time. I'm using the 0.65 because it's the only non-game specific migoto that I've found on github.

Also something very interesting is that you have no pixel shaders fixed in the fix. And I'm seeing a pattern in the fixes. Pretty much every fix has this. Basically anything that looks like this:
o0.xyzw = r2.xyzw;
o2.xyzw = r2.xyzw;

Fix the second float assigned. In this case o2. Or o1 in this example:
o0.xyzw = r2.xyzw;
o1.xyzw = r2.xyzw;

But in the shaders I've found not a single one has that pattern. Here are a few shaders (using dotcom (instead of .com) because I keep getting caught in the ban filter if I post links).

http://pastebin dotcom/GdLkxsWk <- vertex
http://pastebin dotcom/E91v63aa <- vertex
http://pastebin dotcom/Ygx1VLZm <- pixel
http://pastebin dotcom/wd4cf9it <- vertex

When those shaders are disabled the item it applies to usually become semi-transparent. This is a very weird game.

Posted 08/17/2014 06:14 PM   
[quote="ForgottenProdigy"]I'm using 3dmigoto 0.65 and I have to reload the d3dlog every time to find the marked shader, find the shader and copy the ps/vs_replace to shaderfixes every time. I'm using the 0.65 because it's the only non-game specific migoto that I've found on github.[/quote]Ah! Got it. Sorry about that. I've been overbooked on getting the Shaderhacker school up and have neglected to make an up to date release. That older version of the dll does not include the CopyOnMark feature, as it wasn't implemented then. Best bet is to use the newest code, but to strip out the ShaderFixes folder. There is no game specific [i]code [/i]yet, only game specific ShaderFixes folder. The latest x32 version is for SR3: [url]https://github.com/bo3b/3Dmigoto/releases/download/0.70-beta/3Dmigoto-SR3-0.70.zip[/url] And has the added benefit of numerous Decompiler fixes for the SR3 and 4 shader code. I'll try to put out a generic release in the next couple of days. (code will be same as SR3 version) [quote="ForgottenProdigy"]Also something very interesting is that you have no pixel shaders fixed in the fix. And I'm seeing a pattern in the fixes. Pretty much every fix has this. Basically anything that looks like this: [code] o0.xyzw = r2.xyzw; o2.xyzw = r2.xyzw;[/code] Fix the second float assigned. In this case o2. Or o1 in this example: [code] o0.xyzw = r2.xyzw; o1.xyzw = r2.xyzw;[/code] But in the shaders I've found not a single one has that pattern. Here are a few shaders (using dotcom (instead of .com) because I keep getting caught in the ban filter if I post links). http://pastebin dotcom/GdLkxsWk <- vertex http://pastebin dotcom/E91v63aa <- vertex http://pastebin dotcom/Ygx1VLZm <- pixel http://pastebin dotcom/wd4cf9it <- vertex When those shaders are disabled the item it applies to usually become semi-transparent. This is a very weird game.[/quote]Good eye. That is indeed the crux of the halo fix for the SLI version, where we stereo adjust the Texture position that is otherwise missed by the automatic mode. That assignment you quote above is actually part of the game code, we don't do that part. That's why the halo breaks, because the o0 is automatically steroized by the driver after the shader exits, but it misses the o2 that has the same value. In this shader: [url]https://github.com/bo3b/3Dmigoto/blob/master/SR3/ShaderFixes/00840d524a01265c-vs_replace.txt[/url] You can see that I added at the bottom: [code]// Auto-fixed shader float4 stereo = StereoParams.Load(0); o2.x += stereo.x * (o2.w - stereo.y); return; [/code] To stereoize that texture as well. You probably already noticed this, but just to be sure. (this code is added by an automatic feature of 3Dmigoto where you set "fix_sv_position=1". Doesn't always work, but when it does work it fixes a lot. Mike prefers to find the pattern offline to do the same thing.) When the character becomes semi-transparent, I think that indicates that you definitely have the right shader. Not sure what to think of there being no Textures associated. I'll study your shaders and get back to you. BTW: you can paste those shaders into <code> blocks here and avoid the pastebin problem. The size limit for <code> is good.
ForgottenProdigy said:I'm using 3dmigoto 0.65 and I have to reload the d3dlog every time to find the marked shader, find the shader and copy the ps/vs_replace to shaderfixes every time. I'm using the 0.65 because it's the only non-game specific migoto that I've found on github.
Ah! Got it. Sorry about that. I've been overbooked on getting the Shaderhacker school up and have neglected to make an up to date release.

That older version of the dll does not include the CopyOnMark feature, as it wasn't implemented then.

Best bet is to use the newest code, but to strip out the ShaderFixes folder. There is no game specific code yet, only game specific ShaderFixes folder. The latest x32 version is for SR3: https://github.com/bo3b/3Dmigoto/releases/download/0.70-beta/3Dmigoto-SR3-0.70.zip

And has the added benefit of numerous Decompiler fixes for the SR3 and 4 shader code.

I'll try to put out a generic release in the next couple of days. (code will be same as SR3 version)


ForgottenProdigy said:Also something very interesting is that you have no pixel shaders fixed in the fix. And I'm seeing a pattern in the fixes. Pretty much every fix has this. Basically anything that looks like this:
o0.xyzw = r2.xyzw;
o2.xyzw = r2.xyzw;

Fix the second float assigned. In this case o2. Or o1 in this example:
o0.xyzw = r2.xyzw;
o1.xyzw = r2.xyzw;

But in the shaders I've found not a single one has that pattern. Here are a few shaders (using dotcom (instead of .com) because I keep getting caught in the ban filter if I post links).

http://pastebin dotcom/GdLkxsWk <- vertex
http://pastebin dotcom/E91v63aa <- vertex
http://pastebin dotcom/Ygx1VLZm <- pixel
http://pastebin dotcom/wd4cf9it <- vertex

When those shaders are disabled the item it applies to usually become semi-transparent. This is a very weird game.
Good eye. That is indeed the crux of the halo fix for the SLI version, where we stereo adjust the Texture position that is otherwise missed by the automatic mode.

That assignment you quote above is actually part of the game code, we don't do that part. That's why the halo breaks, because the o0 is automatically steroized by the driver after the shader exits, but it misses the o2 that has the same value. In this shader: https://github.com/bo3b/3Dmigoto/blob/master/SR3/ShaderFixes/00840d524a01265c-vs_replace.txt

You can see that I added at the bottom:
// Auto-fixed shader
float4 stereo = StereoParams.Load(0);
o2.x += stereo.x * (o2.w - stereo.y);
return;

To stereoize that texture as well. You probably already noticed this, but just to be sure.

(this code is added by an automatic feature of 3Dmigoto where you set "fix_sv_position=1". Doesn't always work, but when it does work it fixes a lot. Mike prefers to find the pattern offline to do the same thing.)


When the character becomes semi-transparent, I think that indicates that you definitely have the right shader. Not sure what to think of there being no Textures associated. I'll study your shaders and get back to you.

BTW: you can paste those shaders into <code> blocks here and avoid the pastebin problem. The size limit for <code> is good.

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 11:31 PM   
OK, I took a look at your shaders there, and the basic structure is very similar to the SLI version of them. Same inputs and outputs for example, same matrices being used. They are doing something different with the texture outputs, a pattern that doesn't match others we've seen. Nevertheless, they are outputing those textures, and it's very likely it's the same problem. Same symptom, same effect when disabled. So, please try experimenting with those output textures, and see if you get any results. Try setting each piece to 0 to start, like o1=0; o2=0, o3=0; in different tests, and see if you can narrow down which texture is key. Or, try stereoizing the output using that code above, for each texture in the outputs, and see if you get any effect. You might hit upon a given texture that needs stereoization and crack the puzzle on the non-SLI version. One last note, I see it doing a divide by 1/2 in one spot, and I stumbled across doing the stereoization with a /2 as working in some cases. If you get some effect, but it still seems off, try that as well. The matrices are sometimes 2x too big, going from -1..1 instead of 0..1.
OK, I took a look at your shaders there, and the basic structure is very similar to the SLI version of them. Same inputs and outputs for example, same matrices being used.

They are doing something different with the texture outputs, a pattern that doesn't match others we've seen.

Nevertheless, they are outputing those textures, and it's very likely it's the same problem. Same symptom, same effect when disabled.


So, please try experimenting with those output textures, and see if you get any results. Try setting each piece to 0 to start, like o1=0; o2=0, o3=0; in different tests, and see if you can narrow down which texture is key.

Or, try stereoizing the output using that code above, for each texture in the outputs, and see if you get any effect. You might hit upon a given texture that needs stereoization and crack the puzzle on the non-SLI version.


One last note, I see it doing a divide by 1/2 in one spot, and I stumbled across doing the stereoization with a /2 as working in some cases. If you get some effect, but it still seems off, try that as well. The matrices are sometimes 2x too big, going from -1..1 instead of 0..1.

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/18/2014 02:35 AM   
I've looked for a couple of hours and giving the different floats values of 0 either makes a part of the suit dissapear or make it a blackish colour. Setting the stereo fix for each one doesn't do anything as far as I can see. I've been trying to compare the shaders and I've noticed that the shader that is being fixed is as you said assigned the value of SV_Position0 but I can't find anything similar so far. I've also noticed that the texture being fixed is usually a float 4 which makes sense a float 3 would be missing a [b][i]w[/i] [/b]value required for the stereo fix. I'll see what else I can find.
I've looked for a couple of hours and giving the different floats values of 0 either makes a part of the suit dissapear or make it a blackish colour. Setting the stereo fix for each one doesn't do anything as far as I can see. I've been trying to compare the shaders and I've noticed that the shader that is being fixed is as you said assigned the value of SV_Position0 but I can't find anything similar so far. I've also noticed that the texture being fixed is usually a float 4 which makes sense a float 3 would be missing a w value required for the stereo fix. I'll see what else I can find.

Posted 08/18/2014 08:04 AM   
I created a new Release build of the tool, as a standalone for people who want to use it to work on a game. You can go to this link, and download the zip file for use in any x32 game. (x64 will be added shortly.) [url]https://github.com/bo3b/3Dmigoto/releases/tag/x32-Release[/url] This includes all my latest bug fixes, and in theory should work well on pretty much any game. I'm sure there will be bugs, so if you run into a showstopper, please let me know here.
I created a new Release build of the tool, as a standalone for people who want to use it to work on a game.

You can go to this link, and download the zip file for use in any x32 game. (x64 will be added shortly.)

https://github.com/bo3b/3Dmigoto/releases/tag/x32-Release


This includes all my latest bug fixes, and in theory should work well on pretty much any game. I'm sure there will be bugs, so if you run into a showstopper, please let me know here.

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/19/2014 11:16 AM   
I was experimenting a little bit with the 0.77 release on a couple of games. Am I supposed to see red text at the top? With the Trials Fusion demo I don't see any text, but I'm able to cycle & dump individual shaders. Also is there a DumpAll feature? I also tested The Golf Club, but I'm unable to cycle or dump shaders. (3dmigoto not kicking in?)
I was experimenting a little bit with the 0.77 release on a couple of games. Am I supposed to see red text at the top? With the Trials Fusion demo I don't see any text, but I'm able to cycle & dump individual shaders. Also is there a DumpAll feature?

I also tested The Golf Club, but I'm unable to cycle or dump shaders. (3dmigoto not kicking in?)

Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35

Posted 08/23/2014 05:57 AM   
Awesome to have you give it a try! At present there is no red text across the top, and in fact no visual indication that it is running. I hope to add something at some point, but getting it more solid has been my priority. In general, you should be able to tell if it's running by cycling shaders. 3Dmigoto always only uses the shaders in the current frame, I couldn't foresee any time when you'd actually want to cycle through shaders you can't presently see. When you find a shader that you want to mark, you can use the CopyOnMark feature, which will move the shader directly into the ShaderFixes folder, where it can be live edited, without having to quit and relaunch. You will also hear it make a beep sound. High beep on success, low beep on failure. There is a dumpall feature, but in DX11 games in particular, all doesn't mean all, because shaders are all load-on-demand. Set the [i]export_hlsl=1 [/i]in the d3dx.ini file, and that will generate an HLSL file for every shader that it sees. I also changed it so that instead of dumping ASM as separate option, it now includes the ASM as documentation (commented out) in the bottom of the HLSL file. If you ever think the shader may be malfunctioning, it's always possible that it Decompiled wrong, and the ASM will allow us to tell. For The Golf Club, I'm not sure what's happening. Set the [i]calls=1[/i] and [i]debug=1 [/i]in the d3dx.ini file to enable full logging. Then look for the d3d11_log.txt file as a start. Let me know what you see, or send me the log file for a look.
Awesome to have you give it a try!

At present there is no red text across the top, and in fact no visual indication that it is running. I hope to add something at some point, but getting it more solid has been my priority. In general, you should be able to tell if it's running by cycling shaders. 3Dmigoto always only uses the shaders in the current frame, I couldn't foresee any time when you'd actually want to cycle through shaders you can't presently see.

When you find a shader that you want to mark, you can use the CopyOnMark feature, which will move the shader directly into the ShaderFixes folder, where it can be live edited, without having to quit and relaunch. You will also hear it make a beep sound. High beep on success, low beep on failure.


There is a dumpall feature, but in DX11 games in particular, all doesn't mean all, because shaders are all load-on-demand. Set the export_hlsl=1 in the d3dx.ini file, and that will generate an HLSL file for every shader that it sees.

I also changed it so that instead of dumping ASM as separate option, it now includes the ASM as documentation (commented out) in the bottom of the HLSL file. If you ever think the shader may be malfunctioning, it's always possible that it Decompiled wrong, and the ASM will allow us to tell.


For The Golf Club, I'm not sure what's happening. Set the calls=1 and debug=1 in the d3dx.ini file to enable full logging. Then look for the d3d11_log.txt file as a start.

Let me know what you see, or send me the log file for a look.

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/23/2014 07:48 AM   
[quote="bo3b"]For The Golf Club, I'm not sure what's happening. Set the [i]calls=1[/i] and [i]debug=1 [/i]in the d3dx.ini file to enable full logging. Then look for the d3d11_log.txt file as a start.[/quote] Hey bo3b. So I set calls & debug to "1", but I'm not getting a d3d11_log.txt file. I also pasted the 3dMigoto files in the directory where the game's exe is located, as well as all of the directories above & below, but still no luck.
bo3b said:For The Golf Club, I'm not sure what's happening. Set the calls=1 and debug=1 in the d3dx.ini file to enable full logging. Then look for the d3d11_log.txt file as a start.

Hey bo3b. So I set calls & debug to "1", but I'm not getting a d3d11_log.txt file. I also pasted the 3dMigoto files in the directory where the game's exe is located, as well as all of the directories above & below, but still no luck.

Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35

Posted 08/23/2014 10:59 AM   
[quote="4everAwake"]Hey bo3b. So I set calls & debug to "1", but I'm not getting a d3d11_log.txt file. I also pasted the 3dMigoto files in the directory where the game's exe is located, as well as all of the directories above & below, but still no luck. [/quote]OK. Since you are getting no d3d11_log at all, that means that the d3d11.dll is not loading at all, as it generates the log file as the first thing it does. It's always possible that they are doing something similar to WatchDogs, where the game goes directly to System32 and bypasses the local directory proxy dlls. To confirm or disprove that, try deleting the d3d11.dll while the game is running. If it's been loaded at all, you'll get an error. If you get an error: That means it's WatchDogs style where the dll is loaded, but completely bypassed. I have a fix for this case. If you get no error: That means that the dll was never loaded at launch. Look for other directories that it might be setting as the working directory. If you already did all above and below, this is not as likely.
4everAwake said:Hey bo3b. So I set calls & debug to "1", but I'm not getting a d3d11_log.txt file. I also pasted the 3dMigoto files in the directory where the game's exe is located, as well as all of the directories above & below, but still no luck.
OK. Since you are getting no d3d11_log at all, that means that the d3d11.dll is not loading at all, as it generates the log file as the first thing it does.

It's always possible that they are doing something similar to WatchDogs, where the game goes directly to System32 and bypasses the local directory proxy dlls. To confirm or disprove that, try deleting the d3d11.dll while the game is running. If it's been loaded at all, you'll get an error.

If you get an error: That means it's WatchDogs style where the dll is loaded, but completely bypassed. I have a fix for this case.

If you get no error: That means that the dll was never loaded at launch. Look for other directories that it might be setting as the working directory. If you already did all above and below, this is not as likely.

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/23/2014 12:11 PM   
I deleted the d3d11.dll while the game was running, but I didn't get any errors. I'll continue to search for the working directory.
I deleted the d3d11.dll while the game was running, but I didn't get any errors. I'll continue to search for the working directory.

Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35

Posted 08/23/2014 01:37 PM   
OK, good to know. You can try this dependency walker tool, which will show you the dlls that are required at launch time. [url]http://www.dependencywalker.com/[/url] It can sometimes help understand the dependencies and how it might be working. If you see it picking up the 3Dmigoto d3d11.dll for example, that means it's in the dependency chain, but not being called. You can also launch from there, and see how the dlls are loaded dynamically. Not sure it will help, but sometimes.
OK, good to know. You can try this dependency walker tool, which will show you the dlls that are required at launch time.

http://www.dependencywalker.com/

It can sometimes help understand the dependencies and how it might be working.

If you see it picking up the 3Dmigoto d3d11.dll for example, that means it's in the dependency chain, but not being called. You can also launch from there, and see how the dlls are loaded dynamically. Not sure it will help, but sometimes.

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/24/2014 02:54 AM   
After countless hours I've given up on saints row for now, and am trying to fix sniper elite 3 which now opens with the 0.77 version. One of the issues is the campfire light is 2D (no depth at all). This is the code for the vertex shader responsible for the light: [code]Texture2D<float4> StereoParams : register(t125); void main( float3 v0 : Data0, out float4 o0 : SV_Position0) { float4 r0,r1,r2; uint4 bitmask; r0.y = g_fArcCosLimitAngle * v0.y; r0.x = v0.x; sincos(r0.xy, r0.xy, r1.xy); r0.y = v0.z * r0.y; r2.x = r0.y * r1.x; r2.y = r0.y * r0.x; r2.z = min(r1.y, v0.z); r0.xyz = g_fLightMeshRadius * r2.xyz; r1.xyz = g_xLightOrientation._m01_m11_m21 * r0.yyy; r0.xyw = g_xLightOrientation._m00_m10_m20 * r0.xxx + r1.xyz; r0.xyz = g_xLightOrientation._m02_m12_m22 * r0.zzz + r0.xyw; r0.xyz = g_xLightPos.xyz + r0.xyz; r1.xyzw = g_xViewProj._m01_m11_m21_m31 * r0.yyyy; r1.xyzw = g_xViewProj._m00_m10_m20_m30 * r0.xxxx + r1.xyzw; r0.xyzw = g_xViewProj._m02_m12_m22_m32 * r0.zzzz + r1.xyzw; o0.xyzw = g_xViewProj._m03_m13_m23_m33 + r0.xyzw; return; }[/code] Adding the basic code for stereo does absolutely nothing. No variation of it has any effect on the lightning of the campfire. Here's an example: [code]Texture2D<float4> StereoParams : register(t125); void main( float3 v0 : Data0, out float4 o0 : SV_Position0) { float4 r0,r1,r2; uint4 bitmask; r0.y = g_fArcCosLimitAngle * v0.y; r0.x = v0.x; sincos(r0.xy, r0.xy, r1.xy); r0.y = v0.z * r0.y; r2.x = r0.y * r1.x; r2.y = r0.y * r0.x; r2.z = min(r1.y, v0.z); r0.xyz = g_fLightMeshRadius * r2.xyz; r1.xyz = g_xLightOrientation._m01_m11_m21 * r0.yyy; r0.xyw = g_xLightOrientation._m00_m10_m20 * r0.xxx + r1.xyz; r0.xyz = g_xLightOrientation._m02_m12_m22 * r0.zzz + r0.xyw; r0.xyz = g_xLightPos.xyz + r0.xyz; r1.xyzw = g_xViewProj._m01_m11_m21_m31 * r0.yyyy; r1.xyzw = g_xViewProj._m00_m10_m20_m30 * r0.xxxx + r1.xyzw; r0.xyzw = g_xViewProj._m02_m12_m22_m32 * r0.zzzz + r1.xyzw; o0.xyzw = g_xViewProj._m03_m13_m23_m33 + r0.xyzw; float4 stereo = StereoParams.Load(0); o0.x += stereo.x * (o0.w - stereo.y); return; }[/code] I checked that it reloads properly by disabling it first and that worked. Also I've noticed it makes sounds when saving fixes and reloading. If that's intentional, it's a pretty cool feature especially the sound notifying that the shaderfix is already in the folder. This does have 2 pixel shaders that affect it so could the problem lie there? There's this one which I feel like is part of the problem: [code]SamplerState g_xTrilinearWrap_s : register(s2); Texture2D<float4> g_xTransparencyMap : register(t7); Texture2D<float4> StereoParams : register(t125); void main( float4 v0 : SV_Position0, float2 v1 : TEXCOORD0, out float4 o0 : SV_Target0) { float4 r0; uint4 bitmask; r0.xyzw = g_xTransparencyMap.Sample(g_xTrilinearWrap_s, v1.xy).xyzw; r0.x = -1.960784346e-001 + r0.w; r0.x = r0.x < 0.000000000e+000; if (r0.x != 0) discard; o0.xyzw = float4(1.000000e+000,1.000000e+000,1.000000e+000,1.000000e+000); return; }[/code] The [code]if r0.x != 0[/code] part in particular. I think that it throws away any values of the separation other than nothing which is why modifying the vertex shader does nothing (as I'm assuming pixel shader takes over the vertex shader values as the vertex shader exports SV_Position0 and the pixel shader imports it). However with my limited knowledge I don't know how to go about fixing this. Here are the 2 pixel shaders and 1 vertex shader that is responsible for the lightning if you want to take a look at it. https://www.mediafire.com/folder/txcse5vjwecwm/Documents
After countless hours I've given up on saints row for now, and am trying to fix sniper elite 3 which now opens with the 0.77 version.

One of the issues is the campfire light is 2D (no depth at all). This is the code for the vertex shader responsible for the light:
Texture2D<float4> StereoParams : register(t125);

void main(
float3 v0 : Data0,
out float4 o0 : SV_Position0)
{
float4 r0,r1,r2;
uint4 bitmask;
r0.y = g_fArcCosLimitAngle * v0.y;
r0.x = v0.x;
sincos(r0.xy, r0.xy, r1.xy);
r0.y = v0.z * r0.y;
r2.x = r0.y * r1.x;
r2.y = r0.y * r0.x;
r2.z = min(r1.y, v0.z);
r0.xyz = g_fLightMeshRadius * r2.xyz;
r1.xyz = g_xLightOrientation._m01_m11_m21 * r0.yyy;
r0.xyw = g_xLightOrientation._m00_m10_m20 * r0.xxx + r1.xyz;
r0.xyz = g_xLightOrientation._m02_m12_m22 * r0.zzz + r0.xyw;
r0.xyz = g_xLightPos.xyz + r0.xyz;
r1.xyzw = g_xViewProj._m01_m11_m21_m31 * r0.yyyy;
r1.xyzw = g_xViewProj._m00_m10_m20_m30 * r0.xxxx + r1.xyzw;
r0.xyzw = g_xViewProj._m02_m12_m22_m32 * r0.zzzz + r1.xyzw;
o0.xyzw = g_xViewProj._m03_m13_m23_m33 + r0.xyzw;
return;
}

Adding the basic code for stereo does absolutely nothing. No variation of it has any effect on the lightning of the campfire. Here's an example:
Texture2D<float4> StereoParams : register(t125);

void main(
float3 v0 : Data0,
out float4 o0 : SV_Position0)
{
float4 r0,r1,r2;
uint4 bitmask;
r0.y = g_fArcCosLimitAngle * v0.y;
r0.x = v0.x;
sincos(r0.xy, r0.xy, r1.xy);
r0.y = v0.z * r0.y;
r2.x = r0.y * r1.x;
r2.y = r0.y * r0.x;
r2.z = min(r1.y, v0.z);
r0.xyz = g_fLightMeshRadius * r2.xyz;
r1.xyz = g_xLightOrientation._m01_m11_m21 * r0.yyy;
r0.xyw = g_xLightOrientation._m00_m10_m20 * r0.xxx + r1.xyz;
r0.xyz = g_xLightOrientation._m02_m12_m22 * r0.zzz + r0.xyw;
r0.xyz = g_xLightPos.xyz + r0.xyz;
r1.xyzw = g_xViewProj._m01_m11_m21_m31 * r0.yyyy;
r1.xyzw = g_xViewProj._m00_m10_m20_m30 * r0.xxxx + r1.xyzw;
r0.xyzw = g_xViewProj._m02_m12_m22_m32 * r0.zzzz + r1.xyzw;
o0.xyzw = g_xViewProj._m03_m13_m23_m33 + r0.xyzw;
float4 stereo = StereoParams.Load(0);
o0.x += stereo.x * (o0.w - stereo.y);
return;
}

I checked that it reloads properly by disabling it first and that worked. Also I've noticed it makes sounds when saving fixes and reloading. If that's intentional, it's a pretty cool feature especially the sound notifying that the shaderfix is already in the folder.

This does have 2 pixel shaders that affect it so could the problem lie there? There's this one which I feel like is part of the problem:
SamplerState g_xTrilinearWrap_s : register(s2);
Texture2D<float4> g_xTransparencyMap : register(t7);

Texture2D<float4> StereoParams : register(t125);

void main(
float4 v0 : SV_Position0,
float2 v1 : TEXCOORD0,
out float4 o0 : SV_Target0)
{
float4 r0;
uint4 bitmask;
r0.xyzw = g_xTransparencyMap.Sample(g_xTrilinearWrap_s, v1.xy).xyzw;
r0.x = -1.960784346e-001 + r0.w;
r0.x = r0.x < 0.000000000e+000;
if (r0.x != 0) discard;
o0.xyzw = float4(1.000000e+000,1.000000e+000,1.000000e+000,1.000000e+000);
return;
}

The
if r0.x != 0

part in particular. I think that it throws away any values of the separation other than nothing which is why modifying the vertex shader does nothing (as I'm assuming pixel shader takes over the vertex shader values as the vertex shader exports SV_Position0 and the pixel shader imports it). However with my limited knowledge I don't know how to go about fixing this.
Here are the 2 pixel shaders and 1 vertex shader that is responsible for the lightning if you want to take a look at it.
https://www.mediafire.com/folder/txcse5vjwecwm/Documents

Posted 08/24/2014 04:00 AM   
@ForgottenProdigy In the VS example try using this code: [code]o0.x += stereo.x * (stereo.y);[/code] or [code]o0.x += stereo.x * (o0.w);[/code]
@ForgottenProdigy

In the VS example try using this code:

o0.x += stereo.x * (stereo.y);

or

o0.x += stereo.x * (o0.w);

MY WEB

Helix Mod - Making 3D Better

My 3D Screenshot Gallery

Like my fixes? you can donate to Paypal: dhr.donation@gmail.com

Posted 08/24/2014 11:18 AM   
[quote="DHR"]@ForgottenProdigy In the VS example try using this code: [code]o0.x += stereo.x * (stereo.y);[/code] or [code]o0.x += stereo.x * (o0.w);[/code] [/quote] Nope still nothing. I have pretty much tried nearly every permutation of the basic code but it just stays 2D.
DHR said:@ForgottenProdigy

In the VS example try using this code:

o0.x += stereo.x * (stereo.y);

or

o0.x += stereo.x * (o0.w);


Nope still nothing. I have pretty much tried nearly every permutation of the basic code but it just stays 2D.

Posted 08/24/2014 04:47 PM   
Suppose you try this also: [code]o0.x += stereo.x * 0.9;[/code] You can change the 0.9 value from any between 0 - 1 Also delete the .BIN file related to that fixed shader in ShaderCache and ShaderFixed (just in case). Fixing AC Liberation one fix don't applies because i have .BIN file in ShaderCache (the wrapper override with the .BIN)
Suppose you try this also:

o0.x += stereo.x * 0.9;


You can change the 0.9 value from any between 0 - 1


Also delete the .BIN file related to that fixed shader in ShaderCache and ShaderFixed (just in case). Fixing AC Liberation one fix don't applies because i have .BIN file in ShaderCache (the wrapper override with the .BIN)

MY WEB

Helix Mod - Making 3D Better

My 3D Screenshot Gallery

Like my fixes? you can donate to Paypal: dhr.donation@gmail.com

Posted 08/24/2014 05:21 PM   
  11 / 141    
Scroll To Top