Here's some tests that I ran to try to help decipher the problem with the stereo texture problem in the non-SLI case. It was suggested that I take a look at the StereoTextureEnable bits, and specifically bits 0-5 for a given profile to see if they helped the situation.
The short story is that I couldn't find anything that helped for this case.
[u]Here are some details:[/u]
I was modifying the 0x70EDB381 ID, using NVidia Inspector, under the assumption that is StereoTextureEnable. I used the game Saints Row IV since it shows the same problem with SLI working, non-SLI failing. I used driver 320.49 as the most stable and least complicated driver. We haven't seen this problem change with different drivers.
Here is the example image where it's working, and we fixed all the effects. This is using the regular profile for the game, and SLI 760 cards. The StereoTextureEnable was default at 0x24208B6C.
SaintsRowIV SLI 0x24208B6C:
[img]http://www.bo3b.net/SR4_test/SaintsRowIV%20SLI%20%200x24208B6C.jps[/img]
As you can see with this setup, we have a flawless image.
Here is the problem image, where the only difference is running non-SLI, a single GTX 760. Same fix installed, same bits for StereoTextureEnable of 0x24208B6C.
[img]http://www.bo3b.net/SR4_test/SaintsRowIV%20single%20card%200x24208B6C.jps[/img]
For this one, you can see that it's pretty good, but we have that texture problem on the left eye (image on right above). Most visible on the character in foreground, but also affects some lights in distance.
This is the fundamental problem we have not been able to resolve for single-card.
Here is the single card image, with all bits set 0,1,2,3,4,5 in StereoTextureEnable, as 0x24208BFF.jps.
[img]http://www.bo3b.net/SR4_test/SaintsRowIV%20single%20card%200x24208BFF.jps[/img]
As you can see the image is quite a lot worse, with haloing and broken lights.
I have images for all the other variants with different bits cleared and set, but they all show the same bad image with notable character haloing. I can share those if you want to see them, but the upshot is that the original 0x24208B6C is the best that it gets.
Here's one that is suggestive because the texture is no longer broken on the character, but it also has broken depth. Only the minimap and character are in stereo (character haloed). Using the 0x24208B4C bits, clearing bit 5. Also notice the performance jump. (assuming I didn't make a mistake)
[img]http://www.bo3b.net/SR4_test/SaintsRowIV%20single%200x24208B4C.jps[/img]
So.... Not sure if that tells you anything or not.
Seems like these are the right bits at least for StereoTextureEnable. Those bits have a dramatic effect on the image. That suggests that I'm in the right spot, it's just not working.
A basic question I have is whether there are any stereo bits that would be specific to SLI profiles?
If so, that would seem to be the key difference here. If not, that would suggest that the driver somehow behaves differently in SLI for these textures.
By experimenting with a null profile, I could also see that StereoTextureEnable is not the only thing required for a good image. With a single card, and a null profile with StereoTextureEnable set to all zeroes, the image is the same as with a full profile for the single card case:
[img]http://www.bo3b.net/SR4_test/SaintsRowIV%20single%200x00000000.jps[/img]
It's also interesting to note that under SLI with that condition, that it's broken very much like when I change the bits in single card:
[img]http://www.bo3b.net/SR4_test/SaintsRowIV%20SLI%200x00000000.jps[/img]
And lastly, I can tell that it's not solely about the StereoTextureEnable, because in SLI with null profile but StereoTextureEnable as 0x24208B6C, I still get a broken image:
[img]http://www.bo3b.net/SR4_test/SaintsRowIV%20SLI%20null%20profile%200x24208B6C.jps[/img]
If it's helpful, you can find a full set of well named full-size images on my server at: http://www.bo3b.net/SR4_test/
Here's some tests that I ran to try to help decipher the problem with the stereo texture problem in the non-SLI case. It was suggested that I take a look at the StereoTextureEnable bits, and specifically bits 0-5 for a given profile to see if they helped the situation.
The short story is that I couldn't find anything that helped for this case.
Here are some details:
I was modifying the 0x70EDB381 ID, using NVidia Inspector, under the assumption that is StereoTextureEnable. I used the game Saints Row IV since it shows the same problem with SLI working, non-SLI failing. I used driver 320.49 as the most stable and least complicated driver. We haven't seen this problem change with different drivers.
Here is the example image where it's working, and we fixed all the effects. This is using the regular profile for the game, and SLI 760 cards. The StereoTextureEnable was default at 0x24208B6C.
SaintsRowIV SLI 0x24208B6C:
As you can see with this setup, we have a flawless image.
Here is the problem image, where the only difference is running non-SLI, a single GTX 760. Same fix installed, same bits for StereoTextureEnable of 0x24208B6C.
For this one, you can see that it's pretty good, but we have that texture problem on the left eye (image on right above). Most visible on the character in foreground, but also affects some lights in distance.
This is the fundamental problem we have not been able to resolve for single-card.
Here is the single card image, with all bits set 0,1,2,3,4,5 in StereoTextureEnable, as 0x24208BFF.jps.
As you can see the image is quite a lot worse, with haloing and broken lights.
I have images for all the other variants with different bits cleared and set, but they all show the same bad image with notable character haloing. I can share those if you want to see them, but the upshot is that the original 0x24208B6C is the best that it gets.
Here's one that is suggestive because the texture is no longer broken on the character, but it also has broken depth. Only the minimap and character are in stereo (character haloed). Using the 0x24208B4C bits, clearing bit 5. Also notice the performance jump. (assuming I didn't make a mistake)
So.... Not sure if that tells you anything or not.
Seems like these are the right bits at least for StereoTextureEnable. Those bits have a dramatic effect on the image. That suggests that I'm in the right spot, it's just not working.
A basic question I have is whether there are any stereo bits that would be specific to SLI profiles?
If so, that would seem to be the key difference here. If not, that would suggest that the driver somehow behaves differently in SLI for these textures.
By experimenting with a null profile, I could also see that StereoTextureEnable is not the only thing required for a good image. With a single card, and a null profile with StereoTextureEnable set to all zeroes, the image is the same as with a full profile for the single card case:
It's also interesting to note that under SLI with that condition, that it's broken very much like when I change the bits in single card:
And lastly, I can tell that it's not solely about the StereoTextureEnable, because in SLI with null profile but StereoTextureEnable as 0x24208B6C, I still get a broken image:
Two updates:
1) For the mono textures in non-SLI, that is apparently a driver bug, and a bug has been filed. Gonna be awhile most likely, but that's a good step at least.
2) New version of 3Dmigoto is released:
[url]https://github.com/bo3b/3Dmigoto/releases/tag/0.99.35-alpha[/url]
This version includes DarkStarSword's modifications to keyboard handling to use GetAsyncKeyState instead of DirectInput.
That means this should be more reliable for shader hunting. And also not interfere or be blocked by game actions.
And that also means that we can now do Aiming Overrides. So, any key or mouse button can be used to make an aiming override. You can now change any of separation/convergence/iniParams via a keypress or mouse button.
This should open up some new possibilities, including dynamic HUD, dynamic cursors.
No support for xbox controllers in this version, we plan to add that later.
This version also includes a substantially improved Decompiler.
I've marked this an alpha release because these are pretty big changes, and we don't have much experience with them. If you have problems, please let us know.
1) For the mono textures in non-SLI, that is apparently a driver bug, and a bug has been filed. Gonna be awhile most likely, but that's a good step at least.
This version includes DarkStarSword's modifications to keyboard handling to use GetAsyncKeyState instead of DirectInput.
That means this should be more reliable for shader hunting. And also not interfere or be blocked by game actions.
And that also means that we can now do Aiming Overrides. So, any key or mouse button can be used to make an aiming override. You can now change any of separation/convergence/iniParams via a keypress or mouse button.
This should open up some new possibilities, including dynamic HUD, dynamic cursors.
No support for xbox controllers in this version, we plan to add that later.
This version also includes a substantially improved Decompiler.
I've marked this an alpha release because these are pretty big changes, and we don't have much experience with them. If you have problems, please let us know.
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
[quote="bo3b"]1) For the mono textures in non-SLI, that is apparently a driver bug, and a bug has been filed. Gonna be awhile most likely, but that's a good step at least.[/quote]
That is great news! Do we know any details about the bug? Anything that might help us work around it in the short term?
bo3b said:1) For the mono textures in non-SLI, that is apparently a driver bug, and a bug has been filed. Gonna be awhile most likely, but that's a good step at least.
That is great news! Do we know any details about the bug? Anything that might help us work around it in the short term?
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="DarkStarSword"][quote="bo3b"]1) For the mono textures in non-SLI, that is apparently a driver bug, and a bug has been filed. Gonna be awhile most likely, but that's a good step at least.[/quote]
That is great news! Do we know any details about the bug? Anything that might help us work around it in the short term?[/quote]
Nope, sorry, no extra details, or even why it suggested a driver bug.
bo3b said:1) For the mono textures in non-SLI, that is apparently a driver bug, and a bug has been filed. Gonna be awhile most likely, but that's a good step at least.
That is great news! Do we know any details about the bug? Anything that might help us work around it in the short term?
Nope, sorry, no extra details, or even why it suggested a driver bug.
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
Current best info on how to use the new iniParms or keyboard mechanism:
https://github.com/bo3b/3Dmigoto/commit/1e527ac0cded4c822c3aa2eec43e10858bf29309
https://github.com/bo3b/3Dmigoto/commit/0d7885dd0ef42856a3357f9b48115b605b84bff0
The key definitions are new and more flexible. We are using the VK form from Microsoft as this should be a lot more reliable. One side-effect of doing this is that you no longer need to localize your key names to your language.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx
Also worth noting that this change breaks use of Xbox controllers for either hunting or aiming override (which only partly worked before). We'll add xbox controller back later on, depending upon how big a problem this is.
Please let us know of any problems you run into. We don't have much experience with these changes yet.
Also worth noting that this change breaks use of Xbox controllers for either hunting or aiming override (which only partly worked before). We'll add xbox controller back later on, depending upon how big a problem this is.
Please let us know of any problems you run into. We don't have much experience with these changes yet.
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
bo3b....i'm using this version with Dying Light and i found a bug....i want to use 2 keys with "hold" function...but the hold function only works with the first key, in this case only with key1, not key2..... key2 works like normal preset.
bo3b....i'm using this version with Dying Light and i found a bug....i want to use 2 keys with "hold" function...but the hold function only works with the first key, in this case only with key1, not key2..... key2 works like normal preset.
[quote="DHR"]bo3b....i'm using this version with Dying Light and i found a bug....i want to use 2 keys with "hold" function...but the hold function only works with the first key, in this case only with key1, not key2..... key2 works like normal preset.[/quote]
Pretty sure that was working for me when I tested it (but I'm at work at the moment and can't double check)... Can you post the [Key*] sections of your d3dx.ini? Are both keys changing the same parameter (in which case the release may not do what you expect if you hold both at once) or different parameters?
Edit: Just saw helifax' bug report on the other thread (which I'll fix) - for now are you using lower case for "hold"?
DHR said:bo3b....i'm using this version with Dying Light and i found a bug....i want to use 2 keys with "hold" function...but the hold function only works with the first key, in this case only with key1, not key2..... key2 works like normal preset.
Pretty sure that was working for me when I tested it (but I'm at work at the moment and can't double check)... Can you post the [Key*] sections of your d3dx.ini? Are both keys changing the same parameter (in which case the release may not do what you expect if you hold both at once) or different parameters?
Edit: Just saw helifax' bug report on the other thread (which I'll fix) - for now are you using lower case for "hold"?
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
Hey Bo3b, Big thx for the docs !!!!
I just moved the original post I made on "Dying Light" thread here.
Original Message:
[quote="helifax"][quote="DarkStarSword"][quote="helifax"]Wow that is awesome news! ;)) I know I wanted something like this for DAI but the "old" wrapper using DirectInput interface didn't work.... Was this because of DirectInput ? as I understood the newest wrapper uses a different schema for keys...[/quote]
Yeah, I've reworked the whole input infrastructure in 3Dmigoto. You can now do something along these lines:
[code]
[Key1]
Key=RBUTTON
Convergence=0.1
Type=Hold
[Key2]
Key=Q
x=1
Type=Toggle
[Key3]
Key=Z
y=0.5
[/code][/quote]
Ok, I've just tried this and I can say that it is working but I think I might not do something right..
This is with 3DMigoto v.0.99.35.
I added a
[code]
[Key1]
Key=Q
Separation=0.0
Type=Toggle
[/code]
to the ini file (at the bottom, just appended).
If I press it once it makes the separation 0. However on the 2nd press it doesn't revert back to the previous value... Is this working as intended? Should I do something else here? (Am I missing an option?)
Sorry for posting it here again.
PS: The ini file that comes with the release needs updating as I couldn't find any of this inside in the comments but rather the old mechanism of key-bindings... Is that still supported?
EDIT2:
OK, I figured out where the problem is... I would say this is a bug but is up to you basically...:
[code]
.............
else if (!wcscmp(buf, L"toggle"))
{
type = KeyOverrideType::TOGGLE;
}
.....
[/code]
So as a consequence, if I write "Type=Toggle" It only works on 1st press. On second press it doesn't revert to the original value !!!!.
Same goes for Hold.
If I write "Type=toggle" then it works perfectly !!!!.
I would suggest making:
- Whatever you read from the ini file, make it wither lower case or uppercase
(std::transform(str.begin(), str.end(),str.begin(), ::toupper);)
- make the wcscmp on this. (I am sure you already know this but you can cast the std::string to const wchar_t using string.c_str();)
PPS: This was just a quick idea I had. You know the code better and how is structured, so probably your solution would be much better then what I posted above ;))
Now back to testing Mwahaha;)) [/quote]
I just moved the original post I made on "Dying Light" thread here.
Original Message:
helifax said:
DarkStarSword said:
helifax said:Wow that is awesome news! ;)) I know I wanted something like this for DAI but the "old" wrapper using DirectInput interface didn't work.... Was this because of DirectInput ? as I understood the newest wrapper uses a different schema for keys...
Yeah, I've reworked the whole input infrastructure in 3Dmigoto. You can now do something along these lines:
[Key1]
Key=RBUTTON
Convergence=0.1
Type=Hold
[Key2]
Key=Q
x=1
Type=Toggle
[Key3]
Key=Z
y=0.5
Ok, I've just tried this and I can say that it is working but I think I might not do something right..
This is with 3DMigoto v.0.99.35.
I added a
[Key1]
Key=Q
Separation=0.0
Type=Toggle
to the ini file (at the bottom, just appended).
If I press it once it makes the separation 0. However on the 2nd press it doesn't revert back to the previous value... Is this working as intended? Should I do something else here? (Am I missing an option?)
Sorry for posting it here again.
PS: The ini file that comes with the release needs updating as I couldn't find any of this inside in the comments but rather the old mechanism of key-bindings... Is that still supported?
EDIT2:
OK, I figured out where the problem is... I would say this is a bug but is up to you basically...:
.............
else if (!wcscmp(buf, L"toggle"))
{
type = KeyOverrideType::TOGGLE;
}
.....
So as a consequence, if I write "Type=Toggle" It only works on 1st press. On second press it doesn't revert to the original value !!!!.
Same goes for Hold.
If I write "Type=toggle" then it works perfectly !!!!.
I would suggest making:
- Whatever you read from the ini file, make it wither lower case or uppercase
(std::transform(str.begin(), str.end(),str.begin(), ::toupper);)
- make the wcscmp on this. (I am sure you already know this but you can cast the std::string to const wchar_t using string.c_str();)
PPS: This was just a quick idea I had. You know the code better and how is structured, so probably your solution would be much better then what I posted above ;))
Now back to testing Mwahaha;))
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Just updated the fix to make the compares of 'hold' and 'toggle' case insensitive. In general we try to make it all case insensitive as it's easier for the humans. The key names and 'Convergence' or 'X' or 'x' are already case insensitive.
Also added the docs to the d3dx.ini files, so it's directly available. And fixed a bug with requiring .x to be used first in iniParams.
New version with those tweaks is 0.99.36.
Just updated the fix to make the compares of 'hold' and 'toggle' case insensitive. In general we try to make it all case insensitive as it's easier for the humans. The key names and 'Convergence' or 'X' or 'x' are already case insensitive.
Also added the docs to the d3dx.ini files, so it's directly available. And fixed a bug with requiring .x to be used first in iniParams.
New version with those tweaks is 0.99.36.
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
[quote="DarkStarSword"]Thanks for that bo3b :)[/quote]
No problemo. :-> I [i]really [/i]needed to fix that .x problem anyway.
[quote="DHR"]This is the Key section:
[code][Key1]
Key=shift
convergence=1.608609e+000
type=hold
[Key2]
Key=o
convergence=1.428399e+000
[Key3]
Key=p
convergence=7.142391e-001
type=hold[/code][/quote]
Took a look using these key presses, and I can see them both activate in the log file. Not sure what's happening here, taking a closer look with the debugger.
Edit: As near as I can see this is working OK. I can do both Key1 and Key3, they activate like I'd expect on a Hold basis and change the convergence back and forth.
The Key2 also works, but may be the problem you are seeing. That one just does a single set to convergence. No hold, no toggle means that it just sets the convergence to that number. That also worked in my tests, and left it at that convergence as expected.
The way Key2 works as defined may not be what you were wanting though. It's working like we expect, but may not be what you were looking for. Probably you want to add 'type=hold' to Key2 as well.
Took a look using these key presses, and I can see them both activate in the log file. Not sure what's happening here, taking a closer look with the debugger.
Edit: As near as I can see this is working OK. I can do both Key1 and Key3, they activate like I'd expect on a Hold basis and change the convergence back and forth.
The Key2 also works, but may be the problem you are seeing. That one just does a single set to convergence. No hold, no toggle means that it just sets the convergence to that number. That also worked in my tests, and left it at that convergence as expected.
The way Key2 works as defined may not be what you were wanting though. It's working like we expect, but may not be what you were looking for. Probably you want to add 'type=hold' to Key2 as well.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
The short story is that I couldn't find anything that helped for this case.
Here are some details:
I was modifying the 0x70EDB381 ID, using NVidia Inspector, under the assumption that is StereoTextureEnable. I used the game Saints Row IV since it shows the same problem with SLI working, non-SLI failing. I used driver 320.49 as the most stable and least complicated driver. We haven't seen this problem change with different drivers.
Here is the example image where it's working, and we fixed all the effects. This is using the regular profile for the game, and SLI 760 cards. The StereoTextureEnable was default at 0x24208B6C.
SaintsRowIV SLI 0x24208B6C:
As you can see with this setup, we have a flawless image.
Here is the problem image, where the only difference is running non-SLI, a single GTX 760. Same fix installed, same bits for StereoTextureEnable of 0x24208B6C.
For this one, you can see that it's pretty good, but we have that texture problem on the left eye (image on right above). Most visible on the character in foreground, but also affects some lights in distance.
This is the fundamental problem we have not been able to resolve for single-card.
Here is the single card image, with all bits set 0,1,2,3,4,5 in StereoTextureEnable, as 0x24208BFF.jps.
As you can see the image is quite a lot worse, with haloing and broken lights.
I have images for all the other variants with different bits cleared and set, but they all show the same bad image with notable character haloing. I can share those if you want to see them, but the upshot is that the original 0x24208B6C is the best that it gets.
Here's one that is suggestive because the texture is no longer broken on the character, but it also has broken depth. Only the minimap and character are in stereo (character haloed). Using the 0x24208B4C bits, clearing bit 5. Also notice the performance jump. (assuming I didn't make a mistake)
So.... Not sure if that tells you anything or not.
Seems like these are the right bits at least for StereoTextureEnable. Those bits have a dramatic effect on the image. That suggests that I'm in the right spot, it's just not working.
A basic question I have is whether there are any stereo bits that would be specific to SLI profiles?
If so, that would seem to be the key difference here. If not, that would suggest that the driver somehow behaves differently in SLI for these textures.
By experimenting with a null profile, I could also see that StereoTextureEnable is not the only thing required for a good image. With a single card, and a null profile with StereoTextureEnable set to all zeroes, the image is the same as with a full profile for the single card case:
It's also interesting to note that under SLI with that condition, that it's broken very much like when I change the bits in single card:
And lastly, I can tell that it's not solely about the StereoTextureEnable, because in SLI with null profile but StereoTextureEnable as 0x24208B6C, I still get a broken image:
If it's helpful, you can find a full set of well named full-size images on my server at: http://www.bo3b.net/SR4_test/
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
1) For the mono textures in non-SLI, that is apparently a driver bug, and a bug has been filed. Gonna be awhile most likely, but that's a good step at least.
2) New version of 3Dmigoto is released:
https://github.com/bo3b/3Dmigoto/releases/tag/0.99.35-alpha
This version includes DarkStarSword's modifications to keyboard handling to use GetAsyncKeyState instead of DirectInput.
That means this should be more reliable for shader hunting. And also not interfere or be blocked by game actions.
And that also means that we can now do Aiming Overrides. So, any key or mouse button can be used to make an aiming override. You can now change any of separation/convergence/iniParams via a keypress or mouse button.
This should open up some new possibilities, including dynamic HUD, dynamic cursors.
No support for xbox controllers in this version, we plan to add that later.
This version also includes a substantially improved Decompiler.
I've marked this an alpha release because these are pretty big changes, and we don't have much experience with them. If you have problems, please let us know.
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
That is great news! Do we know any details about the bug? Anything that might help us work around it in the short term?
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
Nope, sorry, no extra details, or even why it suggested a driver bug.
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
https://github.com/bo3b/3Dmigoto/commit/1e527ac0cded4c822c3aa2eec43e10858bf29309
https://github.com/bo3b/3Dmigoto/commit/0d7885dd0ef42856a3357f9b48115b605b84bff0
The key definitions are new and more flexible. We are using the VK form from Microsoft as this should be a lot more reliable. One side-effect of doing this is that you no longer need to localize your key names to your language.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx
Also worth noting that this change breaks use of Xbox controllers for either hunting or aiming override (which only partly worked before). We'll add xbox controller back later on, depending upon how big a problem this is.
Please let us know of any problems you run into. We don't have much experience with these changes yet.
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
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Pretty sure that was working for me when I tested it (but I'm at work at the moment and can't double check)... Can you post the [Key*] sections of your d3dx.ini? Are both keys changing the same parameter (in which case the release may not do what you expect if you hold both at once) or different parameters?
Edit: Just saw helifax' bug report on the other thread (which I'll fix) - for now are you using lower case for "hold"?
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
I just moved the original post I made on "Dying Light" thread here.
Original Message:
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Also added the docs to the d3dx.ini files, so it's directly available. And fixed a bug with requiring .x to be used first in iniParams.
New version with those tweaks is 0.99.36.
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
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
No problemo. :-> I really needed to fix that .x problem anyway.
Took a look using these key presses, and I can see them both activate in the log file. Not sure what's happening here, taking a closer look with the debugger.
Edit: As near as I can see this is working OK. I can do both Key1 and Key3, they activate like I'd expect on a Hold basis and change the convergence back and forth.
The Key2 also works, but may be the problem you are seeing. That one just does a single set to convergence. No hold, no toggle means that it just sets the convergence to that number. That also worked in my tests, and left it at that convergence as expected.
The way Key2 works as defined may not be what you were wanting though. It's working like we expect, but may not be what you were looking for. Probably you want to add 'type=hold' to Key2 as well.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)