Congratulations! That absolutely makes sense, and it sounds like you are on the right track :)
Now you might want to experiment around that same area and see it is possible to completely fix it there. You often don't want to adjust the output position register itself since the driver already does that, but you do want to adjust anything else that uses the same value.
When you say slightly off - is there anything you notice there that might provide a hint? Commonly if you notice something moves twice as much as you need, or only half as much that can suggest that a multiplier might be necessary. It's also worth checking how the adjustment behaves if you change the convergence as sometimes that can provide more insight.
Congratulations! That absolutely makes sense, and it sounds like you are on the right track :)
Now you might want to experiment around that same area and see it is possible to completely fix it there. You often don't want to adjust the output position register itself since the driver already does that, but you do want to adjust anything else that uses the same value.
When you say slightly off - is there anything you notice there that might provide a hint? Commonly if you notice something moves twice as much as you need, or only half as much that can suggest that a multiplier might be necessary. It's also worth checking how the adjustment behaves if you change the convergence as sometimes that can provide more insight.
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
[quote="eroc_remag"]After a long break I started working on the shader from scratch & it worked. Yipee!!. Actually watching your lesson#6 helped Bo3b. Now I understand why that code is put there & what it does. I had put off watching it for too long, but now I have a good understanding of how the stereo projection works. You have done an excellent job of explaining the whole thing in simple words!
I do have a question though. In the tutorial you say that setting the following line is important for the fix to get activated:
[code]abs r0.w, c200.y[/code]
Can you please explain why that is so?
And can you also explain this line of code please?
[code]if_ne r0.w, -r0.w[/code]
This triggers the stereo specific shader code. Now why/how would this condition be false when stereo is disabled? I couldn't details of this instruction on MSDN's PS or VS instructions page.[/quote]
Awesome, glad to see you making headway!
DarkStarSword mostly explained that code sequence, but I'll just add that the abs followed by the if_ne is code generated by a compiler, and is the normal code seen in Unreal games. They often include stereo fixes already, and that code sequence is how it decides if the global flag set in your Unrealengine.ini file is enabled or not.
We can use the same technique or not. The 'abs' makes sure that even if it's a negative number that it is made positive, although a 'mov' would work for this purpose as well. The if_ne r0, -ro is a clever way to say 'nonzero', as only zero would equal to it's negative.
There's nothing significant about those instructions, and I just reused them because they were already there. In general, I prefer to mildly tweak code that is there, rather than rewrite it, as rewrites tend to introduce bugs. But if I do put in new code, I would never use this sequence because it's not clear enough.
Here is the MSDN page for the if_ne:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb174583(v=vs.85).aspx
eroc_remag said:After a long break I started working on the shader from scratch & it worked. Yipee!!. Actually watching your lesson#6 helped Bo3b. Now I understand why that code is put there & what it does. I had put off watching it for too long, but now I have a good understanding of how the stereo projection works. You have done an excellent job of explaining the whole thing in simple words!
I do have a question though. In the tutorial you say that setting the following line is important for the fix to get activated:
abs r0.w, c200.y
Can you please explain why that is so?
And can you also explain this line of code please?
if_ne r0.w, -r0.w
This triggers the stereo specific shader code. Now why/how would this condition be false when stereo is disabled? I couldn't details of this instruction on MSDN's PS or VS instructions page.
Awesome, glad to see you making headway!
DarkStarSword mostly explained that code sequence, but I'll just add that the abs followed by the if_ne is code generated by a compiler, and is the normal code seen in Unreal games. They often include stereo fixes already, and that code sequence is how it decides if the global flag set in your Unrealengine.ini file is enabled or not.
We can use the same technique or not. The 'abs' makes sure that even if it's a negative number that it is made positive, although a 'mov' would work for this purpose as well. The if_ne r0, -ro is a clever way to say 'nonzero', as only zero would equal to it's negative.
There's nothing significant about those instructions, and I just reused them because they were already there. In general, I prefer to mildly tweak code that is there, rather than rewrite it, as rewrites tend to introduce bugs. But if I do put in new code, I would never use this sequence because it's not clear enough.
[quote="Muizer"]To add to Eroc's questions,
In the verbose canonical shader code it is stated:
// At this point r0 is the output position, correctly
// placed, but without stereo
Now, as I understand it, that applies to the r0 in the lines that follow:
texldl r30, c200.z, s0
add r30.w, r0.w, -r30.y
mul r30.z, r30.x, r30.w
add r0.x, r0.x, r30.z
And it is up to me to
1) move this correct placement into r0 before this text block
2) move the corrected r0.x out again after it.
Main question is though: how do I find the parameter(s) that holds this correct placement? In other words, at what point do I need to break into the code to make this change?
I've been going through the old Rome II fix by Mike, hoping to find some pattern, but I haven't found one yet. [/quote]
In general, I recommend doing the mov into r0 before that sequence rather than modifying the sequence. It's slightly safer to keep that sequence intact, because if you happen to miss a variable, or have a typo, you'll get a silent mystery failure.
So if the code did a
[code]mov o0.xyzw, r4.xyzw[/code]
Then we'd know that r4 was the expected output (for vertex shader). If we thought it wasn't stereo for some reason, we then do the
[code]mov r0, r4
texldl r30, c200.z, s0
add r30.w, r0.w, -r30.y
mul r30.z, r30.x, r30.w
add r0.x, r0.x, r30.z
mov r4, r0
[/code]
No strict rules here, I just like to keep the prime directive intact because it's more clear to me when skimming code.
DarkStarSword nicely addressed the idea for how you decide. It's basically trial and error with deductive reasoning thrown in.
In the verbose canonical shader code it is stated:
// At this point r0 is the output position, correctly
// placed, but without stereo
Now, as I understand it, that applies to the r0 in the lines that follow:
texldl r30, c200.z, s0
add r30.w, r0.w, -r30.y
mul r30.z, r30.x, r30.w
add r0.x, r0.x, r30.z
And it is up to me to
1) move this correct placement into r0 before this text block
2) move the corrected r0.x out again after it.
Main question is though: how do I find the parameter(s) that holds this correct placement? In other words, at what point do I need to break into the code to make this change?
I've been going through the old Rome II fix by Mike, hoping to find some pattern, but I haven't found one yet.
In general, I recommend doing the mov into r0 before that sequence rather than modifying the sequence. It's slightly safer to keep that sequence intact, because if you happen to miss a variable, or have a typo, you'll get a silent mystery failure.
So if the code did a
mov o0.xyzw, r4.xyzw
Then we'd know that r4 was the expected output (for vertex shader). If we thought it wasn't stereo for some reason, we then do the
tnx for the feedback!
[quote="DarkStarSword"]It's also worth checking how the adjustment behaves if you change the convergence as sometimes that can provide more insight.[/quote]
While I change convergence, the two blue ribbons either move apart or closer together, but only for a short while, before seemingly snapping back to their old position. As soon as I stop changing convergence, they also snap back.
Does that provide any insight?
DarkStarSword said:It's also worth checking how the adjustment behaves if you change the convergence as sometimes that can provide more insight.
While I change convergence, the two blue ribbons either move apart or closer together, but only for a short while, before seemingly snapping back to their old position. As soon as I stop changing convergence, they also snap back.
That's normal for anything fixed with Helix mod - the separation & convergence values passed to the fixed shaders only get updated every half second or so, and the result is that snapping you see while adjusting them.
What you learned from that is that since they stayed at their old position the adjustment is not dependent on convergence.
That's normal for anything fixed with Helix mod - the separation & convergence values passed to the fixed shaders only get updated every half second or so, and the result is that snapping you see while adjusting them.
What you learned from that is that since they stayed at their old position the adjustment is not dependent on convergence.
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
Thanks B03b & DSS. That was very useful info.
So I decided to try & fix Besiege as a test. There's a weird ghosting around trees on the first map on Ipsilon. I've dumped what I think is the right shader. I've declared a local constant c200 & use it to set the output color register oC0 to 0000. Here's the code:
[code]
//ghosting on trees on map1 on Ipsilon
ps_2_0
def c200, 0, 1, 0.0625, 0
dcl_2d s0
dcl_2d s1
dcl t0.xy
dcl t1
dcl t2.xyz
texldp r0, t1, s1
texld r1, t0, s0
mul r1, r1, c0
log_pp r0.x, r0.x
log_pp r0.z, r0.z
log_pp r0.y, r0.y
add_pp r0.xyz, -r0, t2
mul_pp r0.xyz, r1, r0
mov_pp r0.w, r1
mov_pp oC0, r0
//disable shader
mov oC0, c200.wwww
[/code]
I tried both mov & move_pp instructions.
Now when I go back into the game & hit F10 nothing happens. I checked that the folders are named correctly, the file is placed in "Besiege\ShaderOverride\PixelShaders" & the file has hex name with 8 chars. Just to be safe I stripped down my DX9settings.ini file to just these lines:
[code]
[General]
// UseRenderedShaders=true is nearly always useful, because it trims the
// list of shaders seen while hunting down to just those active in the
// current scene. Disable this only if you get crashes during hunting.
UseRenderedShaders=true
// DumpAll will generate ASM text files for every shader seen by the game.
// This is usually worth doing once, but not useful for every run.
DumpAll=false
[/code]
But still the fix refuses to work.
I've spent a good bit of 2 hrs trying to figure this out. I've hit a wall. Any suggestions on what to do in such situations?
Another thing that I noticed is that there are instructions like these in many shaders:
mov_pp
mul_pp & so on
How are these instructions different from the regular instructions? I searched MSDN for these but the search didn't turn up anything.
So I decided to try & fix Besiege as a test. There's a weird ghosting around trees on the first map on Ipsilon. I've dumped what I think is the right shader. I've declared a local constant c200 & use it to set the output color register oC0 to 0000. Here's the code:
Now when I go back into the game & hit F10 nothing happens. I checked that the folders are named correctly, the file is placed in "Besiege\ShaderOverride\PixelShaders" & the file has hex name with 8 chars. Just to be safe I stripped down my DX9settings.ini file to just these lines:
[General]
// UseRenderedShaders=true is nearly always useful, because it trims the
// list of shaders seen while hunting down to just those active in the
// current scene. Disable this only if you get crashes during hunting.
UseRenderedShaders=true
// DumpAll will generate ASM text files for every shader seen by the game.
// This is usually worth doing once, but not useful for every run.
DumpAll=false
But still the fix refuses to work.
I've spent a good bit of 2 hrs trying to figure this out. I've hit a wall. Any suggestions on what to do in such situations?
Another thing that I noticed is that there are instructions like these in many shaders:
mov_pp
mul_pp & so on
How are these instructions different from the regular instructions? I searched MSDN for these but the search didn't turn up anything.
In this case, the most likely problem is that this is a ps_2_0 shader as noted in its header. HelixMod will only operate on ps_3_0 shaders.
You'll want to convert the shader code to ps_3_0 with mana84's tool. [url]http://helixmod.blogspot.com/2013/05/vs11vs20-vs30-converter.html[/url]
Or you can do it by hand as described:
[url]https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/post/3653984/#3653984[/url]
Or you can use DarkStarSwords sweet shadertool.py, which will convert it:
[url]https://github.com/DarkStarSword/3d-fixes/blob/33dbc45e6c8f57f0971f1b499220473ba2ea9f81/shadertool.py[/url]
The mov_pp and other instructions means 'partial precision'. It's not relevant to the problem.
[url]https://msdn.microsoft.com/en-us/library/windows/desktop/bb219850%28v=vs.85%29.aspx[/url]
As a general idea for debugging odd failures like this, you'll want to check the LOG.txt first and see if there is an error. I can't remember if ps_2_0 is reported or not.
If that didn't show anything, then you try to deliberately break it by putting in bad code, to make sure it's being loaded and seen. If a bad line didn't make a debug output in the LOG.txt, you know it's not being seen for some reason.
As a general idea for debugging odd failures like this, you'll want to check the LOG.txt first and see if there is an error. I can't remember if ps_2_0 is reported or not.
If that didn't show anything, then you try to deliberately break it by putting in bad code, to make sure it's being loaded and seen. If a bad line didn't make a debug output in the LOG.txt, you know it's not being seen for some reason.
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
Well I've been doing lots of experimenting and getting various effects (though not yet the desired one :( ).
One thing I found that I find strange is that whenever I use s0 or s1 in the vertex shader, I get a result. If I use s2, I don't.
In a pixel shader I noticed samplers being used that weren't declared in the code (though they were mentioned in the header).
In all, now, I'm not so certain anymore texldl is getting its info from the right place?
In the .ini I found entries that allow you to set default samplers, but neither setting seems to have any effect.......
In all I don't think I understand this bit well enough.
Using DarkStarSword's Python script I was able to convert SM2.0 shader to SM3.0. I experimented on the shader a bit. If I set oC0 to 0000, the whole scene becomes dark. I tried 1111 & it definitely makes it better. There is still some artifact on the trees though. Will need to experiment more. But this is a good start I think.
[code]
//ghosting on trees
ps_3_0 // Converted from ps_2_0 with DarkStarSword's shadertool.py
//def c220, Const1, Const2, Const3, Const4 comes in from dx9settings.ini file
def c200, 0, 1, 0.0625, 0
dcl_2d s0
dcl_2d s1
dcl_texcoord v0.xy
dcl_texcoord1 v1
dcl_texcoord2 v2.xyz
texldp r0, v1, s1
texld r1, v0, s0
mul r1, r1, c0
log_pp r0.x, r0.x
log_pp r0.z, r0.z
log_pp r0.y, r0.y
add_pp r0.xyz, -r0, v2
mul_pp r0.xyz, r1, r0
mov_pp r0.w, r1
mov_pp oC0, r0
//disable the effect
mov oC0, c200.yyyy //0 doesn't work. makes the whole scene dark.
[/code]
http://photos.3dvisionlive.com/eroc_remag/image/54ee99e8e7e5648905000016/
http://photos.3dvisionlive.com/eroc_remag/image/54ee9a32e7e5642f7a00007f/
Using DarkStarSword's Python script I was able to convert SM2.0 shader to SM3.0. I experimented on the shader a bit. If I set oC0 to 0000, the whole scene becomes dark. I tried 1111 & it definitely makes it better. There is still some artifact on the trees though. Will need to experiment more. But this is a good start I think.
//ghosting on trees
ps_3_0 // Converted from ps_2_0 with DarkStarSword's shadertool.py
//def c220, Const1, Const2, Const3, Const4 comes in from dx9settings.ini file
def c200, 0, 1, 0.0625, 0
Thanks for the input 4everAwake. Meanwhile I worked some more on the PS. I wanted to add toggle to my temporary fix. I copied the instructions from a known working file, but the if loop is not hit at all. As soon as I go into game & hit F10 my 'fix' is loaded. I tried using r30, r31, r29, but nothing works. The if loop is never hit.
[code]
ps_3_0 // Converted from ps_2_0 with DarkStarSword's shadertool.py
//def c220, Const1, Const2, Const3, Const4 comes in from dx9settings.ini file
def c200, 0, 1, 0.0625, 0
dcl_2d s0
dcl_2d s1
dcl_texcoord v0.xy
dcl_texcoord1 v1
dcl_texcoord2 v2.xyz
texldp r0, v1, s1 //same effect as setting oC0 to 1111
// r30.xyzw, c200.wwww
// texldp r0, r30, s1
texld r1, v0, s0 //makes the whole scene dark. same as setting oC0 to 0
mul r1, r1, c0
log_pp r0.x, r0.x
log_pp r0.z, r0.z
log_pp r0.y, r0.y
add_pp r0.xyz, -r0, v2
mul_pp r0.xyz, r1, r0
mov_pp r0.w, r1
mov_pp oC0, r0
//disable the effect by setting output color register oC0 to 1111.
mov r29.x, c220.x
if_eq r29.x, c200.x
mov oC0.xyzw, c200.yyyy //0 doesn't work. 1 fixes effect but breaks tree trunk
endif
// approximately 10 instruction slots used (2 texture, 8 arithmetic)
[/code]
Thanks for the input 4everAwake. Meanwhile I worked some more on the PS. I wanted to add toggle to my temporary fix. I copied the instructions from a known working file, but the if loop is not hit at all. As soon as I go into game & hit F10 my 'fix' is loaded. I tried using r30, r31, r29, but nothing works. The if loop is never hit.
ps_3_0 // Converted from ps_2_0 with DarkStarSword's shadertool.py
//def c220, Const1, Const2, Const3, Const4 comes in from dx9settings.ini file
def c200, 0, 1, 0.0625, 0
[quote="Muizer"]One thing I found that I find strange is that whenever I use s0 or s1 in the vertex shader, I get a result. If I use s2, I don't.[/quote]These registers can either be passed from the game or from Helix mod, and by default Helix mod uses s0 to pass the stereo settings in for vertex shaders and s13 for pixel shaders. If you need to use a different register, you need to edit the DX9Settings.ini to specify which one you want to use (either globally, or in individual shader sections).
[quote]In a pixel shader I noticed samplers being used that weren't declared in the code (though they were mentioned in the header).[/quote]What version shader was it? Samplers only had to be declared starting with shader model 2, so if it's an earlier version that would make sense. If you need to use one of these in a fix it will need to be updated to shader model 3. My shadertool.py can upgrade vs_1_1, vs_2_0 and ps_2_0 shaders - I can add support for other versions, but I need to find good (non-trivial) shaders to test it against to make sure it works properly.
[quote]In the .ini I found entries that allow you to set default samplers, but neither setting seems to have any effect.......[/quote]I take it you are referring to DefPSSampler and DefVSSampler. There is a bit of a gotcha with DefVSSampler (but not DefPSSampler) that you need to be aware of - you need to add 257 to whichever of the four (s0-s3) sampler numbers you want to use:
[code]
; For s0, use:
DefVSSampler = 257
; For s1, use:
DefVSSampler = 258
; For s2, use:
DefVSSampler = 259
; For s3, use:
DefVSSampler = 260
[/code]
This quirk does not apply to DefPSSampler, which you simply set to a number from 0 to 13 corresponding to the sampler number s0-s13 you want to use.
Muizer said:One thing I found that I find strange is that whenever I use s0 or s1 in the vertex shader, I get a result. If I use s2, I don't.
These registers can either be passed from the game or from Helix mod, and by default Helix mod uses s0 to pass the stereo settings in for vertex shaders and s13 for pixel shaders. If you need to use a different register, you need to edit the DX9Settings.ini to specify which one you want to use (either globally, or in individual shader sections).
In a pixel shader I noticed samplers being used that weren't declared in the code (though they were mentioned in the header).
What version shader was it? Samplers only had to be declared starting with shader model 2, so if it's an earlier version that would make sense. If you need to use one of these in a fix it will need to be updated to shader model 3. My shadertool.py can upgrade vs_1_1, vs_2_0 and ps_2_0 shaders - I can add support for other versions, but I need to find good (non-trivial) shaders to test it against to make sure it works properly.
In the .ini I found entries that allow you to set default samplers, but neither setting seems to have any effect.......
I take it you are referring to DefPSSampler and DefVSSampler. There is a bit of a gotcha with DefVSSampler (but not DefPSSampler) that you need to be aware of - you need to add 257 to whichever of the four (s0-s3) sampler numbers you want to use:
; For s0, use:
DefVSSampler = 257
; For s1, use:
DefVSSampler = 258
; For s2, use:
DefVSSampler = 259
; For s3, use:
DefVSSampler = 260
This quirk does not apply to DefPSSampler, which you simply set to a number from 0 to 13 corresponding to the sampler number s0-s13 you want to use.
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
[quote="eroc_remag"][code]//disable the effect by setting output color register oC0 to 1111.
mov r29.x, c220.x
if_eq r29.x, c200.x
mov oC0.xyzw, c200.yyyy //0 doesn't work. 1 fixes effect but breaks tree trunk
endif
[/code][/quote]
This looks fine to me - can you post your DX9Settings.ini?
Here's my dx9settings.ini file. This too is a copy of a known working version.
[code]
[General]
// UseRenderedShaders=true is nearly always useful, because it trims the
// list of shaders seen while hunting down to just those active in the
// current scene. Disable this only if you get crashes during hunting.
UseRenderedShaders=true
// DumpAll will generate ASM text files for every shader seen by the game.
// This is usually worth doing once, but not useful for every run.
DumpAll=false
// Constant registers that will arrive in Vertex and Pixel Shaders, as
// c220. You can define any constant register as long as it is not used in any other shader in the game. Check for the desired constant register in the Dumps folder to find out if any other shander uses it. The constants below will be assigned, based on the key preset.
DefVSConst1 = 220
DefPSConst1 = 220
//Helix Sampler
DefPSSampler = 14
// The PresetKeysList specifies which KEYs will be used.
// Multiple keys lists are supported.
// Note that the KEY sections are in hexadecimales
PresetsKeysList = 1;
// For this single key example, we only need one keylist, KEY1. This specifies
// that the Numpad 0 keyboard key (Key=96) should act as a toggle. And toggle
// between the two Presets of PRES1, PRES2. Which will change the Const1 being
// passed to the shader code from 1.0 to 0.0 as floating point numbers.
// Type=1 is toggle, Type=2 is momentary. The value 96 is in decimal virtual key code.
[KEY1]
//Numpad 0
Key = 96
Presets = 1;2;
Type = 1
// Constants that will be sent to every shader through constant register c220.
// The Const1 tells us that we'll need to use c220.x to compare against these
// values. Const2 would be seen as c220.y.
// 0x3f800000 is 1.0 in floating point hex, 0x00000000 is 0.0 in hex
// UseByDef specifies which constant is the default starting value.
[PRES1]
Const2 = 0x3f800000
[PRES2]
Const2 = 0x00000000
UseByDef=True
[/code]
Here's my dx9settings.ini file. This too is a copy of a known working version.
[General]
// UseRenderedShaders=true is nearly always useful, because it trims the
// list of shaders seen while hunting down to just those active in the
// current scene. Disable this only if you get crashes during hunting.
UseRenderedShaders=true
// DumpAll will generate ASM text files for every shader seen by the game.
// This is usually worth doing once, but not useful for every run.
DumpAll=false
// Constant registers that will arrive in Vertex and Pixel Shaders, as
// c220. You can define any constant register as long as it is not used in any other shader in the game. Check for the desired constant register in the Dumps folder to find out if any other shander uses it. The constants below will be assigned, based on the key preset.
DefVSConst1 = 220
DefPSConst1 = 220
//Helix Sampler
DefPSSampler = 14
// The PresetKeysList specifies which KEYs will be used.
// Multiple keys lists are supported.
// Note that the KEY sections are in hexadecimales
PresetsKeysList = 1;
// For this single key example, we only need one keylist, KEY1. This specifies
// that the Numpad 0 keyboard key (Key=96) should act as a toggle. And toggle
// between the two Presets of PRES1, PRES2. Which will change the Const1 being
// passed to the shader code from 1.0 to 0.0 as floating point numbers.
// Type=1 is toggle, Type=2 is momentary. The value 96 is in decimal virtual key code.
[KEY1]
//Numpad 0
Key = 96
Presets = 1;2;
Type = 1
// Constants that will be sent to every shader through constant register c220.
// The Const1 tells us that we'll need to use c220.x to compare against these
// values. Const2 would be seen as c220.y.
// 0x3f800000 is 1.0 in floating point hex, 0x00000000 is 0.0 in hex
// UseByDef specifies which constant is the default starting value.
[PRES1]
Const2 = 0x3f800000
[PRES2]
Const2 = 0x00000000
UseByDef=True
Now you might want to experiment around that same area and see it is possible to completely fix it there. You often don't want to adjust the output position register itself since the driver already does that, but you do want to adjust anything else that uses the same value.
When you say slightly off - is there anything you notice there that might provide a hint? Commonly if you notice something moves twice as much as you need, or only half as much that can suggest that a multiplier might be necessary. It's also worth checking how the adjustment behaves if you change the convergence as sometimes that can provide more insight.
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
Awesome, glad to see you making headway!
DarkStarSword mostly explained that code sequence, but I'll just add that the abs followed by the if_ne is code generated by a compiler, and is the normal code seen in Unreal games. They often include stereo fixes already, and that code sequence is how it decides if the global flag set in your Unrealengine.ini file is enabled or not.
We can use the same technique or not. The 'abs' makes sure that even if it's a negative number that it is made positive, although a 'mov' would work for this purpose as well. The if_ne r0, -ro is a clever way to say 'nonzero', as only zero would equal to it's negative.
There's nothing significant about those instructions, and I just reused them because they were already there. In general, I prefer to mildly tweak code that is there, rather than rewrite it, as rewrites tend to introduce bugs. But if I do put in new code, I would never use this sequence because it's not clear enough.
Here is the MSDN page for the if_ne:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb174583(v=vs.85).aspx
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
In general, I recommend doing the mov into r0 before that sequence rather than modifying the sequence. It's slightly safer to keep that sequence intact, because if you happen to miss a variable, or have a typo, you'll get a silent mystery failure.
So if the code did a
Then we'd know that r4 was the expected output (for vertex shader). If we thought it wasn't stereo for some reason, we then do the
No strict rules here, I just like to keep the prime directive intact because it's more clear to me when skimming code.
DarkStarSword nicely addressed the idea for how you decide. It's basically trial and error with deductive reasoning thrown in.
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
While I change convergence, the two blue ribbons either move apart or closer together, but only for a short while, before seemingly snapping back to their old position. As soon as I stop changing convergence, they also snap back.
Does that provide any insight?
What you learned from that is that since they stayed at their old position the adjustment is not dependent on convergence.
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
So I decided to try & fix Besiege as a test. There's a weird ghosting around trees on the first map on Ipsilon. I've dumped what I think is the right shader. I've declared a local constant c200 & use it to set the output color register oC0 to 0000. Here's the code:
I tried both mov & move_pp instructions.
Now when I go back into the game & hit F10 nothing happens. I checked that the folders are named correctly, the file is placed in "Besiege\ShaderOverride\PixelShaders" & the file has hex name with 8 chars. Just to be safe I stripped down my DX9settings.ini file to just these lines:
But still the fix refuses to work.
I've spent a good bit of 2 hrs trying to figure this out. I've hit a wall. Any suggestions on what to do in such situations?
Another thing that I noticed is that there are instructions like these in many shaders:
mov_pp
mul_pp & so on
How are these instructions different from the regular instructions? I searched MSDN for these but the search didn't turn up anything.
You'll want to convert the shader code to ps_3_0 with mana84's tool. http://helixmod.blogspot.com/2013/05/vs11vs20-vs30-converter.html
Or you can do it by hand as described:
https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/post/3653984/#3653984
Or you can use DarkStarSwords sweet shadertool.py, which will convert it:
https://github.com/DarkStarSword/3d-fixes/blob/33dbc45e6c8f57f0971f1b499220473ba2ea9f81/shadertool.py
The mov_pp and other instructions means 'partial precision'. It's not relevant to the problem.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb219850%28v=vs.85%29.aspx
As a general idea for debugging odd failures like this, you'll want to check the LOG.txt first and see if there is an error. I can't remember if ps_2_0 is reported or not.
If that didn't show anything, then you try to deliberately break it by putting in bad code, to make sure it's being loaded and seen. If a bad line didn't make a debug output in the LOG.txt, you know it's not being seen for some reason.
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
One thing I found that I find strange is that whenever I use s0 or s1 in the vertex shader, I get a result. If I use s2, I don't.
In a pixel shader I noticed samplers being used that weren't declared in the code (though they were mentioned in the header).
In all, now, I'm not so certain anymore texldl is getting its info from the right place?
In the .ini I found entries that allow you to set default samplers, but neither setting seems to have any effect.......
In all I don't think I understand this bit well enough.
http://photos.3dvisionlive.com/eroc_remag/image/54ee99e8e7e5648905000016/
http://photos.3dvisionlive.com/eroc_remag/image/54ee9a32e7e5642f7a00007f/
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
What version shader was it? Samplers only had to be declared starting with shader model 2, so if it's an earlier version that would make sense. If you need to use one of these in a fix it will need to be updated to shader model 3. My shadertool.py can upgrade vs_1_1, vs_2_0 and ps_2_0 shaders - I can add support for other versions, but I need to find good (non-trivial) shaders to test it against to make sure it works properly.
I take it you are referring to DefPSSampler and DefVSSampler. There is a bit of a gotcha with DefVSSampler (but not DefPSSampler) that you need to be aware of - you need to add 257 to whichever of the four (s0-s3) sampler numbers you want to use:
This quirk does not apply to DefPSSampler, which you simply set to a number from 0 to 13 corresponding to the sampler number s0-s13 you want to use.
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
This looks fine to me - can you post your DX9Settings.ini?
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