How to fix/disable shaders in games(DLL,guide and fixes).
  161 / 167    
Looking at that vs_3_0 code, it looks OK to me. I don't see anything there that seems suspicious, and it looks like the conversion worked. Look in the helix log file, and search for this CRC number and make sure that it compiles properly. If it's not compiling, you'll see an error in the log. If the main problem is a crash with the game, I think that is pretty unlikely to be this. Maybe, never say never, but in general shaders only cause bad visual behavior, not outright crashes. You can experiment with it to see. Comment out all of the code, except for the vs_3_0. Then try it with the I/O declarations, but no code.
Looking at that vs_3_0 code, it looks OK to me.

I don't see anything there that seems suspicious, and it looks like the conversion worked.

Look in the helix log file, and search for this CRC number and make sure that it compiles properly. If it's not compiling, you'll see an error in the log.


If the main problem is a crash with the game, I think that is pretty unlikely to be this. Maybe, never say never, but in general shaders only cause bad visual behavior, not outright crashes.

You can experiment with it to see. Comment out all of the code, except for the vs_3_0. Then try it with the I/O declarations, but no code.

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 11/16/2014 11:42 AM   
Thanks for the help. I tried to keep only the vs_3_0 => black screen. I put the complete converted shader: game crahs at the launch. This is not the first tie I had this behaviour with a game... The log examination show me that I had the following messages [code] ... CreateVertexShader CRC: 0x8D3711A3 pD3DXAssembleShaderFromFile Error in vertex shader result: 0x8876086C uaL_openlibs ... [/code] The converted shader is indeed 0x8D3711A3. I wonder what the "error in shader result" mean...
Thanks for the help.
I tried to keep only the vs_3_0 => black screen.
I put the complete converted shader: game crahs at the launch. This is not the first tie I had this behaviour with a game...
The log examination show me that I had the following messages

...
CreateVertexShader CRC: 0x8D3711A3

pD3DXAssembleShaderFromFile

Error in vertex shader result: 0x8876086C

uaL_openlibs
...


The converted shader is indeed 0x8D3711A3. I wonder what the "error in shader result" mean...

Posted 11/16/2014 04:34 PM   
[quote="lefuneste"]I do not manage to convert V1.1 vertex shader to V3.0. I tried to make it manually and with the shader converter tool, but I got crash with the game (RoF) with the modified shader. Here is the original shader [code]vs_1_1 def c66, 3, 1, 0, 0.999000013 def c67, 1000, 0, 0, 0 dcl_position v0 dcl_normal v1 dcl_texcoord v2 dcl_blendindices v3 dcl_texcoord1 v4 mov r0.w, c64.w mov r1.xyz, v0 mov r1.w, c64.w mul r2.x, v3.x, c66.x mov a0.x, r2.x dp4 r0.x, r1, c0[a0.x] dp4 r0.y, r1, c1[a0.x] dp4 r0.z, r1, c2[a0.x] dp4 oPos.x, r0, c60 dp4 oPos.y, r0, c61 dp4 oPos.z, r0, c62 dp4 oPos.w, r0, c63 dp3 r1.x, v1, c0[a0.x] dp3 r1.y, v1, c1[a0.x] dp3 r1.z, v1, c2[a0.x] dp3 r0.w, r1, r1 rsq r0.w, r0.w mul r1.xyz, r0.w, r1 mad r3, v4.xyzx, c66.yyyz, c66.zzzy dp4 r4.x, r3, c0[a0.x] dp4 r4.y, r3, c1[a0.x] dp4 r4.z, r3, c2[a0.x] add r2.xyz, -r4, c65 dp3 r0.w, r2, r1 mul r0.w, r0.w, c66.w mad r2.xyz, r1, r0.w, r4 mov oT1.xyz, r1 add r1.xyz, -r2, c65 mad r1.xyz, r1, -c67.x, r4 add oT2.xyz, -r0, r1 mov oT0.xy, v2 [/code] and the modified shader (by converter tool) [code] vs_3_0 def c66, 3, 1, 0, 0.999000013 def c67, 1000, 0, 0, 0 dcl_position o10 dcl_texcoord1 o1.xyz dcl_texcoord2 o2.xyz dcl_texcoord o0.xy dcl_position v0 dcl_normal v1 dcl_texcoord v2 dcl_blendindices v3 dcl_texcoord1 v4 mov r0.w, c64.w mov r1.xyz, v0 mov r1.w, c64.w mul r2.x, v3.x, c66.x mov a0.x, r2.x dp4 r0.x, r1, c0[a0.x] dp4 r0.y, r1, c1[a0.x] dp4 r0.z, r1, c2[a0.x] dp4 o10.x, r0, c60 dp4 o10.y, r0, c61 dp4 o10.z, r0, c62 dp4 o10.w, r0, c63 dp3 r1.x, v1, c0[a0.x] dp3 r1.y, v1, c1[a0.x] dp3 r1.z, v1, c2[a0.x] dp3 r0.w, r1, r1 rsq r0.w, r0.w mul r1.xyz, r0.w, r1 mad r3, v4.xyzx, c66.yyyz, c66.zzzy dp4 r4.x, r3, c0[a0.x] dp4 r4.y, r3, c1[a0.x] dp4 r4.z, r3, c2[a0.x] add r2.xyz, -r4, c65 dp3 r0.w, r2, r1 mul r0.w, r0.w, c66.w mad r2.xyz, r1, r0.w, r4 mov o1.xyz, r1 add r1.xyz, -r2, c65 mad r1.xyz, r1, -c67.x, r4 add o2.xyz, -r0, r1 mov o0.xy, v2[/code] if someone can help...[/quote] In the fixed code change: [code]mov a0.x, r2.x[/code] to [code]mova a0.x, r2.x[/code]
lefuneste said:I do not manage to convert V1.1 vertex shader to V3.0.
I tried to make it manually and with the shader converter tool, but I got crash with the game (RoF) with the modified shader.
Here is the original shader

vs_1_1
def c66, 3, 1, 0, 0.999000013
def c67, 1000, 0, 0, 0
dcl_position v0
dcl_normal v1
dcl_texcoord v2
dcl_blendindices v3
dcl_texcoord1 v4
mov r0.w, c64.w
mov r1.xyz, v0
mov r1.w, c64.w
mul r2.x, v3.x, c66.x
mov a0.x, r2.x
dp4 r0.x, r1, c0[a0.x]
dp4 r0.y, r1, c1[a0.x]
dp4 r0.z, r1, c2[a0.x]
dp4 oPos.x, r0, c60
dp4 oPos.y, r0, c61
dp4 oPos.z, r0, c62
dp4 oPos.w, r0, c63
dp3 r1.x, v1, c0[a0.x]
dp3 r1.y, v1, c1[a0.x]
dp3 r1.z, v1, c2[a0.x]
dp3 r0.w, r1, r1
rsq r0.w, r0.w
mul r1.xyz, r0.w, r1
mad r3, v4.xyzx, c66.yyyz, c66.zzzy
dp4 r4.x, r3, c0[a0.x]
dp4 r4.y, r3, c1[a0.x]
dp4 r4.z, r3, c2[a0.x]
add r2.xyz, -r4, c65
dp3 r0.w, r2, r1
mul r0.w, r0.w, c66.w
mad r2.xyz, r1, r0.w, r4
mov oT1.xyz, r1
add r1.xyz, -r2, c65
mad r1.xyz, r1, -c67.x, r4
add oT2.xyz, -r0, r1
mov oT0.xy, v2



and the modified shader (by converter tool)
vs_3_0
def c66, 3, 1, 0, 0.999000013
def c67, 1000, 0, 0, 0
dcl_position o10
dcl_texcoord1 o1.xyz
dcl_texcoord2 o2.xyz
dcl_texcoord o0.xy
dcl_position v0
dcl_normal v1
dcl_texcoord v2
dcl_blendindices v3
dcl_texcoord1 v4
mov r0.w, c64.w
mov r1.xyz, v0
mov r1.w, c64.w
mul r2.x, v3.x, c66.x
mov a0.x, r2.x
dp4 r0.x, r1, c0[a0.x]
dp4 r0.y, r1, c1[a0.x]
dp4 r0.z, r1, c2[a0.x]
dp4 o10.x, r0, c60
dp4 o10.y, r0, c61
dp4 o10.z, r0, c62
dp4 o10.w, r0, c63
dp3 r1.x, v1, c0[a0.x]
dp3 r1.y, v1, c1[a0.x]
dp3 r1.z, v1, c2[a0.x]
dp3 r0.w, r1, r1
rsq r0.w, r0.w
mul r1.xyz, r0.w, r1
mad r3, v4.xyzx, c66.yyyz, c66.zzzy
dp4 r4.x, r3, c0[a0.x]
dp4 r4.y, r3, c1[a0.x]
dp4 r4.z, r3, c2[a0.x]
add r2.xyz, -r4, c65
dp3 r0.w, r2, r1
mul r0.w, r0.w, c66.w
mad r2.xyz, r1, r0.w, r4
mov o1.xyz, r1
add r1.xyz, -r2, c65
mad r1.xyz, r1, -c67.x, r4
add o2.xyz, -r0, r1
mov o0.xy, v2


if someone can help...


In the fixed code change:
mov a0.x, r2.x


to

mova a0.x, r2.x

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 11/16/2014 04:58 PM   
[quote="mike_ar69"] In the fixed code change: [code]mov a0.x, r2.x[/code] to [code]mova a0.x, r2.x[/code][/quote] It works ! Well the game is no more crashing but the shader result is not the same as the original one. I have the same effect when putting the original 1.1 shader in the shaderoverride directory.
mike_ar69 said:
In the fixed code change:
mov a0.x, r2.x


to

mova a0.x, r2.x


It works ! Well the game is no more crashing but the shader result is not the same as the original one.
I have the same effect when putting the original 1.1 shader in the shaderoverride directory.

Posted 11/16/2014 09:26 PM   
[quote="lefuneste"][quote="mike_ar69"] In the fixed code change: [code]mov a0.x, r2.x[/code] to [code]mova a0.x, r2.x[/code][/quote] I made the change but the game is still crashing...[/quote] Do you get the same error message in the error log? If you comment out everything from line 17 to the end what happens? If you comment out everything from line 18 to the end what happens? This mov <-> mova is the only thing I have experienced that causes crashes and the solution is to chnage mov->mova. Otherwise I can't see anything else immediately wrong...
lefuneste said:
mike_ar69 said:
In the fixed code change:
mov a0.x, r2.x


to

mova a0.x, r2.x


I made the change but the game is still crashing...

Do you get the same error message in the error log?
If you comment out everything from line 17 to the end what happens?
If you comment out everything from line 18 to the end what happens?

This mov <-> mova is the only thing I have experienced that causes crashes and the solution is to chnage mov->mova. Otherwise I can't see anything else immediately wrong...

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 11/16/2014 09:39 PM   
Try changing all of the [i][a0.x][/i] items to be[i] [a0.x + 0][/i]. Looks like nine of them.
Try changing all of the [a0.x] items to be [a0.x + 0]. Looks like nine of 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 11/17/2014 05:15 AM   
[quote="bo3b"]Try changing all of the [i][a0.x][/i] items to be[i] [a0.x + 0][/i]. Looks like nine of them. [/quote] I had done it, but it changes nothing. The shader is still not providing the same effect Here are some link to a zip including some jps pictures (before applying modified shader and after): [URL=http://turbobit.net/5s2kh9ti6y4q.html]NVStereoscopic3D.IMG.zip[/URL] It may help to understand the problem...
bo3b said:Try changing all of the [a0.x] items to be [a0.x + 0]. Looks like nine of them.


I had done it, but it changes nothing. The shader is still not providing the same effect
Here are some link to a zip including some jps pictures (before applying modified shader and after):
NVStereoscopic3D.IMG.zip
It may help to understand the problem...

Posted 11/17/2014 09:08 PM   
[quote="lefuneste"][quote="bo3b"]Try changing all of the [i][a0.x][/i] items to be[i] [a0.x + 0][/i]. Looks like nine of them. [/quote] I had done it, but it changes nothing. The shader is still not providing the same effect Here are some link to a zip including some jps pictures (before applying modified shader and after): [URL=http://turbobit.net/5s2kh9ti6y4q.html]NVStereoscopic3D.IMG.zip[/URL] It may help to understand the problem...[/quote] OK that is wierd. I might be missing something but it looks like the viewpoint is the only things changing between the before and after images - I can't see any rendering issues otherwise. Let me understand this: 1. With no shader (at all) in the shader override directory you get the "before" images? 2. With either the VS1.1 shader or the fixed VS3.0 shader you get the same "after" images? If no.2 is true then the shader conversion is working. But clearly something else is not right. I've never seen a case where the viewpoint moves but everything is otherwise rendered correctly. A quick question - I can't see any rendering issues in your images, so what reason do you have for "fixing" this shader? It looks like you could simply not have it in the shaderoverride folder in the first place and avoid all the trouble?
lefuneste said:
bo3b said:Try changing all of the [a0.x] items to be [a0.x + 0]. Looks like nine of them.


I had done it, but it changes nothing. The shader is still not providing the same effect
Here are some link to a zip including some jps pictures (before applying modified shader and after):
NVStereoscopic3D.IMG.zip
It may help to understand the problem...

OK that is wierd. I might be missing something but it looks like the viewpoint is the only things changing between the before and after images - I can't see any rendering issues otherwise. Let me understand this:
1. With no shader (at all) in the shader override directory you get the "before" images?
2. With either the VS1.1 shader or the fixed VS3.0 shader you get the same "after" images?

If no.2 is true then the shader conversion is working. But clearly something else is not right. I've never seen a case where the viewpoint moves but everything is otherwise rendered correctly.

A quick question - I can't see any rendering issues in your images, so what reason do you have for "fixing" this shader? It looks like you could simply not have it in the shaderoverride folder in the first place and avoid all the trouble?

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 11/17/2014 09:30 PM   
Well, I should have given more information when posting the screenshot. The problem I want to fix is in the "aldis sight" model (here is a view of the real one: http://www.google.fr/imgres?imgurl=http://www.johnsshawaviation.co.uk/wordpress/wp-content/uploads/2012/10/SC-View-through-Aldis-sight.jpg&imgrefurl=http://www.johnsshawaviation.co.uk/wordpress/sopwith-camel-f1-2/sopwith-camel-equipment/sopwith-camel-armament/&h=717&w=1024&tbnid=DSe0qr5DOxw90M:&zoom=1&tbnh=90&tbnw=129&usg=__CanLVVYZ1u2S5aVTyw-1vMaAi2g=&docid=SCU1Zas1v7VowM&client=firefox-a&sa=X&ei=6atrVJ-lLoKNaO_xgcgC&ved=0CCMQ9QEwAA&dur=3363). In standard game, the circle in the sight is not usable with "strong" 3D depth and convergence, as you can see in the "before_1" jps. So I want to reduce the spacing between the left and right eye drawn for the circle. The before_2 and before_3 jps are made to show the shader effect when you see it with a lateral offset (in Rise of flight like many other sims you can translate your virtual head left & right to see outside the cockpit). The tube is opaque when seen from far right and there is a kind of black halo when you only look partially into the sight. But after changing the shader with the 3_0 version, the tube is no more opaque (as seen in after_1 jps) and it seems that there is also no more circle sight (only mounting rings and end of tube seems visible in after_2.jps).
Well, I should have given more information when posting the screenshot.
The problem I want to fix is in the "aldis sight" model (here is a view of the real one: http://www.google.fr/imgres?imgurl=http://www.johnsshawaviation.co.uk/wordpress/wp-content/uploads/2012/10/SC-View-through-Aldis-sight.jpg&imgrefurl=http://www.johnsshawaviation.co.uk/wordpress/sopwith-camel-f1-2/sopwith-camel-equipment/sopwith-camel-armament/&h=717&w=1024&tbnid=DSe0qr5DOxw90M:&zoom=1&tbnh=90&tbnw=129&usg=__CanLVVYZ1u2S5aVTyw-1vMaAi2g=&docid=SCU1Zas1v7VowM&client=firefox-a&sa=X&ei=6atrVJ-lLoKNaO_xgcgC&ved=0CCMQ9QEwAA&dur=3363).

In standard game, the circle in the sight is not usable with "strong" 3D depth and convergence, as you can see in the "before_1" jps. So I want to reduce the spacing between the left and right eye drawn for the circle. The before_2 and before_3 jps are made to show the shader effect when you see it with a lateral offset (in Rise of flight like many other sims you can translate your virtual head left & right to see outside the cockpit). The tube is opaque when seen from far right and there is a kind of black halo when you only look partially into the sight.
But after changing the shader with the 3_0 version, the tube is no more opaque (as seen in after_1 jps) and it seems that there is also no more circle sight (only mounting rings and end of tube seems visible in after_2.jps).

Posted 11/18/2014 08:43 PM   
I looked at your screen shots. (One request, please don't use bad sharing services like turboit, that might be the most annoying service I've seen to date. Use the much simpler PaperClip icon in top right AFTER you make a post, in order to attach jps images.) This seems like a Helix bug of some form, maybe because Helix only operates on SM3 shaders. I see that the tube is no longer opaque, and that is probably because the shader has been disabled. Either by bug, or by shader. The 1.1 shader in the folder can possibly make HelixMod skip the shader and give this effect. Not sure what happens in this case, but it's probably a bug. The 3.0 shader should work, but may not be compiling correctly still. Take a look at the log again, and make sure it is compiling. Any "Error in vertex shader result" means that it has a syntax error in the code and is thus not functional. I would expect to have it still be opaque in this case, but there may be a 1.1 to 3.0 conflict.
I looked at your screen shots. (One request, please don't use bad sharing services like turboit, that might be the most annoying service I've seen to date. Use the much simpler PaperClip icon in top right AFTER you make a post, in order to attach jps images.)


This seems like a Helix bug of some form, maybe because Helix only operates on SM3 shaders. I see that the tube is no longer opaque, and that is probably because the shader has been disabled. Either by bug, or by shader.

The 1.1 shader in the folder can possibly make HelixMod skip the shader and give this effect. Not sure what happens in this case, but it's probably a bug.

The 3.0 shader should work, but may not be compiling correctly still. Take a look at the log again, and make sure it is compiling. Any "Error in vertex shader result" means that it has a syntax error in the code and is thus not functional. I would expect to have it still be opaque in this case, but there may be a 1.1 to 3.0 conflict.

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 11/19/2014 05:09 AM   
Sorry for the sharing service, I didn't notice the paperclip before ! I also discovered the problem: I was not aware that there was new version of the dll. I just installed the last one from the repository (http://helixmod.wikispot.org/oldvers) and did have no more black screen when leaving only vs_3_0 instruction to disable shader. So I also remove the "movea" instruction and ...the shader is now working! Please forgive me to have make you spent your time with my stupid questions... I wonder if this version is more compatible with latest nvidia drivers...
Sorry for the sharing service, I didn't notice the paperclip before !
I also discovered the problem: I was not aware that there was new version of the dll. I just installed the last one from the repository (http://helixmod.wikispot.org/oldvers) and did have no more black screen when leaving only vs_3_0 instruction to disable shader. So I also remove the "movea" instruction and ...the shader is now working!
Please forgive me to have make you spent your time with my stupid questions...
I wonder if this version is more compatible with latest nvidia drivers...

Posted 11/19/2014 09:36 PM   
Working on FF XIII-2 I'm trying to fix a aiming circle (for throwing Mog) that has some issues: http://photos.3dvisionlive.com/3d4dd/image/5490c30dd475fe6e780000b2/ The same shader and so the same issues appear when there is a random encounter and a circle around the character indicates how far You have to run to evade the fight. This is the original VSEC583D1A: [code] // // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 vs_3_0 def c0, 1, 0, 0, 0 def c1, -0.5, 2, -2, 0 dcl_position v0 dcl_texcoord v1 dcl_position o0 dcl_texcoord o1.xy dcl_texcoord1 o2.xy add r0.xy, c1.x, v1 mul o2.xy, r0, c1.yzzw mad o0, v0.xyzx, c0.xxxy, c0.yyyx mov o1.xy, v1 // approximately 4 instruction slots used[/code] I have played around with it and used the prime directive (Xnew = Xold + Separation * (W - Convergence)) on o0, o1 and o2. With o0 and o2 I could observe no change but with the modified o1 I got an improvement: http://photos.3dvisionlive.com/3d4dd/image/5490c32fd475fe3e770000a5/ As You can see the aiming help is correctly 3D but turned from a circle into a strip. This is the code I have used: [code]// // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 vs_3_0 def c200, 0, 0.5, 0.0625, 5 // 0.0625 prime directive reference value def c0, 1, 0, 0, 0 def c1, -0.5, 2, -2, 0 dcl_2d s0 // Sampler used to fetch stereo params dcl_position v0 dcl_texcoord v1 dcl_position o0 dcl_texcoord o1.xy dcl_texcoord1 o2.xy add r0.xy, c1.x, v1 mul o2.xy, r0, c1.yzzw mad o0, v0.xyzx, c0.xxxy, c0.yyyx // mov o1.xy, v1 mov r1.xy, v1 // use prime directive on o1 texldl r30, c200.z, s0 add r30.w, r1.w, -r30.y mul r30.z, r30.x, r30.w add r1.x, r1.x, r30.z mov o1, r1 // approximately 4 instruction slots used[/code] I is already an improvement and the aiming help is usable in this combination of strip and curve. Also the distance to escape the agro range is displayed correctly as the strip changes its orientation with the moving direction. So just out of curiosity: is there a code that turns the strip into a correctly placed circle?
Working on FF XIII-2 I'm trying to fix a aiming circle (for throwing Mog) that has some issues:
http://photos.3dvisionlive.com/3d4dd/image/5490c30dd475fe6e780000b2/
The same shader and so the same issues appear when there is a random encounter and a circle around the character indicates how far You have to run to evade the fight.
This is the original VSEC583D1A:
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
vs_3_0
def c0, 1, 0, 0, 0
def c1, -0.5, 2, -2, 0
dcl_position v0
dcl_texcoord v1
dcl_position o0
dcl_texcoord o1.xy
dcl_texcoord1 o2.xy
add r0.xy, c1.x, v1
mul o2.xy, r0, c1.yzzw
mad o0, v0.xyzx, c0.xxxy, c0.yyyx
mov o1.xy, v1

// approximately 4 instruction slots used

I have played around with it and used the prime directive (Xnew = Xold + Separation * (W - Convergence)) on o0, o1 and o2. With o0 and o2 I could observe no change but with the modified o1 I got an improvement:
http://photos.3dvisionlive.com/3d4dd/image/5490c32fd475fe3e770000a5/
As You can see the aiming help is correctly 3D but turned from a circle into a strip. This is the code I have used:
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
vs_3_0
def c200, 0, 0.5, 0.0625, 5 // 0.0625 prime directive reference value
def c0, 1, 0, 0, 0
def c1, -0.5, 2, -2, 0
dcl_2d s0 // Sampler used to fetch stereo params
dcl_position v0
dcl_texcoord v1
dcl_position o0
dcl_texcoord o1.xy
dcl_texcoord1 o2.xy
add r0.xy, c1.x, v1
mul o2.xy, r0, c1.yzzw
mad o0, v0.xyzx, c0.xxxy, c0.yyyx
// mov o1.xy, v1
mov r1.xy, v1 // use prime directive on o1
texldl r30, c200.z, s0
add r30.w, r1.w, -r30.y
mul r30.z, r30.x, r30.w
add r1.x, r1.x, r30.z
mov o1, r1
// approximately 4 instruction slots used


I is already an improvement and the aiming help is usable in this combination of strip and curve. Also the distance to escape the agro range is displayed correctly as the strip changes its orientation with the moving direction.
So just out of curiosity: is there a code that turns the strip into a correctly placed circle?

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 12/17/2014 12:11 AM   
So, the r1.w you are using for the depth hasn't been initialised here, which means it could contain any value and in this case has resulted in the effect to be stretched. I wouldn't recommend using an uninitialised register as you can't be certain that it will contain a useful value, and may even change randomly causing flickering. If we can't come up with anything better, I'd suggest using a constant value and playing around with it to find something acceptable. You might try seeing what happens if you use v0.z or v0.w for the depth, but it also wouldn't surprise me if this needs to be fixed elsewhere. It's probably also worth trying the stereo correction on the other outputs again but using v0.z for the depth to see if that makes any difference. What I find most interesting, is that you have altered the output texcoord0 and the effect got stretched, but [i]not clipped[/i] and still follows the terrain height correctly in each eye. That suggests to me that the vertices covering this effect might cover the full screen and there [i]might[/i] be something you can do in the pixel shader to fix it - the trick will be getting the correct depth to use for the stereo correction. All just a guess though - can you post the pixel shader?
So, the r1.w you are using for the depth hasn't been initialised here, which means it could contain any value and in this case has resulted in the effect to be stretched. I wouldn't recommend using an uninitialised register as you can't be certain that it will contain a useful value, and may even change randomly causing flickering. If we can't come up with anything better, I'd suggest using a constant value and playing around with it to find something acceptable.

You might try seeing what happens if you use v0.z or v0.w for the depth, but it also wouldn't surprise me if this needs to be fixed elsewhere. It's probably also worth trying the stereo correction on the other outputs again but using v0.z for the depth to see if that makes any difference.

What I find most interesting, is that you have altered the output texcoord0 and the effect got stretched, but not clipped and still follows the terrain height correctly in each eye. That suggests to me that the vertices covering this effect might cover the full screen and there might be something you can do in the pixel shader to fix it - the trick will be getting the correct depth to use for the stereo correction.

All just a guess though - can you post the pixel shader?

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 12/17/2014 03:12 AM   
I could find 2 PS that disable the circle when hunting: PS3CB12ABB: [code]// // Parameters: // // sampler2D $s_colorSampler; // sampler2D $s_depthSampler; // float4 $s_divisionInnerColorMatrix[4]; // float4 $s_divisionOuterColorMatrix[4]; // float $s_divisionRadius; // float $s_divisionWidthReciprocal; // float4 $s_lineInnerColor; // float4 $s_lineOuterColor; // float $s_lineRadius; // float $s_lineWidthReciprocal; // float4 $s_projectionReciprocal; // float3 $s_viewSpaceDirection; // float3 $s_viewSpacePosition; // // // Registers: // // Name Reg Size // --------------------------- ----- ---- // $s_divisionInnerColorMatrix c0 4 // $s_divisionOuterColorMatrix c4 4 // $s_viewSpacePosition c8 1 // $s_viewSpaceDirection c9 1 // $s_projectionReciprocal c10 1 // $s_lineRadius c11 1 // $s_lineWidthReciprocal c12 1 // $s_lineInnerColor c13 1 // $s_lineOuterColor c14 1 // $s_divisionRadius c15 1 // $s_divisionWidthReciprocal c16 1 // $s_colorSampler s0 1 // $s_depthSampler s1 1 // ps_3_0 def c17, 1, 0, 0.5, -0.212114394 def c18, -2, 3, -0.0187292993, 0.0742610022 def c19, 1.57072878, -2, 3.14159274, 0 def c20, 0.636619747, -1, 0, 0 dcl_texcoord v0.xy dcl_texcoord1 v1.xy dcl_2d s0 dcl_2d s1 texld r0, v0, s1 mad r0.yzw, v1.xxyx, c17.xxxy, c17.xyyx mul r0.xyz, r0.x, r0.yzww mov r1.xyz, c10 mad r0.xyz, r0, r1, -c8 dp3 r0.w, r0, r0 rsq r0.w, r0.w mul r0.xyz, r0.w, r0 rcp r0.w, r0.w dp3 r0.x, r0, c9 mad r0.y, r0_abs.x, c18.z, c18.w mad r0.y, r0.y, r0_abs.x, c17.w mad r0.y, r0.y, r0_abs.x, c19.x add r0.z, -r0_abs.x, c17.x cmp r0.x, r0.x, c17.y, c17.x rsq r0.z, r0.z rcp r0.z, r0.z mul r0.y, r0.z, r0.y mad r0.z, r0.y, c19.y, c19.z mad r0.x, r0.z, r0.x, r0.y mad r0.x, r0.x, c20.x, c20.y add_pp r0.x, -r0_abs.x, c17.x add r0.y, r0.w, -c11.x add r0.z, r0.w, -c15.x mul r0.z, r0.z, c16.x mad_sat r0.z, r0.z, c17.z, c17.z mul_sat r0.y, r0_abs.y, c12.x add_pp r0.y, -r0.y, c17.x mul_pp r0.x, r0.x, r0.y max r1.x, r0.x, c17.y mad r0.x, r1.x, c18.x, c18.y mul r0.y, r1.x, r1.x mul_pp r0.x, r0.y, r0.x mul_pp r0.y, r0.x, r0.x mov r1, c14 add r1, -r1, c13 mad_pp r1, r0.y, r1, c14 mad r0.y, r0.z, c18.x, c18.y mul r0.z, r0.z, r0.z mul r0.y, r0.z, r0.y texld_pp r2, v0, s0 mul_pp r3.xyz, r2.y, c1 mad_pp r3.xyz, r2.x, c0, r3 mad_pp r3.xyz, r2.z, c2, r3 add_pp r3.xyz, r3, c3 mul_pp r4.xyz, r2.y, c5 mad_pp r2.xyw, r2.x, c4.xyzz, r4.xyzz mad_pp r2.xyz, r2.z, c6, r2.xyww add_pp r2.xyz, r2, c7 lrp_pp r4.xyz, r0.y, r2, r3 add_pp r0.yzw, r1.xxyz, -r4.xxyz mul_pp r0.x, r0.x, r1.w mad_pp oC0.xyz, r0.x, r0.yzww, r4 mov_pp oC0.w, c17.x // approximately 54 instruction slots used (2 texture, 52 arithmetic) [/code] Replacing the value for lineRadius c11 changes the radius of the white line, divisionRadius c15 the radius of the orange colored area. The second PS8FF4A6B4 (looks quite unspecific to me): [code]// Parameters: // // float4 $s_depthParameter; // sampler2D $s_depthSampler; // // // Registers: // // Name Reg Size // ----------------- ----- ---- // $s_depthParameter c0 1 // $s_depthSampler s0 1 // ps_3_0 dcl_texcoord v0.xy dcl_2d s0 texld r0, v0, s0 add r0.x, r0.x, c0.z rcp r0.x, r0.x mul oC0, r0.x, c0.w // approximately 4 instruction slots used (1 texture, 3 arithmetic)[/code] I did some tests with r1.w and discovered the following. It doesn't matter which value I use (r1.w initialized or not) when the game starts and I use the aiming circle it looks like the one with the original code. When I press the reload button then I get the stripe instead of the circle and every future change to the code (e.g. disabling with mov o0.xyzw, c0.yyyy (=0)) has no effect at all. So the shader simply is broken after reloading it and this causes another shader to draw a stripe at correct depth instead of the circle. I hunted again the shader and discovered that VS D478466A also disables the circle: [code]// // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 vs_3_0 def c0, 1, 0, 0, 0 dcl_position v0 dcl_texcoord v1 dcl_position o0 dcl_texcoord o1.xy mad o0, v0.xyzx, c0.xxxy, c0.yyyx mov o1.xy, v1 // approximately 2 instruction slots used[/code] I know this shader as it is used for (intro)videos and has an effect on fog and lense flares, too. Similar to the HUD/menus I already have used the prime directive on dcl_position o0 to push the videos to some depth with success. But in addition to the usual formula I had to use line 4: [code] mad r1, v0.xyzx, c0.xxxy, c0.yyyx add r30.w, r1.w, -r30.y mul r30.z, r30.x, r30.w mul r30.z, r30.z, c200.x // special add r1.x, r1.x, r30.z mov o0, r1 [/code] With c200.x = -0.05 (<0) otherwise the videos popped out. This prime directive code is only active when the game starts not when playing and aiming. It tried this fix for the aiming situation (with and without line 4) but it had no effect on the depth of the aiming circle. It just remained at screen depth. Now I will try to use the prime directive on o0 (position) in VSEC583D1A again with v0.w or v0.z. Update: The prime directive on o0 changes the depth of the circle (quite a strong pop out) but like the original shader the depth doesn't change when I aim to different distances. In addition to this not only the circle but also the bigger part of the screen changes changes its depth (see the edges in http://photos.3dvisionlive.com/3d4dd/image/5491c9d4d475fe7478000110/). Using r1.w (from mad r1, v0.xyzx, c0.xxxy, c0.yyyx) or v0.w or v0.z for depth doesn't make a difference in the behavior and only changes to constant depth of the circle.
I could find 2 PS that disable the circle when hunting:
PS3CB12ABB:
//
// Parameters:
//
// sampler2D $s_colorSampler;
// sampler2D $s_depthSampler;
// float4 $s_divisionInnerColorMatrix[4];
// float4 $s_divisionOuterColorMatrix[4];
// float $s_divisionRadius;
// float $s_divisionWidthReciprocal;
// float4 $s_lineInnerColor;
// float4 $s_lineOuterColor;
// float $s_lineRadius;
// float $s_lineWidthReciprocal;
// float4 $s_projectionReciprocal;
// float3 $s_viewSpaceDirection;
// float3 $s_viewSpacePosition;
//
//
// Registers:
//
// Name Reg Size
// --------------------------- ----- ----
// $s_divisionInnerColorMatrix c0 4
// $s_divisionOuterColorMatrix c4 4
// $s_viewSpacePosition c8 1
// $s_viewSpaceDirection c9 1
// $s_projectionReciprocal c10 1
// $s_lineRadius c11 1
// $s_lineWidthReciprocal c12 1
// $s_lineInnerColor c13 1
// $s_lineOuterColor c14 1
// $s_divisionRadius c15 1
// $s_divisionWidthReciprocal c16 1
// $s_colorSampler s0 1
// $s_depthSampler s1 1
//

ps_3_0
def c17, 1, 0, 0.5, -0.212114394
def c18, -2, 3, -0.0187292993, 0.0742610022
def c19, 1.57072878, -2, 3.14159274, 0
def c20, 0.636619747, -1, 0, 0
dcl_texcoord v0.xy
dcl_texcoord1 v1.xy
dcl_2d s0
dcl_2d s1
texld r0, v0, s1
mad r0.yzw, v1.xxyx, c17.xxxy, c17.xyyx
mul r0.xyz, r0.x, r0.yzww
mov r1.xyz, c10
mad r0.xyz, r0, r1, -c8
dp3 r0.w, r0, r0
rsq r0.w, r0.w
mul r0.xyz, r0.w, r0
rcp r0.w, r0.w
dp3 r0.x, r0, c9
mad r0.y, r0_abs.x, c18.z, c18.w
mad r0.y, r0.y, r0_abs.x, c17.w
mad r0.y, r0.y, r0_abs.x, c19.x
add r0.z, -r0_abs.x, c17.x
cmp r0.x, r0.x, c17.y, c17.x
rsq r0.z, r0.z
rcp r0.z, r0.z
mul r0.y, r0.z, r0.y
mad r0.z, r0.y, c19.y, c19.z
mad r0.x, r0.z, r0.x, r0.y
mad r0.x, r0.x, c20.x, c20.y
add_pp r0.x, -r0_abs.x, c17.x
add r0.y, r0.w, -c11.x
add r0.z, r0.w, -c15.x
mul r0.z, r0.z, c16.x
mad_sat r0.z, r0.z, c17.z, c17.z
mul_sat r0.y, r0_abs.y, c12.x
add_pp r0.y, -r0.y, c17.x
mul_pp r0.x, r0.x, r0.y
max r1.x, r0.x, c17.y
mad r0.x, r1.x, c18.x, c18.y
mul r0.y, r1.x, r1.x
mul_pp r0.x, r0.y, r0.x
mul_pp r0.y, r0.x, r0.x
mov r1, c14
add r1, -r1, c13
mad_pp r1, r0.y, r1, c14
mad r0.y, r0.z, c18.x, c18.y
mul r0.z, r0.z, r0.z
mul r0.y, r0.z, r0.y
texld_pp r2, v0, s0
mul_pp r3.xyz, r2.y, c1
mad_pp r3.xyz, r2.x, c0, r3
mad_pp r3.xyz, r2.z, c2, r3
add_pp r3.xyz, r3, c3
mul_pp r4.xyz, r2.y, c5
mad_pp r2.xyw, r2.x, c4.xyzz, r4.xyzz
mad_pp r2.xyz, r2.z, c6, r2.xyww
add_pp r2.xyz, r2, c7
lrp_pp r4.xyz, r0.y, r2, r3
add_pp r0.yzw, r1.xxyz, -r4.xxyz
mul_pp r0.x, r0.x, r1.w
mad_pp oC0.xyz, r0.x, r0.yzww, r4
mov_pp oC0.w, c17.x

// approximately 54 instruction slots used (2 texture, 52 arithmetic)

Replacing the value for lineRadius c11 changes the radius of the white line, divisionRadius c15 the radius of the orange colored area.

The second PS8FF4A6B4 (looks quite unspecific to me):
// Parameters:
//
// float4 $s_depthParameter;
// sampler2D $s_depthSampler;
//
//
// Registers:
//
// Name Reg Size
// ----------------- ----- ----
// $s_depthParameter c0 1
// $s_depthSampler s0 1
//

ps_3_0
dcl_texcoord v0.xy
dcl_2d s0
texld r0, v0, s0
add r0.x, r0.x, c0.z
rcp r0.x, r0.x
mul oC0, r0.x, c0.w

// approximately 4 instruction slots used (1 texture, 3 arithmetic)


I did some tests with r1.w and discovered the following. It doesn't matter which value I use (r1.w initialized or not) when the game starts and I use the aiming circle it looks like the one with the original code. When I press the reload button then I get the stripe instead of the circle and every future change to the code (e.g. disabling with mov o0.xyzw, c0.yyyy (=0)) has no effect at all. So the shader simply is broken after reloading it and this causes another shader to draw a stripe at correct depth instead of the circle. I hunted again the shader and discovered that VS D478466A also disables the circle:
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
vs_3_0
def c0, 1, 0, 0, 0
dcl_position v0
dcl_texcoord v1
dcl_position o0
dcl_texcoord o1.xy
mad o0, v0.xyzx, c0.xxxy, c0.yyyx
mov o1.xy, v1

// approximately 2 instruction slots used

I know this shader as it is used for (intro)videos and has an effect on fog and lense flares, too. Similar to the HUD/menus I already have used the prime directive on dcl_position o0 to push the videos to some depth with success. But in addition to the usual formula I had to use line 4:
mad r1, v0.xyzx, c0.xxxy, c0.yyyx
add r30.w, r1.w, -r30.y
mul r30.z, r30.x, r30.w
mul r30.z, r30.z, c200.x // special
add r1.x, r1.x, r30.z
mov o0, r1

With c200.x = -0.05 (<0) otherwise the videos popped out. This prime directive code is only active when the game starts not when playing and aiming. It tried this fix for the aiming situation (with and without line 4) but it had no effect on the depth of the aiming circle. It just remained at screen depth.

Now I will try to use the prime directive on o0 (position) in VSEC583D1A again with v0.w or v0.z.

Update: The prime directive on o0 changes the depth of the circle (quite a strong pop out) but like the original shader the depth doesn't change when I aim to different distances. In addition to this not only the circle but also the bigger part of the screen changes changes its depth (see the edges in http://photos.3dvisionlive.com/3d4dd/image/5491c9d4d475fe7478000110/). Using r1.w (from mad r1, v0.xyzx, c0.xxxy, c0.yyyx) or v0.w or v0.z for depth doesn't make a difference in the behavior and only changes to constant depth of the circle.

My original display name is 3d4dd - for some reason Nvidia changed it..?!

Posted 12/17/2014 01:15 PM   
[quote="3d4dd"]I could find 2 PS that disable the circle when hunting:[/quote] This one looks promising. There might be something you can do here, as it gets the depth from the d_depthSampler in s1. Maybe something like this: [code] ... dcl_2d s1 // Add the usual stereo declarations: def c220, 0, 1, 0.0625, 0.5 dcl_2d s13 texld r0, v0, s1 // r0.x now has the depth value - try adjusing v1 using r0.x as the depth: mov r20.xy, v1.xy texldl r31, c220.z, s13 add r31.w, r0.x, -r31.y mul r31.w, r31.w, r31.x add r20.x, r20.x, r31.w // Replace v1 with r20: mad r0.yzw, r20.xxyx, c17.xxxy, c17.xyyx ... [/code] I'm not sure if the depth value in sampler 1 will already be at the correct scale for that to work (or even if that is even on the right track), or if something else will need to be done with it. For now try it and just observe what (if any) difference it makes. [quote]The second PS8FF4A6B4 (looks quite unspecific to me):[/quote] It looks like that's rescaling a depth texture to another based on the depth buffer parameters. This is the type of rescaling that we *might* need in the above pixel shader, but I don't think there is anything that needs to be done to this one. [quote]I did some tests with r1.w and discovered the following. It doesn't matter which value I use (r1.w initialized or not) when the game starts and I use the aiming circle it looks like the one with the original code. When I press the reload button then I get the stripe instead of the circle and every future change to the code (e.g. disabling with mov o0.xyzw, c0.yyyy (=0)) has no effect at all. So the shader simply is broken after reloading it and this causes another shader to draw a stripe at correct depth instead of the circle.[/quote] When odd things are happening reloading shaders without modifying them, it likely means there is an error somewhere. I've hit this a bunch when I've tried to access a masked component of an input texcoord in a pixel shader (i.e. I've tried to access v0.z or v0.w, but v0 was declared dcl_texcoord v0.xy). Check if there are any errors in the LOG.txt, and you may need to completely restart the game if this happens and reloading is not working properly any more. I've hit other odd situations with similar results that I still cannot explain. Before I figured out the correct Unity Shadow fix I had made this attempt in World of Diving: https://github.com/DarkStarSword/3d-fixes/commit/d1dd4b99d50112faf92b0ed5199ab4a20b9f0ea5 That actually did kind of work on most surfaces if convergence was 0, but wasn't correct. After bringing in the correct fix I started getting absolutely bizzare behaviour when reloading shaders that I just couldn't explain - each time I reloaded the shadows would change in random ways - sometimes they would be fixed, sometimes they would be broken, sometimes they would do something completely bizarre, like pulsating from small to large and back again every few seconds. The cause was some weird conflict between my adjustment to that shader and the correct fix, and once I removed the above shader everything worked, but I still cannot explain why I got such weird behaviour with both in place, yet not with either one or the other :-/ [quote]I hunted again the shader and discovered that VS D478466A also disables the circle:[/quote]That one is just passing the position straight through (with w=1 so the perspective divide will have no effect, i.e. it's in screen coords) and passing the texcoord straight through to the pixel shader with no alterations, so I doubt this would be the correct place to fix it, except maybe to adjust it to a constant depth as you found (and a shader this simple will very likely affect lots of other things).
3d4dd said:I could find 2 PS that disable the circle when hunting:

This one looks promising. There might be something you can do here, as it gets the depth from the d_depthSampler in s1. Maybe something like this:
...
dcl_2d s1

// Add the usual stereo declarations:
def c220, 0, 1, 0.0625, 0.5
dcl_2d s13

texld r0, v0, s1

// r0.x now has the depth value - try adjusing v1 using r0.x as the depth:
mov r20.xy, v1.xy
texldl r31, c220.z, s13
add r31.w, r0.x, -r31.y
mul r31.w, r31.w, r31.x
add r20.x, r20.x, r31.w

// Replace v1 with r20:
mad r0.yzw, r20.xxyx, c17.xxxy, c17.xyyx
...


I'm not sure if the depth value in sampler 1 will already be at the correct scale for that to work (or even if that is even on the right track), or if something else will need to be done with it. For now try it and just observe what (if any) difference it makes.

The second PS8FF4A6B4 (looks quite unspecific to me):

It looks like that's rescaling a depth texture to another based on the depth buffer parameters. This is the type of rescaling that we *might* need in the above pixel shader, but I don't think there is anything that needs to be done to this one.

I did some tests with r1.w and discovered the following. It doesn't matter which value I use (r1.w initialized or not) when the game starts and I use the aiming circle it looks like the one with the original code. When I press the reload button then I get the stripe instead of the circle and every future change to the code (e.g. disabling with mov o0.xyzw, c0.yyyy (=0)) has no effect at all. So the shader simply is broken after reloading it and this causes another shader to draw a stripe at correct depth instead of the circle.

When odd things are happening reloading shaders without modifying them, it likely means there is an error somewhere. I've hit this a bunch when I've tried to access a masked component of an input texcoord in a pixel shader (i.e. I've tried to access v0.z or v0.w, but v0 was declared dcl_texcoord v0.xy). Check if there are any errors in the LOG.txt, and you may need to completely restart the game if this happens and reloading is not working properly any more.

I've hit other odd situations with similar results that I still cannot explain. Before I figured out the correct Unity Shadow fix I had made this attempt in World of Diving:

https://github.com/DarkStarSword/3d-fixes/commit/d1dd4b99d50112faf92b0ed5199ab4a20b9f0ea5

That actually did kind of work on most surfaces if convergence was 0, but wasn't correct. After bringing in the correct fix I started getting absolutely bizzare behaviour when reloading shaders that I just couldn't explain - each time I reloaded the shadows would change in random ways - sometimes they would be fixed, sometimes they would be broken, sometimes they would do something completely bizarre, like pulsating from small to large and back again every few seconds. The cause was some weird conflict between my adjustment to that shader and the correct fix, and once I removed the above shader everything worked, but I still cannot explain why I got such weird behaviour with both in place, yet not with either one or the other :-/

I hunted again the shader and discovered that VS D478466A also disables the circle:
That one is just passing the position straight through (with w=1 so the perspective divide will have no effect, i.e. it's in screen coords) and passing the texcoord straight through to the pixel shader with no alterations, so I doubt this would be the correct place to fix it, except maybe to adjust it to a constant depth as you found (and a shader this simple will very likely affect lots of other things).

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 12/19/2014 05:58 AM   
  161 / 167    
Scroll To Top