[url]http://store.steampowered.com/app/404680/Hob/[/url]
Zelda meets Rime in this one. With shadows off, 3D looks really good. A few issues, but nothing too distracting.
An absolutely gorgeous game from the developers of the Torchlight series (Runic Games.)
I noticed that Torchlight 1 and 2 were never fixed. This game is running on the same engine which is based on Ogre3D. I wasn't sure if it was running on OpenGL or DirectX, but since you got 3D to kick in it looks like it's DirectX.
I've been looking forward to this game for a while, i'll probably give it a hot this weekend.
I noticed that Torchlight 1 and 2 were never fixed. This game is running on the same engine which is based on Ogre3D. I wasn't sure if it was running on OpenGL or DirectX, but since you got 3D to kick in it looks like it's DirectX.
I've been looking forward to this game for a while, i'll probably give it a hot this weekend.
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
I am about 80 minutes in and think it is brilliant - the look and quality of Rime for me (and Rime is one of my favorites of 2017), but gameplay more like Zelda.
It is DX11 - CM kicks in as well.
I am about 80 minutes in and think it is brilliant - the look and quality of Rime for me (and Rime is one of my favorites of 2017), but gameplay more like Zelda.
[quote="bo3b"][img]https://forums.geforce.com/cmd/default/download-comment-attachment/73766/[/img]
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/73767/[/img]
[img]https://forums.geforce.com/cmd/default/download-comment-attachment/73768/[/img][/quote]
Those Screenshots look pretty promising. Did you fix any of the shaders or did you just disable the shadows? I played for about 30 minutes yesterday in 2D and it look like a really neat game. if one of the more experienced shader hackers are not looking at fixing it, I might give it a shot when i have some free time (Divinity 2 is eating up most of it right now).
Those Screenshots look pretty promising. Did you fix any of the shaders or did you just disable the shadows? I played for about 30 minutes yesterday in 2D and it look like a really neat game. if one of the more experienced shader hackers are not looking at fixing it, I might give it a shot when i have some free time (Divinity 2 is eating up most of it right now).
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
Fun game - I just like puzzles (for the most part) so playing Easy on the battles. Great Part?-- Good Native Surround, which is rare these days, and yes playing with no shadows. Works for me.
@TheBigDogma, thanks for letting us know of the game :-)
Fun game - I just like puzzles (for the most part) so playing Easy on the battles. Great Part?-- Good Native Surround, which is rare these days, and yes playing with no shadows. Works for me.
@TheBigDogma, thanks for letting us know of the game :-)
NP - glad you are enjoying it. While I don't have the background to fix 'em, I can at least be the person willing to take a flyer on a new game to let the community know of its existence, if it works/identify the problems in 3D and give initial opinions on the type/quality of the game...
In my humble opinion... LOL
NP - glad you are enjoying it. While I don't have the background to fix 'em, I can at least be the person willing to take a flyer on a new game to let the community know of its existence, if it works/identify the problems in 3D and give initial opinions on the type/quality of the game...
I'm in the process of fixing this game and managed to get the shadows almost working. The issue i'm running into is that the shadows look ok towards the center of the screen but the further things are from the center the more they start to deviate. The game is deriving it's position from a depth map. I suspect that the fov/projection matrix is throwing off the calculated depth. I've tried applying stereo correction using three different methods and I get near identical results. Method 3 seems to be the most accurate. Here's the shader the modified code start at line 173:
// ---- Created with 3Dmigoto v1.2.65 on Fri Oct 06 23:26:26 2017
// I'm assuming that r5 is in view space since it's later transformed by constMat_inverseViewMainCam2 and constMat_viewToShadow matrices
float4 stereo = StereoParams.Load(0);
// method 1 convert r5 to screen space, apply stereo correction, revert back to view space.
//r5 = mul(constMat_proj,r5);
//r5.x -= stereo.x * (r5.z - stereo.y);
//r5 = mul(constMat_inverseProjMainCam,r5);
Here's some screenshots. Notice how in the first picture the shadows for the robot that's sitting down look fine. But in the second picture as i move away from him, they start to get messed up the further he is from the center of the screen.
[url=http://www.iforce.co.nz/View.aspx?i=vu0vxisy.c4s.jpg][img]http://iforce.co.nz/i/vu0vxisy.c4s.jpg[/img][/url]
[url=http://www.iforce.co.nz/View.aspx?i=hqwwhzpg.12c.jpg][img]http://iforce.co.nz/i/hqwwhzpg.12c.jpg[/img][/url]
[url=http://www.iforce.co.nz/View.aspx?i=5c0l54b0.kzy.jpg][img]http://iforce.co.nz/i/5c0l54b0.kzy.jpg[/img][/url]
Here's some screenshots. Notice how in the first picture the shadows for the robot that's sitting down look fine. But in the second picture as i move away from him, they start to get messed up the further he is from the center of the screen.
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
@sgsrules
Almost sure the r5.z value don't have the depth...only a fixed value.
In the comments you put that the depth was "throwing off"...is a possibility. That code should fix the shadows if the depth was there.....Maybe grab the depth from another register or TEXTCOORD (vX)...
@sgsrules
Almost sure the r5.z value don't have the depth...only a fixed value.
In the comments you put that the depth was "throwing off"...is a possibility. That code should fix the shadows if the depth was there.....Maybe grab the depth from another register or TEXTCOORD (vX)...
[quote="DHR"]@sgsrules
Almost sure the r5.z value don't have the depth...only a fixed value.
[/quote]
what do you mean by fixed value?
I'm pretty sure it has the depth value (or at least the z position in view space) because it is fixing the shadows. They work for the most part but stuff closer to the edges of the screen have errors.
[quote="DHR"]
In the comments you put that the depth was "throwing off"...is a possibility. That code should fix the shadows if the depth was there.....Maybe grab the depth from another register or TEXTCOORD (vX)...
[/quote]
The inputs v0,v1, v2 seem to just be texture coordinates of some sort and are not actual 3d vertex data.
Is there a way to figure out which vertex shader is paired with this pixel shader? If i could take a look at the vertex shader i could confirm what the inputs actually are. But just from looking at the code I'm pretty sure they're not positional data.
It looks like the position is being reconstructed from depth:
I'm making a ton of assumptions so please correct me if i'm wrong.
[code]
r0.xy = (int2)v0.xy; // screen tex coords?
r0.zw = float2(0,0);
r1.xyzw = DepthMap.Load(r0.xyw).xyzw; // Loads depth in r1
r1.y = dot(v1.xyz, v1.xyz); // magnitude of v1 squared
r1.y = rsqrt(r1.y); // reciprocal of the above line
r1.yzw = v1.xyz * r1.yyy; // normalizes directional vector
r2.xyz = r1.yzw * r1.xxx; // multiply normalized depth stored in r1.x by direction vector.
r2.xyz = float3(250,250,250) * r2.xyz; // multiply normalized depth by far clip 250.
r2.w = dot(r2.xyz, r2.xyz);
r2.w = rsqrt(r2.w);
r3.xyz = r2.xyz * r2.www; // normalizes vector
r4.xy = cmp(float2(2,0.999989986) < r1.xx); // comparison to check which far clip value to use
r1.yzw = float3(500,500,500) * r1.yzw; // multiply normalized depth by far clip 500.
r5.xyz = r4.xxx ? r1.yzw : r2.xyz; // I'm assuming r5 is reconstructed position from depth.
// r5 is set to either use r1.yzw (contains xyz position in view space) or r2.xyz depending on r4.x
[/code]
My guess is that the depth value is not being scaled or normalized correctly when it's multiplied by the projection matrix. The values are correct in the center but the perspective introduces errors as it moves towards the edges.
DHR said:@sgsrules
Almost sure the r5.z value don't have the depth...only a fixed value.
what do you mean by fixed value?
I'm pretty sure it has the depth value (or at least the z position in view space) because it is fixing the shadows. They work for the most part but stuff closer to the edges of the screen have errors.
DHR said:
In the comments you put that the depth was "throwing off"...is a possibility. That code should fix the shadows if the depth was there.....Maybe grab the depth from another register or TEXTCOORD (vX)...
The inputs v0,v1, v2 seem to just be texture coordinates of some sort and are not actual 3d vertex data.
Is there a way to figure out which vertex shader is paired with this pixel shader? If i could take a look at the vertex shader i could confirm what the inputs actually are. But just from looking at the code I'm pretty sure they're not positional data.
It looks like the position is being reconstructed from depth:
I'm making a ton of assumptions so please correct me if i'm wrong.
r0.xy = (int2)v0.xy; // screen tex coords?
r0.zw = float2(0,0);
r1.xyzw = DepthMap.Load(r0.xyw).xyzw; // Loads depth in r1
r1.y = dot(v1.xyz, v1.xyz); // magnitude of v1 squared
r1.y = rsqrt(r1.y); // reciprocal of the above line
r1.yzw = v1.xyz * r1.yyy; // normalizes directional vector
r2.xyz = r1.yzw * r1.xxx; // multiply normalized depth stored in r1.x by direction vector.
r2.xyz = float3(250,250,250) * r2.xyz; // multiply normalized depth by far clip 250.
r2.w = dot(r2.xyz, r2.xyz);
r2.w = rsqrt(r2.w);
r3.xyz = r2.xyz * r2.www; // normalizes vector
r4.xy = cmp(float2(2,0.999989986) < r1.xx); // comparison to check which far clip value to use
r1.yzw = float3(500,500,500) * r1.yzw; // multiply normalized depth by far clip 500.
r5.xyz = r4.xxx ? r1.yzw : r2.xyz; // I'm assuming r5 is reconstructed position from depth.
// r5 is set to either use r1.yzw (contains xyz position in view space) or r2.xyz depending on r4.x
My guess is that the depth value is not being scaled or normalized correctly when it's multiplied by the projection matrix. The values are correct in the center but the perspective introduces errors as it moves towards the edges.
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
Sorry for the delay in the responde...
I mean that the shadows have the same separation, same distance if you compare left/right eyes, that's why you have a working shadows in the middle...but broken in upper and lower part of the screen. In the upper part the separation of the shadows need to be closer (far) and the lower part more separate (Near).
In the constant buffer you have "const_NearClip"....maybe normalyze with that (multiply).
You can see the VS related searching for the shaders #hash in the "shaderusage.txt" file...located in the same folder than dll files.
I mean that the shadows have the same separation, same distance if you compare left/right eyes, that's why you have a working shadows in the middle...but broken in upper and lower part of the screen. In the upper part the separation of the shadows need to be closer (far) and the lower part more separate (Near).
In the constant buffer you have "const_NearClip"....maybe normalyze with that (multiply).
You can see the VS related searching for the shaders #hash in the "shaderusage.txt" file...located in the same folder than dll files.
[quote="DHR"]Sorry for the delay in the responde...[/quote]No problem, thanks for responding.
[quote="DHR"]I mean that the shadows have the same separation, same distance if you compare left/right eyes, that's why you have a working shadows in the middle...but broken in upper and lower part of the screen. In the upper part the separation of the shadows need to be closer (far) and the lower part more separate (Near).[/quote]The shadows, without the fix are at screen depth but with my fix they actually have correct separation and are different for each eye. If i increase/decrease the convergence they will project properly on the ground at teh right depth... but only in the center of the screen, errors are introduced towards the edges. I can see how you might think that the shadows were at a fixed depth from my screenshots since i have the convergence set so that the main character is at screen depth.[/quote][quote="DHR"]In the constant buffer you have "const_NearClip"....maybe normalyze with that (multiply).
You can see the VS related searching for the shaders #hash in the "shaderusage.txt" file...located in the same folder than dll files.[/quote]Great, I'll give it a look. Thanks again for the help!
DHR said:I mean that the shadows have the same separation, same distance if you compare left/right eyes, that's why you have a working shadows in the middle...but broken in upper and lower part of the screen. In the upper part the separation of the shadows need to be closer (far) and the lower part more separate (Near).
The shadows, without the fix are at screen depth but with my fix they actually have correct separation and are different for each eye. If i increase/decrease the convergence they will project properly on the ground at teh right depth... but only in the center of the screen, errors are introduced towards the edges. I can see how you might think that the shadows were at a fixed depth from my screenshots since i have the convergence set so that the main character is at screen depth.
DHR said:In the constant buffer you have "const_NearClip"....maybe normalyze with that (multiply).
You can see the VS related searching for the shaders #hash in the "shaderusage.txt" file...located in the same folder than dll files.
Great, I'll give it a look. Thanks again for the help!
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
Apparently I had used the shaderusage.txt file before but completely forgot about it, damn my shitty memory. Anyhow I took a look at the matching vertex shader:[code]
void main(
float4 v0 : POSITION0,
out float4 o0 : SV_POSITION0,
out float4 o1 : TEXCOORD0,
out float3 o2 : TEXCOORD2)
{
float4 r0,r1;
uint4 bitmask, uiDest;
float4 fDest;
o0.xyzw = v0.xyzw;
r0.xyz = v0.xyz;
r0.w = 1;
r1.x = dot(constMat_inverseProjMainCam._m00_m01_m02_m03, r0.xyzw);
r1.y = dot(constMat_inverseProjMainCam._m10_m11_m12_m13, r0.xyzw);
r1.z = dot(constMat_inverseProjMainCam._m20_m21_m22_m23, r0.xyzw);
o1.w = dot(constMat_inverseProjMainCam._m30_m31_m32_m33, r0.xyzw);
o1.xyz = r1.xyz;
o2.xyz = r1.xyz * float3(0.5,0.5,0.5) + float3(0.5,0.5,0.5);
return;
}
[/code]As you can see it's pretty simple. I'm 99% sure that it's simply drawing a fullscreen quad. It basically just outputs:
o0 (v0 in PS): vertex coords used as uv coords in ps shader.
o1 (v1 in PS): transformed by inverse projection matrix, gives you the view frustum corners in view space. This is used as a directional vector to reconstruct the position using the depth buffer in view space.
o2 (v2 in PS): ok this one is a bit confusing, it's the o1 view space vector but it's being transformed by *.5+.5 which is ussually used to convert from the -1 to 1 range to 0 to 1 range. Oddly enough the only time it's used in the PS is [code] r1.z = v2.y * 2 + -1;[/code] which converts it back from 0 to 1 to -1 to 1. For now i'll just attribute this to the developers sloppy shader code lol.
I'm pretty sure that somewhere in the PS the depth values are being fiddled with to offset the shadows or do something funky, there seem to be a lot of magic numbers in the shader. This is what's probably throwing off the correction at the corners of the screen.
Apparently I had used the shaderusage.txt file before but completely forgot about it, damn my shitty memory. Anyhow I took a look at the matching vertex shader:
void main(
float4 v0 : POSITION0,
out float4 o0 : SV_POSITION0,
out float4 o1 : TEXCOORD0,
out float3 o2 : TEXCOORD2)
{
float4 r0,r1;
uint4 bitmask, uiDest;
float4 fDest;
As you can see it's pretty simple. I'm 99% sure that it's simply drawing a fullscreen quad. It basically just outputs:
o0 (v0 in PS): vertex coords used as uv coords in ps shader.
o1 (v1 in PS): transformed by inverse projection matrix, gives you the view frustum corners in view space. This is used as a directional vector to reconstruct the position using the depth buffer in view space.
o2 (v2 in PS): ok this one is a bit confusing, it's the o1 view space vector but it's being transformed by *.5+.5 which is ussually used to convert from the -1 to 1 range to 0 to 1 range. Oddly enough the only time it's used in the PS is
r1.z = v2.y * 2 + -1;
which converts it back from 0 to 1 to -1 to 1. For now i'll just attribute this to the developers sloppy shader code lol.
I'm pretty sure that somewhere in the PS the depth values are being fiddled with to offset the shadows or do something funky, there seem to be a lot of magic numbers in the shader. This is what's probably throwing off the correction at the corners of the screen.
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
Zelda meets Rime in this one. With shadows off, 3D looks really good. A few issues, but nothing too distracting.
An absolutely gorgeous game from the developers of the Torchlight series (Runic Games.)
I've been looking forward to this game for a while, i'll probably give it a hot this weekend.
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
It is DX11 - CM kicks in as well.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
Those Screenshots look pretty promising. Did you fix any of the shaders or did you just disable the shadows? I played for about 30 minutes yesterday in 2D and it look like a really neat game. if one of the more experienced shader hackers are not looking at fixing it, I might give it a shot when i have some free time (Divinity 2 is eating up most of it right now).
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
@TheBigDogma, thanks for letting us know of the game :-)
In my humble opinion... LOL
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
Almost sure the r5.z value don't have the depth...only a fixed value.
In the comments you put that the depth was "throwing off"...is a possibility. That code should fix the shadows if the depth was there.....Maybe grab the depth from another register or TEXTCOORD (vX)...
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
what do you mean by fixed value?
I'm pretty sure it has the depth value (or at least the z position in view space) because it is fixing the shadows. They work for the most part but stuff closer to the edges of the screen have errors.
The inputs v0,v1, v2 seem to just be texture coordinates of some sort and are not actual 3d vertex data.
Is there a way to figure out which vertex shader is paired with this pixel shader? If i could take a look at the vertex shader i could confirm what the inputs actually are. But just from looking at the code I'm pretty sure they're not positional data.
It looks like the position is being reconstructed from depth:
I'm making a ton of assumptions so please correct me if i'm wrong.
My guess is that the depth value is not being scaled or normalized correctly when it's multiplied by the projection matrix. The values are correct in the center but the perspective introduces errors as it moves towards the edges.
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
I mean that the shadows have the same separation, same distance if you compare left/right eyes, that's why you have a working shadows in the middle...but broken in upper and lower part of the screen. In the upper part the separation of the shadows need to be closer (far) and the lower part more separate (Near).
In the constant buffer you have "const_NearClip"....maybe normalyze with that (multiply).
You can see the VS related searching for the shaders #hash in the "shaderusage.txt" file...located in the same folder than dll files.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
The shadows, without the fix are at screen depth but with my fix they actually have correct separation and are different for each eye. If i increase/decrease the convergence they will project properly on the ground at teh right depth... but only in the center of the screen, errors are introduced towards the edges. I can see how you might think that the shadows were at a fixed depth from my screenshots since i have the convergence set so that the main character is at screen depth. Great, I'll give it a look. Thanks again for the help!
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z
o0 (v0 in PS): vertex coords used as uv coords in ps shader.
o1 (v1 in PS): transformed by inverse projection matrix, gives you the view frustum corners in view space. This is used as a directional vector to reconstruct the position using the depth buffer in view space.
o2 (v2 in PS): ok this one is a bit confusing, it's the o1 view space vector but it's being transformed by *.5+.5 which is ussually used to convert from the -1 to 1 range to 0 to 1 range. Oddly enough the only time it's used in the PS is which converts it back from 0 to 1 to -1 to 1. For now i'll just attribute this to the developers sloppy shader code lol.
I'm pretty sure that somewhere in the PS the depth values are being fiddled with to offset the shadows or do something funky, there seem to be a lot of magic numbers in the shader. This is what's probably throwing off the correction at the corners of the screen.
Like my work? You can send a donation via Paypal to sgs.rules@gmail.com
Windows 7 Pro 64x - Nvidia Driver 398.82 - EVGA 980Ti SC - Optoma HD26 with Edid override - 3D Vision 2 - i7-8700K CPU at 5.0Ghz - ASROCK Z370 Ext 4 Motherboard - 32 GB RAM Corsair Vengeance - 512 GB Samsung SSD 850 Pro - Creative Sound Blaster Z