Bo3b's School For Shaderhackers
  47 / 88    
Thanks for your reply. You are right, I didn't study the pdf document previously because you only referenced it in the lesson but I did do it a couple of days ago plus the rbwhitaker wiki and a few other articles. I now BEGIN to understand a bit how 3D and shaders work. I have all the time in the world so we will see how far I come. Previously I only played games using the fixes so now that I can try and fix broken ones myself is great. I can't see from the website (and I can't find it on Google) what language 3Dmitogo is written in? Is it a C variation, I did do a C course about 30 years ago because I had to program something but in the end the project was cancelled so I never actually did any practical C programming and now I have forgotten it completely.
Thanks for your reply. You are right, I didn't study the pdf document previously because you only referenced it in the lesson but I did do it a couple of days ago plus the rbwhitaker wiki and a few other articles. I now BEGIN to understand a bit how 3D and shaders work. I have all the time in the world so we will see how far I come. Previously I only played games using the fixes so now that I can try and fix broken ones myself is great.

I can't see from the website (and I can't find it on Google) what language 3Dmitogo is written in? Is it a C variation, I did do a C course about 30 years ago because I had to program something but in the end the project was cancelled so I never actually did any practical C programming and now I have forgotten it completely.

Posted 12/04/2015 11:51 AM   
It's written in C++ (actually like many "C++" projects it's really a bit of a hybrid of C and C++) since it needs to wrap DirectX, which is a C++ API, but if you have experience with other OO or imperative languages it's not that hard to muddle through if you keep a C++ reference handy - what types of languages are you familiar with? C++ does have a lot of weird gotchas though that you will find (and learn to avoid) with experience - for every cool feature listed in the C++ FAQ, there's an equally valid reason to debunk it in the FQA (Frequently Questioned Answers - well worth a read). This seems to have improved a lot with C++11, or maybe I'm just getting used to the language. Don't worry too much about that though - if you do submit any patches to 3DMigoto, bo3b and I would review them and provide feedback - we are both professional software engineers and try to follow good software engineering best practices like code review.
It's written in C++ (actually like many "C++" projects it's really a bit of a hybrid of C and C++) since it needs to wrap DirectX, which is a C++ API, but if you have experience with other OO or imperative languages it's not that hard to muddle through if you keep a C++ reference handy - what types of languages are you familiar with?

C++ does have a lot of weird gotchas though that you will find (and learn to avoid) with experience - for every cool feature listed in the C++ FAQ, there's an equally valid reason to debunk it in the FQA (Frequently Questioned Answers - well worth a read). This seems to have improved a lot with C++11, or maybe I'm just getting used to the language.

Don't worry too much about that though - if you do submit any patches to 3DMigoto, bo3b and I would review them and provide feedback - we are both professional software engineers and try to follow good software engineering best practices like code review.

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/04/2015 12:38 PM   
I am only familiar with Visual Pro/5 on Windows which is a pretty comprehensive Basic language, if it was in that language no problem. As said I was given a C course 30 years ago to program a WORM (write once read many) a sort of hard disk used for security backups of computer print-outs but the project was cancelled because it was too expensive so I haven't used it in practice and I don't know how quickly I could pick it up again and certainly not in relation with DirectX and Windows. OO is object oriented I assume, no I have never done object oriented programming. When I left my firm they were switching over a new version of the language with a Java interpreter, in which you could use Java statements but I never got that far.
I am only familiar with Visual Pro/5 on Windows which is a pretty comprehensive Basic language, if it was in that language no problem. As said I was given a C course 30 years ago to program a WORM (write once read many) a sort of hard disk used for security backups of computer print-outs but the project was cancelled because it was too expensive so I haven't used it in practice and I don't know how quickly I could pick it up again and certainly not in relation with DirectX and Windows.

OO is object oriented I assume, no I have never done object oriented programming. When I left my firm they were switching over a new version of the language with a Java interpreter, in which you could use Java statements but I never got that far.

Posted 12/04/2015 01:22 PM   
I am a little confused - you mentioned that you have programmed micro code, assembler and modified a compiler - surely you did not use BASIC for all of that, so what languages did you use for those and what architecture was the assembly code for? If you're only familiar with BASIC like languages, C/C++ would certainly be quite a steep learning curve from there (it certainly was for me when I taught myself C 15 years ago), so it's probably not worth considering at the moment since you are already focused on learning the art of shaderhacking. If you did want to learn another language (just in general - not to help out on 3DMigoto), I would really suggest learning Python well before thinking about learning something like C. Once you know a few languages it is much easier to pick up a new one, and Python is a great language to know since it's easy for a beginner to pick up, yet powerful enough for a pro to keep on using, and includes support for a whole bunch of programming paradigms, like imperative, Object Oriented (OO), Functional and others. Bookmark this page: http://www.diveintopython3.net/
I am a little confused - you mentioned that you have programmed micro code, assembler and modified a compiler - surely you did not use BASIC for all of that, so what languages did you use for those and what architecture was the assembly code for?

If you're only familiar with BASIC like languages, C/C++ would certainly be quite a steep learning curve from there (it certainly was for me when I taught myself C 15 years ago), so it's probably not worth considering at the moment since you are already focused on learning the art of shaderhacking.

If you did want to learn another language (just in general - not to help out on 3DMigoto), I would really suggest learning Python well before thinking about learning something like C. Once you know a few languages it is much easier to pick up a new one, and Python is a great language to know since it's easy for a beginner to pick up, yet powerful enough for a pro to keep on using, and includes support for a whole bunch of programming paradigms, like imperative, Object Oriented (OO), Functional and others. Bookmark this page: http://www.diveintopython3.net/

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/04/2015 02:52 PM   
Sorry I should have been more specific. The assembler and micro code was on Nixdorf 820/15, 880/45 and 8835 computers about 40 years ago. The compiler was on a proprietary language called LILA (list language) for the Nixdorf 880/45 and 8835 about 35 years ago. Oh I almost forgot that I worked on a UNIX computer (TARGON) in fact I worked exclusively for Nixdorf which when Heinz Nixdorf died was taken over by Siemens and after that I programmed in Visual Pro/5 for a software house ( there is a lot about Nixdorf on Google but most of it is in German). But as I said I was given a C course about 30 years ago so maybe I can pick it up again. Shame that I threw away my C language book (K&R) when I was tidying up a couple of years ago.
Sorry I should have been more specific. The assembler and micro code was on Nixdorf 820/15, 880/45 and 8835 computers about 40 years ago. The compiler was on a proprietary language called LILA (list language) for the Nixdorf 880/45 and 8835 about 35 years ago. Oh I almost forgot that I worked on a UNIX computer (TARGON) in fact I worked exclusively for Nixdorf which when Heinz Nixdorf died was taken over by Siemens and after that I programmed in Visual Pro/5 for a software house ( there is a lot about Nixdorf on Google but most of it is in German). But as I said I was given a C course about 30 years ago so maybe I can pick it up again. Shame that I threw away my C language book (K&R) when I was tidying up a couple of years ago.

Posted 12/04/2015 03:10 PM   
Hi! Still alive ;) And sorry for beeing quiet the last months as I didn't have much time for gaming and spent the time I had with MMORPGs instead of trying new games. But it is great to see how many high quality game fixes have been made meanwhile and I'm looking forward to play the fixed games :) I wanted to return to shader hacking with "Final Fantasy Lightning Returns" (= FF XIII-3) and so complete my fixes for the FF XIII trilogy. FF XIII-1 and -II offered a good S3D experience out of the box and only needed some minor fixes and tweaks. In contrary to this FF-LR is unplayable in S3D as it uses a new lighting system because of the introduced day and night cycle. So all shadows are "dynamic shadows" and are rendered in 2D at screen depth :( In addition to this only a very old version of Helix's debug dll works (https://s3.amazonaws.com/-HeliX-/DLLS/Debug.zip). The newer ones have no effect on the game or cause a crash. I could hunt the shaders for the shadows. I know that it is very difficult to fix shadows especially when a game uses its own engine and not a common one like Unreal,Unity, etc.. But maybe some of our experienced hackers could have a short look at the code if they recognize a pattern that allows to fix the shadows? This seems to be the PS for the shadows: [code]// Parameters: // // sampler2D $s_cameraDepthSampler; // sampler2D $s_directionSampler; // float2 $s_screenReciprocal; // sampler2D $s_shadowDepthSampler; // float2 $s_shadowOffset0; // float2 $s_shadowOffset1; // float2 $s_shadowOffset2; // float2 $s_shadowOffset3; // float2 $s_shadowOffset4; // float2 $s_shadowOffset5; // float2 $s_shadowOffset6; // float2 $s_shadowOffset7; // float4 $s_shadowRatio0; // float4 $s_shadowRatio1; // float4 $s_viewBound; // float4 $s_viewShadowMatrixFarColumn0; // float4 $s_viewShadowMatrixFarColumn1; // float4 $s_viewShadowMatrixFarColumn2; // float4 $s_viewShadowMatrixFarColumn3; // float4 $s_viewShadowMatrixNearColumn0; // float4 $s_viewShadowMatrixNearColumn1; // float4 $s_viewShadowMatrixNearColumn2; // float4 $s_viewShadowMatrixNearColumn3; // // // Registers: // // Name Reg Size // ------------------------------ ----- ---- // $s_viewBound c0 1 // $s_screenReciprocal c1 1 // $s_viewShadowMatrixNearColumn0 c2 1 // $s_viewShadowMatrixNearColumn1 c3 1 // $s_viewShadowMatrixNearColumn2 c4 1 // $s_viewShadowMatrixNearColumn3 c5 1 // $s_viewShadowMatrixFarColumn0 c6 1 // $s_viewShadowMatrixFarColumn1 c7 1 // $s_viewShadowMatrixFarColumn2 c8 1 // $s_viewShadowMatrixFarColumn3 c9 1 // $s_shadowRatio0 c10 1 // $s_shadowOffset0 c11 1 // $s_shadowOffset1 c12 1 // $s_shadowOffset2 c13 1 // $s_shadowOffset3 c14 1 // $s_shadowRatio1 c15 1 // $s_shadowOffset4 c16 1 // $s_shadowOffset5 c17 1 // $s_shadowOffset6 c18 1 // $s_shadowOffset7 c19 1 // $s_cameraDepthSampler s0 1 // $s_shadowDepthSampler s1 1 // $s_directionSampler s2 1 // ps_3_0 def c20, 0.5, 0.015625, 2, -1 def c21, 0, 0, 0, 0 dcl_texcoord v0.xyz dcl vPos.xy dcl_2d s0 dcl_2d s1 dcl_2d s2 frc r0.xy, vPos add r0.xy, -r0, vPos add r0.xy, r0, c20.x mul r0.zw, r0.xyxy, c1.xyxy mul r0.xy, r0, c20.y texld r1, r0, s2 mad r0.xy, r1.zyzw, c20.z, c20.w texld r1, r0.zwzw, s0 mul r2.xyz, r1.x, v0 mad r0.zw, v0.z, -r1.x, -c0.xyyw mov r1, c9 cmp r1, r0.z, r1, c5 mov r2.w, -c20.w dp4 r1.x, r1, r2 rcp r1.x, r1.x mov r3, c6 cmp r3, r0.z, r3, c2 dp4 r3.x, r3, r2 mov r4, c7 cmp r4, r0.z, r4, c3 dp4 r3.y, r4, r2 mul r1.xy, r1.x, r3 mad r1.zw, c11.xyxy, r0.xyyx, r1.xyxy texld r3, r1.zwzw, s1 mov r4, c8 cmp r4, r0.z, r4, c4 dp4 r0.z, r4, r2 add r1.z, -r3.x, r0.z mov r2.x, c21.x mad r2.yz, c12.xxyw, r0.xxyw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.zw, r1, r2.x, c10.xyxy add_pp r1.z, r1.w, r1.z mad r2.yz, c13.xxyw, r0.xyxw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.w, r1.w, r2.x, c10.z add_pp r1.z, r1.w, r1.z mad r2.yz, c14.xxyw, r0.xxyw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.w, r1.w, r2.x, c10.w add_pp r1.z, r1.w, r1.z mad r2.yz, c16.xxyw, r0.xyxw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.w, r1.w, r2.x, c15.x add_pp r1.z, r1.w, r1.z mad r2.yz, c17.xxyw, r0.xxyw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.w, r1.w, r2.x, c15.y add_pp r1.z, r1.w, r1.z mad r2.yz, c18.xxyw, r0.xyxw, r1.xxyw mad r0.xy, c19, r0, r1 texld r3, r0, s1 add r0.x, r0.z, -r3.x texld r3, r2.yzzw, s1 add r0.y, r0.z, -r3.x cmp_pp r0.xy, r0, r2.x, c15.wzzw add_pp r0.y, r0.y, r1.z add_pp r0.x, r0.x, r0.y cmp_pp oC0.w, r0.w, -c20.w, r0.x mov_pp oC0.xyz, -c20.w mov r14.x, c222.z[/code] There are several VS for the shadows but they all have a similar pattern like this example: [code]// Parameters: // // bool $isSkining; // float4 ModelBBoxOffSet; // float4 ModelBBoxScale; // float4 jointMatrices[144]; // float4x4 localProjectionMatrix; // // // Registers: // // Name Reg Size // --------------------- ----- ---- // $isSkining b0 1 // localProjectionMatrix c8 4 // jointMatrices c21 144 // ModelBBoxScale c169 1 // ModelBBoxOffSet c170 1 // vs_3_0 def c0, 3, 1, -1, 0 dcl_texcoord v0 dcl_texcoord6 v1 dcl_texcoord7 v2 dcl_position v3 dcl_position o0 dcl_texcoord o1 mov r0.xyz, c169 mad r0.xyz, v3, r0, c170 if b0 frc r1, v2 add r2, -r1, v2 slt r3, v2, -v2 slt r1, -r1, r1 mad r1, r3, r1, r2 mul r1, r1, c0.x mova a0.xy, r1 mul r2, v1.y, c21[a0.y] mul r3, v1.y, c22[a0.y] mul r4, v1.y, c23[a0.y] mad r2, c21[a0.x], v1.x, r2 mad r3, c22[a0.x], v1.x, r3 mad r4, c23[a0.x], v1.x, r4 mova a0.x, r1.z mad r2, c21[a0.x], v1.z, r2 mad r3, c22[a0.x], v1.z, r3 mad r4, c23[a0.x], v1.z, r4 mova a0.x, r1.w mad r1, c21[a0.x], v1.w, r2 mad r2, c22[a0.x], v1.w, r3 mad r3, c23[a0.x], v1.w, r4 mov r0.w, c0.y dp4 r1.x, r1, r0 dp4 r1.y, r2, r0 dp4 r0.z, r3, r0 mov r0.xy, r1 endif mul r1, r0.y, c9 mad r1, c8, r0.x, r1 mad r0, c10, r0.z, r1 add r0, r0, c11 mul o0.z, r0.w, r0.z mov o0.xyw, r0 mad o1.xyw, v0.xyzx, c0.yzzw, c0.wyzw mov o1.z, r0.z[/code] Would be great if the shadows could be fixed. Otherwise I would have to disable them and find some work arounds that mask the absence of shadows (freeze game clock and play at night time, replace blue with grey sky or fog, etc.)...
Hi! Still alive ;) And sorry for beeing quiet the last months as I didn't have much time for gaming and spent the time I had with MMORPGs instead of trying new games. But it is great to see how many high quality game fixes have been made meanwhile and I'm looking forward to play the fixed games :)

I wanted to return to shader hacking with "Final Fantasy Lightning Returns" (= FF XIII-3) and so complete my fixes for the FF XIII trilogy. FF XIII-1 and -II offered a good S3D experience out of the box and only needed some minor fixes and tweaks. In contrary to this FF-LR is unplayable in S3D as it uses a new lighting system because of the introduced day and night cycle. So all shadows are "dynamic shadows" and are rendered in 2D at screen depth :( In addition to this only a very old version of Helix's debug dll works (https://s3.amazonaws.com/-HeliX-/DLLS/Debug.zip). The newer ones have no effect on the game or cause a crash.
I could hunt the shaders for the shadows. I know that it is very difficult to fix shadows especially when a game uses its own engine and not a common one like Unreal,Unity, etc.. But maybe some of our experienced hackers could have a short look at the code if they recognize a pattern that allows to fix the shadows?
This seems to be the PS for the shadows:
// Parameters:
//
// sampler2D $s_cameraDepthSampler;
// sampler2D $s_directionSampler;
// float2 $s_screenReciprocal;
// sampler2D $s_shadowDepthSampler;
// float2 $s_shadowOffset0;
// float2 $s_shadowOffset1;
// float2 $s_shadowOffset2;
// float2 $s_shadowOffset3;
// float2 $s_shadowOffset4;
// float2 $s_shadowOffset5;
// float2 $s_shadowOffset6;
// float2 $s_shadowOffset7;
// float4 $s_shadowRatio0;
// float4 $s_shadowRatio1;
// float4 $s_viewBound;
// float4 $s_viewShadowMatrixFarColumn0;
// float4 $s_viewShadowMatrixFarColumn1;
// float4 $s_viewShadowMatrixFarColumn2;
// float4 $s_viewShadowMatrixFarColumn3;
// float4 $s_viewShadowMatrixNearColumn0;
// float4 $s_viewShadowMatrixNearColumn1;
// float4 $s_viewShadowMatrixNearColumn2;
// float4 $s_viewShadowMatrixNearColumn3;
//
//
// Registers:
//
// Name Reg Size
// ------------------------------ ----- ----
// $s_viewBound c0 1
// $s_screenReciprocal c1 1
// $s_viewShadowMatrixNearColumn0 c2 1
// $s_viewShadowMatrixNearColumn1 c3 1
// $s_viewShadowMatrixNearColumn2 c4 1
// $s_viewShadowMatrixNearColumn3 c5 1
// $s_viewShadowMatrixFarColumn0 c6 1
// $s_viewShadowMatrixFarColumn1 c7 1
// $s_viewShadowMatrixFarColumn2 c8 1
// $s_viewShadowMatrixFarColumn3 c9 1
// $s_shadowRatio0 c10 1
// $s_shadowOffset0 c11 1
// $s_shadowOffset1 c12 1
// $s_shadowOffset2 c13 1
// $s_shadowOffset3 c14 1
// $s_shadowRatio1 c15 1
// $s_shadowOffset4 c16 1
// $s_shadowOffset5 c17 1
// $s_shadowOffset6 c18 1
// $s_shadowOffset7 c19 1
// $s_cameraDepthSampler s0 1
// $s_shadowDepthSampler s1 1
// $s_directionSampler s2 1
//

ps_3_0
def c20, 0.5, 0.015625, 2, -1
def c21, 0, 0, 0, 0
dcl_texcoord v0.xyz
dcl vPos.xy
dcl_2d s0
dcl_2d s1
dcl_2d s2
frc r0.xy, vPos
add r0.xy, -r0, vPos
add r0.xy, r0, c20.x
mul r0.zw, r0.xyxy, c1.xyxy
mul r0.xy, r0, c20.y
texld r1, r0, s2
mad r0.xy, r1.zyzw, c20.z, c20.w
texld r1, r0.zwzw, s0
mul r2.xyz, r1.x, v0
mad r0.zw, v0.z, -r1.x, -c0.xyyw
mov r1, c9
cmp r1, r0.z, r1, c5
mov r2.w, -c20.w
dp4 r1.x, r1, r2
rcp r1.x, r1.x
mov r3, c6
cmp r3, r0.z, r3, c2
dp4 r3.x, r3, r2
mov r4, c7
cmp r4, r0.z, r4, c3
dp4 r3.y, r4, r2
mul r1.xy, r1.x, r3
mad r1.zw, c11.xyxy, r0.xyyx, r1.xyxy
texld r3, r1.zwzw, s1
mov r4, c8
cmp r4, r0.z, r4, c4
dp4 r0.z, r4, r2
add r1.z, -r3.x, r0.z
mov r2.x, c21.x
mad r2.yz, c12.xxyw, r0.xxyw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.zw, r1, r2.x, c10.xyxy
add_pp r1.z, r1.w, r1.z
mad r2.yz, c13.xxyw, r0.xyxw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.w, r1.w, r2.x, c10.z
add_pp r1.z, r1.w, r1.z
mad r2.yz, c14.xxyw, r0.xxyw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.w, r1.w, r2.x, c10.w
add_pp r1.z, r1.w, r1.z
mad r2.yz, c16.xxyw, r0.xyxw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.w, r1.w, r2.x, c15.x
add_pp r1.z, r1.w, r1.z
mad r2.yz, c17.xxyw, r0.xxyw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.w, r1.w, r2.x, c15.y
add_pp r1.z, r1.w, r1.z
mad r2.yz, c18.xxyw, r0.xyxw, r1.xxyw
mad r0.xy, c19, r0, r1
texld r3, r0, s1
add r0.x, r0.z, -r3.x
texld r3, r2.yzzw, s1
add r0.y, r0.z, -r3.x
cmp_pp r0.xy, r0, r2.x, c15.wzzw
add_pp r0.y, r0.y, r1.z
add_pp r0.x, r0.x, r0.y
cmp_pp oC0.w, r0.w, -c20.w, r0.x
mov_pp oC0.xyz, -c20.w
mov r14.x, c222.z

There are several VS for the shadows but they all have a similar pattern like this example:
// Parameters:
//
// bool $isSkining;
// float4 ModelBBoxOffSet;
// float4 ModelBBoxScale;
// float4 jointMatrices[144];
// float4x4 localProjectionMatrix;
//
//
// Registers:
//
// Name Reg Size
// --------------------- ----- ----
// $isSkining b0 1
// localProjectionMatrix c8 4
// jointMatrices c21 144
// ModelBBoxScale c169 1
// ModelBBoxOffSet c170 1
//

vs_3_0
def c0, 3, 1, -1, 0
dcl_texcoord v0
dcl_texcoord6 v1
dcl_texcoord7 v2
dcl_position v3
dcl_position o0
dcl_texcoord o1
mov r0.xyz, c169
mad r0.xyz, v3, r0, c170
if b0
frc r1, v2
add r2, -r1, v2
slt r3, v2, -v2
slt r1, -r1, r1
mad r1, r3, r1, r2
mul r1, r1, c0.x
mova a0.xy, r1
mul r2, v1.y, c21[a0.y]
mul r3, v1.y, c22[a0.y]
mul r4, v1.y, c23[a0.y]
mad r2, c21[a0.x], v1.x, r2
mad r3, c22[a0.x], v1.x, r3
mad r4, c23[a0.x], v1.x, r4
mova a0.x, r1.z
mad r2, c21[a0.x], v1.z, r2
mad r3, c22[a0.x], v1.z, r3
mad r4, c23[a0.x], v1.z, r4
mova a0.x, r1.w
mad r1, c21[a0.x], v1.w, r2
mad r2, c22[a0.x], v1.w, r3
mad r3, c23[a0.x], v1.w, r4
mov r0.w, c0.y
dp4 r1.x, r1, r0
dp4 r1.y, r2, r0
dp4 r0.z, r3, r0
mov r0.xy, r1
endif
mul r1, r0.y, c9
mad r1, c8, r0.x, r1
mad r0, c10, r0.z, r1
add r0, r0, c11
mul o0.z, r0.w, r0.z
mov o0.xyw, r0
mad o1.xyw, v0.xyzx, c0.yzzw, c0.wyzw
mov o1.z, r0.z

Would be great if the shadows could be fixed. Otherwise I would have to disable them and find some work arounds that mask the absence of shadows (freeze game clock and play at night time, replace blue with grey sky or fog, etc.)...

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

Posted 12/17/2015 06:42 PM   
[quote="3d4dd"]Hi! Still alive ;)[/quote]Welcome back :) Let's take a look... [code] // $s_cameraDepthSampler s0 1 [/code] The depth buffer is usually important - let's see where it is used: [code] texld r1, r0.zwzw, s0 mul r2.xyz, r1.x, v0 [/code] This is important - here the shader is creating a three dimensional coordinate by multiplying a vector by the depth of this pixel. This is usually where you would need to insert some kind of adjustment, but I can't tell from the code alone what kind of adjustment you will need. If we can determine what coordinate system v0 is in that would answer this question, but we would need to study the vertex shader to even be able to guess (and even then it might not hold the answer). The vertex shader you posted does not look right for a shadow - it has "joints", which means it is likely the shader for one of the characters that cast the shadow, but you actually want to find the shader that removes the light. Alternatively you can use Helix Mod's "PixelPair" to find the corresponding vertex shader for a given pixel shader (there's a guide on this on bo3b's wiki in the Helix Mod feature list). You can also experiment with r2.xyz to see what happens. In particular, if you adjust r2.x, does the shadow move horizontally with respect to the camera, or does it move in a fixed direction with respect to the world (as in, does it move north-east or something like that?) If adjusting r2.x makes the shadows always move horizontally with respect to the camera, you are likely in view-space coordiantes. In that case you would want to do something equivalent to r2.x -= separation * (r2.z - convergence) * fov; Note that we are subtracting and we are using r2.z for depth, not r2.w. "fov" is from the inverse projection matrix and is related to the horizontal FOV (1 / tan(radians(fov_horiz) / 2)) - if the FOV cannot change you can use trial and error to find a suitable value (e.g. between 0.5 and 1.5), but if it can you would need to find a way to get access to the projection or inverse projection matrix (or derive them from other matrices like we do in Unity). If it doesn't move horizontally with respect to the camera, it is likely in world-space coordinates. In this case you will need to find some matrices you can use to convert between projection-space and world-space (and usually the reverse as well by inverting them, though I have tricks to avoid that if necessary). This shader does not have any of the required matrices, so you will likely need to copy them from elsewhere. Start by finding the matching vertex shader as it might already have them, otherwise you would need to copy them from another shader with Helix Mod. If you can copy the inverse view-projection matrix in to the shader that would be ideal, but there are plenty of options depending on what matrices you can find (view matrix * projection matrix == view-projection matrix. inverse model-view-projection matrix * model matrix == inverse view-projection matrix, etc), so long as the matrices were used to draw something in the 3D world from the perspective of the camera, and if you use multiple matrices they should generally all come from the same source shader. In some cases (Unity), the light also interacts with the surfaces it lands on, so it's also worth checking the vertex shaders for the ground for any halo type issues that affect the shadow placement.
3d4dd said:Hi! Still alive ;)
Welcome back :)

Let's take a look...

//   $s_cameraDepthSampler          s0       1

The depth buffer is usually important - let's see where it is used:

texld r1, r0.zwzw, s0
mul r2.xyz, r1.x, v0

This is important - here the shader is creating a three dimensional coordinate by multiplying a vector by the depth of this pixel. This is usually where you would need to insert some kind of adjustment, but I can't tell from the code alone what kind of adjustment you will need.

If we can determine what coordinate system v0 is in that would answer this question, but we would need to study the vertex shader to even be able to guess (and even then it might not hold the answer). The vertex shader you posted does not look right for a shadow - it has "joints", which means it is likely the shader for one of the characters that cast the shadow, but you actually want to find the shader that removes the light. Alternatively you can use Helix Mod's "PixelPair" to find the corresponding vertex shader for a given pixel shader (there's a guide on this on bo3b's wiki in the Helix Mod feature list).

You can also experiment with r2.xyz to see what happens. In particular, if you adjust r2.x, does the shadow move horizontally with respect to the camera, or does it move in a fixed direction with respect to the world (as in, does it move north-east or something like that?)

If adjusting r2.x makes the shadows always move horizontally with respect to the camera, you are likely in view-space coordiantes. In that case you would want to do something equivalent to r2.x -= separation * (r2.z - convergence) * fov; Note that we are subtracting and we are using r2.z for depth, not r2.w. "fov" is from the inverse projection matrix and is related to the horizontal FOV (1 / tan(radians(fov_horiz) / 2)) - if the FOV cannot change you can use trial and error to find a suitable value (e.g. between 0.5 and 1.5), but if it can you would need to find a way to get access to the projection or inverse projection matrix (or derive them from other matrices like we do in Unity).

If it doesn't move horizontally with respect to the camera, it is likely in world-space coordinates. In this case you will need to find some matrices you can use to convert between projection-space and world-space (and usually the reverse as well by inverting them, though I have tricks to avoid that if necessary).

This shader does not have any of the required matrices, so you will likely need to copy them from elsewhere. Start by finding the matching vertex shader as it might already have them, otherwise you would need to copy them from another shader with Helix Mod.

If you can copy the inverse view-projection matrix in to the shader that would be ideal, but there are plenty of options depending on what matrices you can find (view matrix * projection matrix == view-projection matrix. inverse model-view-projection matrix * model matrix == inverse view-projection matrix, etc), so long as the matrices were used to draw something in the 3D world from the perspective of the camera, and if you use multiple matrices they should generally all come from the same source shader.


In some cases (Unity), the light also interacts with the surfaces it lands on, so it's also worth checking the vertex shaders for the ground for any halo type issues that affect the shadow placement.

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/18/2015 04:16 AM   
Thank You very much for Your help :) I did some observations on the shadows: - [s]There is a vertical (!) split of the shadows between the left and the right eye. The split depends on the cardinal direction of the camera and is maximum when looking to east or west and 0 when looking to north or south. See [url]http://photos.3dvisionlive.com/3d4dd/image/5673e017e7e564ff050001ef/[/url] and [url]http://photos.3dvisionlive.com/3d4dd/image/5673e067e7e564df4b0001aa/[/url][/s] Stupid me - the split results from the fact that the objects are not on plain ground but on a slope in N-S direction. On a plain there is no vertical split. But maybe this observation is nevertheless usefull. - Changing the value for r2.x (add r2.x, r2.x, [different values]) moves shadows horizontally with respect to the camera. The cardinal direction doesn't matter. So it should be view-space coordiantes. - I tried to find the correct VS but it is difficult because the newest working debug.dll version is 120401. So UseRenderedShaders, bCalcTexCRCatStart, etc. don't work :( Also VertexPair allways shows "0". But I could find 2 VS that disable all the dynamic shadows and not only a certain type of shadows like the one I have posted before. Unfortunately they also disable other effects like fog, etc. So maybe they are too common, now? VS 51505A22 [code]// Parameters: // // float2 $s_surfaceSize; // // // Registers: // // Name Reg Size // -------------- ----- ---- // $s_surfaceSize c0 1 // vs_3_0 def c1, 0, 1, 0, 0 def c2, 0.5, -0.5, -1, 1 dcl_position v0 dcl_position o0 dcl_texcoord o1.xy mad o1.xy, v0, c2, c2.x rcp r0.x, c0.x rcp r0.y, c0.y mad o0.xy, r0, c2.zwzw, v0 mov o0.zw, c1.xyxy[/code] VS 8A77467B [code]// Parameters: // // float4 $s_projectionReciprocal; // float2 $s_surfaceSize; // // // Registers: // // Name Reg Size // ----------------------- ----- ---- // $s_surfaceSize c0 1 // $s_projectionReciprocal c1 1 // vs_3_0 def c2, 1, 0, -1, 0 dcl_position v0 dcl_position o0 dcl_texcoord o1.xyz mad r0.xyz, v0.xyxw, c2.xxyw, c2.yyxw mul o1.xyz, r0, c1 rcp r0.x, c0.x rcp r0.y, c0.y mad o0.xy, r0, c2.zxzw, v0 mov o0.zw, c2.xyyx[/code] - DAT-13 reported that the "Render shadows in mono" option of the iZ3D driver fixed the shadow issues. Unfortunately it didn't work for me...
Thank You very much for Your help :)
I did some observations on the shadows:
- There is a vertical (!) split of the shadows between the left and the right eye. The split depends on the cardinal direction of the camera and is maximum when looking to east or west and 0 when looking to north or south. See http://photos.3dvisionlive.com/3d4dd/image/5673e017e7e564ff050001ef/ and http://photos.3dvisionlive.com/3d4dd/image/5673e067e7e564df4b0001aa/
Stupid me - the split results from the fact that the objects are not on plain ground but on a slope in N-S direction. On a plain there is no vertical split. But maybe this observation is nevertheless usefull.
- Changing the value for r2.x (add r2.x, r2.x, [different values]) moves shadows horizontally with respect to the camera. The cardinal direction doesn't matter. So it should be view-space coordiantes.
- I tried to find the correct VS but it is difficult because the newest working debug.dll version is 120401. So UseRenderedShaders, bCalcTexCRCatStart, etc. don't work :( Also VertexPair allways shows "0". But I could find 2 VS that disable all the dynamic shadows and not only a certain type of shadows like the one I have posted before. Unfortunately they also disable other effects like fog, etc. So maybe they are too common, now?
VS 51505A22
// Parameters:
//
// float2 $s_surfaceSize;
//
//
// Registers:
//
// Name Reg Size
// -------------- ----- ----
// $s_surfaceSize c0 1
//

vs_3_0
def c1, 0, 1, 0, 0
def c2, 0.5, -0.5, -1, 1
dcl_position v0
dcl_position o0
dcl_texcoord o1.xy
mad o1.xy, v0, c2, c2.x
rcp r0.x, c0.x
rcp r0.y, c0.y
mad o0.xy, r0, c2.zwzw, v0
mov o0.zw, c1.xyxy

VS 8A77467B
// Parameters:
//
// float4 $s_projectionReciprocal;
// float2 $s_surfaceSize;
//
//
// Registers:
//
// Name Reg Size
// ----------------------- ----- ----
// $s_surfaceSize c0 1
// $s_projectionReciprocal c1 1
//

vs_3_0
def c2, 1, 0, -1, 0
dcl_position v0
dcl_position o0
dcl_texcoord o1.xyz
mad r0.xyz, v0.xyxw, c2.xxyw, c2.yyxw
mul o1.xyz, r0, c1
rcp r0.x, c0.x
rcp r0.y, c0.y
mad o0.xy, r0, c2.zxzw, v0
mov o0.zw, c2.xyyx

- DAT-13 reported that the "Render shadows in mono" option of the iZ3D driver fixed the shadow issues. Unfortunately it didn't work for me...

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

Posted 12/18/2015 11:05 AM   
Hi Just startet on Bo3b's scool and allready about to fail first lesson :/ I have been following Lesson 1 to the point where I have to save a pixelshader. I have created the DX9Settings.ini and cycled through the pixelshaders with the 1-2 key, found a shader I liked to disable, and pushed the 3 key. And now it Begins to confuse me... According to Bo3b the dumb dirs should be in the Bin dir, but they are in the main dir instead, and nothing is saved in the dumb dirs ?? What have I done wrong ??
Hi
Just startet on Bo3b's scool and allready about to fail first lesson :/

I have been following Lesson 1 to the point where I have to save a pixelshader.

I have created the DX9Settings.ini and cycled through the pixelshaders with the 1-2 key, found a shader I liked to disable, and pushed the 3 key.

And now it Begins to confuse me...
According to Bo3b the dumb dirs should be in the Bin dir, but they are in the main dir instead, and nothing is saved in the dumb dirs ??

What have I done wrong ??

Win7 64bit Pro
CPU: 4790K 4.8 GHZ
GPU: Asus Geforce RTX 2080 TI Rog Strix OC
Monitor: Asus PG278QR
And lots of ram and HD's ;)

Posted 12/19/2015 05:36 PM   
This is a problem with the full version of The Ball. Just copy the Dumps folder to the bin folder and then it will work.
This is a problem with the full version of The Ball. Just copy the Dumps folder to the bin folder and then it will work.

Posted 12/19/2015 06:32 PM   
Thanks tonka - that did it.. though it actually IS the demo version i'm using :) Moving on to lesson 2...
Thanks tonka - that did it.. though it actually IS the demo version i'm using :)

Moving on to lesson 2...

Win7 64bit Pro
CPU: 4790K 4.8 GHZ
GPU: Asus Geforce RTX 2080 TI Rog Strix OC
Monitor: Asus PG278QR
And lots of ram and HD's ;)

Posted 12/19/2015 08:32 PM   
[quote="3d4dd"]- Changing the value for r2.x (add r2.x, r2.x, [different values]) moves shadows horizontally with respect to the camera. The cardinal direction doesn't matter. So it should be view-space coordiantes.[/quote] Ok, the next step is to try hardcoding the value used for FOV and see if you can find some value that lines them up. If the FOV is constant in the game that might be enough, but even if it can vary it will at least confirm if you are on the right track, and if that is the only adjustment needed or if you might need to also adjust them somewhere else as well. [quote]- I tried to find the correct VS but it is difficult because the newest working debug.dll version is 120401. So UseRenderedShaders, bCalcTexCRCatStart, etc. don't work :( Also VertexPair allways shows "0".[/quote]That's annoying. Hopefully that won't be a show stopper - I don't know if that version supports copying matrices around if we determine we need to. I've noticed an option in the dll that isn't used in the latest version, but maybe it did something in the older version - try adding this to the [General] section: [code] ShowShaderPairs = true [/code] [quote]But I could find 2 VS that disable all the dynamic shadows and not only a certain type of shadows like the one I have posted before. Unfortunately they also disable other effects like fog, etc. So maybe they are too common, now? VS 51505A22 [code]<snip> dcl_texcoord o1.xy [/code][/quote] This one won't be right because it only outputs a 2D texcoord, but the pixel shader takes a 3D texcoord input. [quote] VS 8A77467B [code] // $s_surfaceSize c0 1 // $s_projectionReciprocal c1 1 // vs_3_0 def c2, 1, 0, -1, 0 dcl_position v0 dcl_position o0 dcl_texcoord o1.xyz mad r0.xyz, v0.xyxw, c2.xxyw, c2.yyxw mul o1.xyz, r0, c1 rcp r0.x, c0.x rcp r0.y, c0.y mad o0.xy, r0, c2.zxzw, v0 mov o0.zw, c2.xyyx [/code][/quote] This is a possibility, though it's not a pattern I'm familiar with. The texcoord is coming from (v0.x, v0.y, 1) * s_projectionReciprocal. It might be worth doing some experiments in here to see if you can move the shadows by adjusting the texcoord by some amount. It might be that you will have to pass this projectionReciprocal through to the pixel shader and use it there to get the right correction, but I'm not sure.
3d4dd said:- Changing the value for r2.x (add r2.x, r2.x, [different values]) moves shadows horizontally with respect to the camera. The cardinal direction doesn't matter. So it should be view-space coordiantes.

Ok, the next step is to try hardcoding the value used for FOV and see if you can find some value that lines them up. If the FOV is constant in the game that might be enough, but even if it can vary it will at least confirm if you are on the right track, and if that is the only adjustment needed or if you might need to also adjust them somewhere else as well.

- I tried to find the correct VS but it is difficult because the newest working debug.dll version is 120401. So UseRenderedShaders, bCalcTexCRCatStart, etc. don't work :( Also VertexPair allways shows "0".
That's annoying. Hopefully that won't be a show stopper - I don't know if that version supports copying matrices around if we determine we need to.

I've noticed an option in the dll that isn't used in the latest version, but maybe it did something in the older version - try adding this to the [General] section:
ShowShaderPairs = true


But I could find 2 VS that disable all the dynamic shadows and not only a certain type of shadows like the one I have posted before. Unfortunately they also disable other effects like fog, etc. So maybe they are too common, now?
VS 51505A22
<snip>
dcl_texcoord o1.xy

This one won't be right because it only outputs a 2D texcoord, but the pixel shader takes a 3D texcoord input.


VS 8A77467B
//   $s_surfaceSize          c0       1
// $s_projectionReciprocal c1 1
//

vs_3_0
def c2, 1, 0, -1, 0
dcl_position v0
dcl_position o0
dcl_texcoord o1.xyz
mad r0.xyz, v0.xyxw, c2.xxyw, c2.yyxw
mul o1.xyz, r0, c1
rcp r0.x, c0.x
rcp r0.y, c0.y
mad o0.xy, r0, c2.zxzw, v0
mov o0.zw, c2.xyyx

This is a possibility, though it's not a pattern I'm familiar with. The texcoord is coming from (v0.x, v0.y, 1) * s_projectionReciprocal. It might be worth doing some experiments in here to see if you can move the shadows by adjusting the texcoord by some amount. It might be that you will have to pass this projectionReciprocal through to the pixel shader and use it there to get the right correction, but I'm not sure.

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/20/2015 06:02 AM   
Back from holidays, ready for shader hacking and very sorry for my delayed answer! ShowShaderPairs = true didn't work. I still only get "0" for the pair. I also have the impression that the debug.dll doesn't get all the shaders used by the game. For my workaround with disabled shadows I tried to find the shader that is responsible for the ligthing of the far distant scenery. For this area obviously static shadows (with no S3D issues) are used that only get darker depending on daytime. But altough I cycled several times trough the hundreds of PS and VS I couldn't identify a shader that affected this lighting... [quote="DarkStarSword"] VS 8A77467B The texcoord is coming from (v0.x, v0.y, 1) * s_projectionReciprocal. It might be worth doing some experiments in here to see if you can move the shadows by adjusting the texcoord by some amount. [/quote] As an experiment I have used the following code: [code]// mul o1.xyz, r0, c1 mul r2.xyz, r0, c1 add r2.x, r2.x, c200.x mov o1.xyz, r2.xyz[/code] with c200.x = 0.01 The shadows again were moved horizontally with respect to the camera. Does this provide relevant informations? Should I do additional experiments? [quote="DarkStarSword"] Ok, the next step is to try hardcoding the value used for FOV and see if you can find some value that lines them up. [/quote] Do You by chance have an example of a fixed PS that uses this method?
Back from holidays, ready for shader hacking and very sorry for my delayed answer!
ShowShaderPairs = true didn't work. I still only get "0" for the pair.
I also have the impression that the debug.dll doesn't get all the shaders used by the game. For my workaround with disabled shadows I tried to find the shader that is responsible for the ligthing of the far distant scenery. For this area obviously static shadows (with no S3D issues) are used that only get darker depending on daytime. But altough I cycled several times trough the hundreds of PS and VS I couldn't identify a shader that affected this lighting...

DarkStarSword said:
VS 8A77467B
The texcoord is coming from (v0.x, v0.y, 1) * s_projectionReciprocal. It might be worth doing some experiments in here to see if you can move the shadows by adjusting the texcoord by some amount.

As an experiment I have used the following code:
//    mul o1.xyz, r0, c1
mul r2.xyz, r0, c1
add r2.x, r2.x, c200.x
mov o1.xyz, r2.xyz

with c200.x = 0.01
The shadows again were moved horizontally with respect to the camera. Does this provide relevant informations? Should I do additional experiments?

DarkStarSword said:
Ok, the next step is to try hardcoding the value used for FOV and see if you can find some value that lines them up.

Do You by chance have an example of a fixed PS that uses this method?

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

Posted 12/27/2015 01:09 PM   
Just wanted to bump my question above as I'm still on vacation this week and would have some time to try to fix the shadows - but still have no idea how to continue... I would also be happy to gift the game for a shared Steam account if it helps :)
Just wanted to bump my question above as I'm still on vacation this week and would have some time to try to fix the shadows - but still have no idea how to continue... I would also be happy to gift the game for a shared Steam account if it helps :)

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

Posted 01/05/2016 07:08 AM   
Sorry, I meant to reply to this earlier. This might be a long shot, but here's my haunch: VS 8A77467B [code]// Parameters: // // float4 $s_projectionReciprocal; // float2 $s_surfaceSize; // // // Registers: // // Name Reg Size // ----------------------- ----- ---- // $s_surfaceSize c0 1 // $s_projectionReciprocal c1 1 // vs_3_0 def c2, 1, 0, -1, 0 dcl_position v0 dcl_position o0 dcl_texcoord o1.xyz // Add a new output to pass s_projectionReciprocal to the pixel shader: dcl_texcoord1 o2 mov o2, c1 mad r0.xyz, v0.xyxw, c2.xxyw, c2.yyxw mul o1.xyz, r0, c1 rcp r0.x, c0.x rcp r0.y, c0.y mad o0.xy, r0, c2.zxzw, v0 mov o0.zw, c2.xyyx [/code] PS: [code]// Parameters: // // sampler2D $s_cameraDepthSampler; // sampler2D $s_directionSampler; // float2 $s_screenReciprocal; // sampler2D $s_shadowDepthSampler; // float2 $s_shadowOffset0; // float2 $s_shadowOffset1; // float2 $s_shadowOffset2; // float2 $s_shadowOffset3; // float2 $s_shadowOffset4; // float2 $s_shadowOffset5; // float2 $s_shadowOffset6; // float2 $s_shadowOffset7; // float4 $s_shadowRatio0; // float4 $s_shadowRatio1; // float4 $s_viewBound; // float4 $s_viewShadowMatrixFarColumn0; // float4 $s_viewShadowMatrixFarColumn1; // float4 $s_viewShadowMatrixFarColumn2; // float4 $s_viewShadowMatrixFarColumn3; // float4 $s_viewShadowMatrixNearColumn0; // float4 $s_viewShadowMatrixNearColumn1; // float4 $s_viewShadowMatrixNearColumn2; // float4 $s_viewShadowMatrixNearColumn3; // // // Registers: // // Name Reg Size // ------------------------------ ----- ---- // $s_viewBound c0 1 // $s_screenReciprocal c1 1 // $s_viewShadowMatrixNearColumn0 c2 1 // $s_viewShadowMatrixNearColumn1 c3 1 // $s_viewShadowMatrixNearColumn2 c4 1 // $s_viewShadowMatrixNearColumn3 c5 1 // $s_viewShadowMatrixFarColumn0 c6 1 // $s_viewShadowMatrixFarColumn1 c7 1 // $s_viewShadowMatrixFarColumn2 c8 1 // $s_viewShadowMatrixFarColumn3 c9 1 // $s_shadowRatio0 c10 1 // $s_shadowOffset0 c11 1 // $s_shadowOffset1 c12 1 // $s_shadowOffset2 c13 1 // $s_shadowOffset3 c14 1 // $s_shadowRatio1 c15 1 // $s_shadowOffset4 c16 1 // $s_shadowOffset5 c17 1 // $s_shadowOffset6 c18 1 // $s_shadowOffset7 c19 1 // $s_cameraDepthSampler s0 1 // $s_shadowDepthSampler s1 1 // $s_directionSampler s2 1 // ps_3_0 def c20, 0.5, 0.015625, 2, -1 def c21, 0, 0, 0, 0 dcl_texcoord v0.xyz dcl vPos.xy dcl_2d s0 dcl_2d s1 dcl_2d s2 // New input with s_projectionReciprocal from the vertex shader: dcl_texcoord1 v2 // Helix Mod Stereo Params: dcl_2d s13 def c220, 0, 1, 0.0625, 0.5 frc r0.xy, vPos add r0.xy, -r0, vPos add r0.xy, r0, c20.x mul r0.zw, r0.xyxy, c1.xyxy mul r0.xy, r0, c20.y texld r1, r0, s2 mad r0.xy, r1.zyzw, c20.z, c20.w texld r1, r0.zwzw, s0 mul r2.xyz, r1.x, v0 // Subtract a view-space stereo correction from r2: texldl r31, c220.z, s13 add r31.w, r2.z, -r31.y mul r31.w, r31.w, r31.x mad r2.x, -r31.w, v2.x, r2.x mad r0.zw, v0.z, -r1.x, -c0.xyyw mov r1, c9 cmp r1, r0.z, r1, c5 mov r2.w, -c20.w dp4 r1.x, r1, r2 rcp r1.x, r1.x mov r3, c6 cmp r3, r0.z, r3, c2 dp4 r3.x, r3, r2 mov r4, c7 cmp r4, r0.z, r4, c3 dp4 r3.y, r4, r2 mul r1.xy, r1.x, r3 mad r1.zw, c11.xyxy, r0.xyyx, r1.xyxy texld r3, r1.zwzw, s1 mov r4, c8 cmp r4, r0.z, r4, c4 dp4 r0.z, r4, r2 add r1.z, -r3.x, r0.z mov r2.x, c21.x mad r2.yz, c12.xxyw, r0.xxyw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.zw, r1, r2.x, c10.xyxy add_pp r1.z, r1.w, r1.z mad r2.yz, c13.xxyw, r0.xyxw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.w, r1.w, r2.x, c10.z add_pp r1.z, r1.w, r1.z mad r2.yz, c14.xxyw, r0.xxyw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.w, r1.w, r2.x, c10.w add_pp r1.z, r1.w, r1.z mad r2.yz, c16.xxyw, r0.xyxw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.w, r1.w, r2.x, c15.x add_pp r1.z, r1.w, r1.z mad r2.yz, c17.xxyw, r0.xxyw, r1.xxyw texld r3, r2.yzzw, s1 add r1.w, r0.z, -r3.x cmp_pp r1.w, r1.w, r2.x, c15.y add_pp r1.z, r1.w, r1.z mad r2.yz, c18.xxyw, r0.xyxw, r1.xxyw mad r0.xy, c19, r0, r1 texld r3, r0, s1 add r0.x, r0.z, -r3.x texld r3, r2.yzzw, s1 add r0.y, r0.z, -r3.x cmp_pp r0.xy, r0, r2.x, c15.wzzw add_pp r0.y, r0.y, r1.z add_pp r0.x, r0.x, r0.y cmp_pp oC0.w, r0.w, -c20.w, r0.x mov_pp oC0.xyz, -c20.w mov r14.x, c222.z[/code] I'm basing that on a guess that s_projectionReciprocal has the non-zero values of the inverse projection matrix, and that the x component would be the part related to the horizontal FOV. If that doesn't work, try replacing the use of v2.x with a constant register and use trial and error to see how close you can get the shadows. [quote="3d4dd"]Just wanted to bump my question above as I'm still on vacation this week and would have some time to try to fix the shadows - but still have no idea how to continue... I would also be happy to gift the game for a shared Steam account if it helps :)[/quote]See if the above experiment pans out first. If you want to add it to a shared account feel free - then I could take a closer look at it. We also now have a bit of a budget for shared games it seems, which we could quite easily put towards this game so you don't have to spend your money on it - either way contact pirateguygrush to arrange this (and I think you are deserving of access yourself)
Sorry, I meant to reply to this earlier. This might be a long shot, but here's my haunch:

VS 8A77467B
// Parameters:
//
// float4 $s_projectionReciprocal;
// float2 $s_surfaceSize;
//
//
// Registers:
//
// Name Reg Size
// ----------------------- ----- ----
// $s_surfaceSize c0 1
// $s_projectionReciprocal c1 1
//

vs_3_0
def c2, 1, 0, -1, 0
dcl_position v0
dcl_position o0
dcl_texcoord o1.xyz

// Add a new output to pass s_projectionReciprocal to the pixel shader:
dcl_texcoord1 o2

mov o2, c1

mad r0.xyz, v0.xyxw, c2.xxyw, c2.yyxw
mul o1.xyz, r0, c1
rcp r0.x, c0.x
rcp r0.y, c0.y
mad o0.xy, r0, c2.zxzw, v0
mov o0.zw, c2.xyyx


PS:
// Parameters:
//
// sampler2D $s_cameraDepthSampler;
// sampler2D $s_directionSampler;
// float2 $s_screenReciprocal;
// sampler2D $s_shadowDepthSampler;
// float2 $s_shadowOffset0;
// float2 $s_shadowOffset1;
// float2 $s_shadowOffset2;
// float2 $s_shadowOffset3;
// float2 $s_shadowOffset4;
// float2 $s_shadowOffset5;
// float2 $s_shadowOffset6;
// float2 $s_shadowOffset7;
// float4 $s_shadowRatio0;
// float4 $s_shadowRatio1;
// float4 $s_viewBound;
// float4 $s_viewShadowMatrixFarColumn0;
// float4 $s_viewShadowMatrixFarColumn1;
// float4 $s_viewShadowMatrixFarColumn2;
// float4 $s_viewShadowMatrixFarColumn3;
// float4 $s_viewShadowMatrixNearColumn0;
// float4 $s_viewShadowMatrixNearColumn1;
// float4 $s_viewShadowMatrixNearColumn2;
// float4 $s_viewShadowMatrixNearColumn3;
//
//
// Registers:
//
// Name Reg Size
// ------------------------------ ----- ----
// $s_viewBound c0 1
// $s_screenReciprocal c1 1
// $s_viewShadowMatrixNearColumn0 c2 1
// $s_viewShadowMatrixNearColumn1 c3 1
// $s_viewShadowMatrixNearColumn2 c4 1
// $s_viewShadowMatrixNearColumn3 c5 1
// $s_viewShadowMatrixFarColumn0 c6 1
// $s_viewShadowMatrixFarColumn1 c7 1
// $s_viewShadowMatrixFarColumn2 c8 1
// $s_viewShadowMatrixFarColumn3 c9 1
// $s_shadowRatio0 c10 1
// $s_shadowOffset0 c11 1
// $s_shadowOffset1 c12 1
// $s_shadowOffset2 c13 1
// $s_shadowOffset3 c14 1
// $s_shadowRatio1 c15 1
// $s_shadowOffset4 c16 1
// $s_shadowOffset5 c17 1
// $s_shadowOffset6 c18 1
// $s_shadowOffset7 c19 1
// $s_cameraDepthSampler s0 1
// $s_shadowDepthSampler s1 1
// $s_directionSampler s2 1
//

ps_3_0
def c20, 0.5, 0.015625, 2, -1
def c21, 0, 0, 0, 0
dcl_texcoord v0.xyz
dcl vPos.xy
dcl_2d s0
dcl_2d s1
dcl_2d s2

// New input with s_projectionReciprocal from the vertex shader:
dcl_texcoord1 v2

// Helix Mod Stereo Params:
dcl_2d s13
def c220, 0, 1, 0.0625, 0.5

frc r0.xy, vPos
add r0.xy, -r0, vPos
add r0.xy, r0, c20.x
mul r0.zw, r0.xyxy, c1.xyxy
mul r0.xy, r0, c20.y
texld r1, r0, s2
mad r0.xy, r1.zyzw, c20.z, c20.w
texld r1, r0.zwzw, s0
mul r2.xyz, r1.x, v0

// Subtract a view-space stereo correction from r2:
texldl r31, c220.z, s13
add r31.w, r2.z, -r31.y
mul r31.w, r31.w, r31.x
mad r2.x, -r31.w, v2.x, r2.x

mad r0.zw, v0.z, -r1.x, -c0.xyyw
mov r1, c9
cmp r1, r0.z, r1, c5
mov r2.w, -c20.w
dp4 r1.x, r1, r2
rcp r1.x, r1.x
mov r3, c6
cmp r3, r0.z, r3, c2
dp4 r3.x, r3, r2
mov r4, c7
cmp r4, r0.z, r4, c3
dp4 r3.y, r4, r2
mul r1.xy, r1.x, r3
mad r1.zw, c11.xyxy, r0.xyyx, r1.xyxy
texld r3, r1.zwzw, s1
mov r4, c8
cmp r4, r0.z, r4, c4
dp4 r0.z, r4, r2
add r1.z, -r3.x, r0.z
mov r2.x, c21.x
mad r2.yz, c12.xxyw, r0.xxyw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.zw, r1, r2.x, c10.xyxy
add_pp r1.z, r1.w, r1.z
mad r2.yz, c13.xxyw, r0.xyxw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.w, r1.w, r2.x, c10.z
add_pp r1.z, r1.w, r1.z
mad r2.yz, c14.xxyw, r0.xxyw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.w, r1.w, r2.x, c10.w
add_pp r1.z, r1.w, r1.z
mad r2.yz, c16.xxyw, r0.xyxw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.w, r1.w, r2.x, c15.x
add_pp r1.z, r1.w, r1.z
mad r2.yz, c17.xxyw, r0.xxyw, r1.xxyw
texld r3, r2.yzzw, s1
add r1.w, r0.z, -r3.x
cmp_pp r1.w, r1.w, r2.x, c15.y
add_pp r1.z, r1.w, r1.z
mad r2.yz, c18.xxyw, r0.xyxw, r1.xxyw
mad r0.xy, c19, r0, r1
texld r3, r0, s1
add r0.x, r0.z, -r3.x
texld r3, r2.yzzw, s1
add r0.y, r0.z, -r3.x
cmp_pp r0.xy, r0, r2.x, c15.wzzw
add_pp r0.y, r0.y, r1.z
add_pp r0.x, r0.x, r0.y
cmp_pp oC0.w, r0.w, -c20.w, r0.x
mov_pp oC0.xyz, -c20.w
mov r14.x, c222.z


I'm basing that on a guess that s_projectionReciprocal has the non-zero values of the inverse projection matrix, and that the x component would be the part related to the horizontal FOV.

If that doesn't work, try replacing the use of v2.x with a constant register and use trial and error to see how close you can get the shadows.

3d4dd said:Just wanted to bump my question above as I'm still on vacation this week and would have some time to try to fix the shadows - but still have no idea how to continue... I would also be happy to gift the game for a shared Steam account if it helps :)
See if the above experiment pans out first. If you want to add it to a shared account feel free - then I could take a closer look at it. We also now have a bit of a budget for shared games it seems, which we could quite easily put towards this game so you don't have to spend your money on it - either way contact pirateguygrush to arrange this (and I think you are deserving of access yourself)

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 01/05/2016 10:39 AM   
  47 / 88    
Scroll To Top