[quote="DarkStarSword"]That shouldn't matter - I specifically designed it so that should work. You'll get a second temporary register for stereoparams and it will load both from t125 separately, but that shouldn't hurt anything. t125 should only be declared once if it's the same in both InsertDeclarations sections. Can you show me exactly what it's doing that's wrong?[/quote]
Yes, ShaderRegex used 2 register for stereoparams, but the second one in the shader break the second fix and break the shader....if i copy paste both fixes manually in the same shader -ASM- (from the shaderregex log) and use the same register from stereoparams from the first fix in the second, the entire shader is fixed correcly...i need to use the same register stereoparams in both fixes.
In both ShaderRegex i have defined the stereoparams, because they works independant in some shaders.
Thanks for the 1.2.72 !! i will test later.
Nice hunting new feature!!! :)
DarkStarSword said:That shouldn't matter - I specifically designed it so that should work. You'll get a second temporary register for stereoparams and it will load both from t125 separately, but that shouldn't hurt anything. t125 should only be declared once if it's the same in both InsertDeclarations sections. Can you show me exactly what it's doing that's wrong?
Yes, ShaderRegex used 2 register for stereoparams, but the second one in the shader break the second fix and break the shader....if i copy paste both fixes manually in the same shader -ASM- (from the shaderregex log) and use the same register from stereoparams from the first fix in the second, the entire shader is fixed correcly...i need to use the same register stereoparams in both fixes.
In both ShaderRegex i have defined the stereoparams, because they works independant in some shaders.
Thanks for the 1.2.72 !! i will test later.
Nice hunting new feature!!! :)
i'm not home to post the exact shader, but is related to the UE4 Universal fix: [url]https://s3.amazonaws.com/dhr/Universal_Fixes/3Dmigoto.Universal.3DFix.UE4.x64.by.DHR.zip[/url]
Is one shader that need fixing using [ShaderRegex_Objects_1] + [ShaderRegexDecals1]. Both have declared:
[code]ld_indexable(texture2d)(float,float,float,float) ${stereo}.xyzw, l(0, 0, 0, 0), t125.xyzw\n[/code]
and
[code]dcl_resource_texture2d (float,float,float,float) t125[/code]
In others shaders both ShaderRegex are working OK when only 1 ShaderRegex is used per Shader. Works Ok independently. But when i used together don't work...the only way that both works Ok, is if a dump the asm shader, manually paste both fixes and in the second fix use the SAME stereoparams register from the first fix...if i use different stereoparams register for both pattern the shader is broke....In the log you can see that there are defined 2 stereoparams register, 1 for the first ShaderRegex and second for the other, BUT that seems to don't like to 3Dmigoto or the shader....because the shader is broken.
In others shaders both ShaderRegex are working OK when only 1 ShaderRegex is used per Shader. Works Ok independently. But when i used together don't work...the only way that both works Ok, is if a dump the asm shader, manually paste both fixes and in the second fix use the SAME stereoparams register from the first fix...if i use different stereoparams register for both pattern the shader is broke....In the log you can see that there are defined 2 stereoparams register, 1 for the first ShaderRegex and second for the other, BUT that seems to don't like to 3Dmigoto or the shader....because the shader is broken.
Hmm, something still doesn't quite add up, because that should be working, and when I've tested multiple ShaderRegex being applied to the same shader it has worked and both patterns had working independent stereo registers (so, I must be at stage 2 of the six stages of debugging :-p ). I probably need to see this in action - is there any particular UE4 game that is good to test this?
Hmm, something still doesn't quite add up, because that should be working, and when I've tested multiple ShaderRegex being applied to the same shader it has worked and both patterns had working independent stereo registers (so, I must be at stage 2 of the six stages of debugging :-p ). I probably need to see this in action - is there any particular UE4 game that is good to test this?
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
I saw this in ECHO, when i was testing the UE4 Universal Fix....and now i don't remember in what part i see the shader...damn! Is 1 shader in the whole game, and this game have a lot of fixed shaders....give me some time to track that shader again and of course do more test....if you already test that sceneario, probably was a mistake from my side :(
I saw this in ECHO, when i was testing the UE4 Universal Fix....and now i don't remember in what part i see the shader...damn! Is 1 shader in the whole game, and this game have a lot of fixed shaders....give me some time to track that shader again and of course do more test....if you already test that sceneario, probably was a mistake from my side :(
[quote="DHR"]i'm not home to post the exact shader, but is related to the UE4 Universal fix: [url]https://s3.amazonaws.com/dhr/Universal_Fixes/3Dmigoto.Universal.3DFix.UE4.x64.by.DHR.zip[/url]
Is one shader that need fixing using [ShaderRegex_Objects_1] + [ShaderRegexDecals1]. Both have declared:
[code]ld_indexable(texture2d)(float,float,float,float) ${stereo}.xyzw, l(0, 0, 0, 0), t125.xyzw\n[/code]
and
[code]dcl_resource_texture2d (float,float,float,float) t125[/code]
In others shaders both ShaderRegex are working OK when only 1 ShaderRegex is used per Shader. Works Ok independently. But when i used together don't work...the only way that both works Ok, is if a dump the asm shader, manually paste both fixes and in the second fix use the SAME stereoparams register from the first fix...if i use different stereoparams register for both pattern the shader is broke....In the log you can see that there are defined 2 stereoparams register, 1 for the first ShaderRegex and second for the other, BUT that seems to don't like to 3Dmigoto or the shader....because the shader is broken.[/quote]
Just to clarify one piece there- you cannot do two of these:
[code]dcl_resource_texture2d (float,float,float,float) t125[/code]
But it is OK to do two of these:
[code]ld_indexable(texture2d)(float,float,float,float) ${stereo}.xyzw, l(0, 0, 0, 0), t125.xyzw\n[/code]
If you have two of the first, that will cause it to not assemble, because of a duplicate declaration. For a single shader, changed with two regex, you'd want only one to include that dcl.
In others shaders both ShaderRegex are working OK when only 1 ShaderRegex is used per Shader. Works Ok independently. But when i used together don't work...the only way that both works Ok, is if a dump the asm shader, manually paste both fixes and in the second fix use the SAME stereoparams register from the first fix...if i use different stereoparams register for both pattern the shader is broke....In the log you can see that there are defined 2 stereoparams register, 1 for the first ShaderRegex and second for the other, BUT that seems to don't like to 3Dmigoto or the shader....because the shader is broken.
Just to clarify one piece there- you cannot do two of these:
If you have two of the first, that will cause it to not assemble, because of a duplicate declaration. For a single shader, changed with two regex, you'd want only one to include that dcl.
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="DHR"]I saw this in ECHO, when i was testing the UE4 Universal Fix....and now i don't remember in what part i see the shader...damn! Is 1 shader in the whole game, and this game have a lot of fixed shaders....give me some time to track that shader again and of course do more test....if you already test that sceneario, probably was a mistake from my side :([/quote]
Sounds like you have a "bug" there (the same shader gets corrected 2 times)... At least from my understanding from you explanation.
DHR said:I saw this in ECHO, when i was testing the UE4 Universal Fix....and now i don't remember in what part i see the shader...damn! Is 1 shader in the whole game, and this game have a lot of fixed shaders....give me some time to track that shader again and of course do more test....if you already test that sceneario, probably was a mistake from my side :(
Sounds like you have a "bug" there (the same shader gets corrected 2 times)... At least from my understanding from you explanation.
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
[quote="DHR"]i'm not home to post the exact shader, but is related to the UE4 Universal fix: [url]https://s3.amazonaws.com/dhr/Universal_Fixes/3Dmigoto.Universal.3DFix.UE4.x64.by.DHR.zip[/url]
Is one shader that need fixing using [ShaderRegex_Objects_1] + [ShaderRegexDecals1]. Both have declared:
[code]ld_indexable(texture2d)(float,float,float,float) ${stereo}.xyzw, l(0, 0, 0, 0), t125.xyzw\n[/code]
and
[code]dcl_resource_texture2d (float,float,float,float) t125[/code]
In others shaders both ShaderRegex are working OK when only 1 ShaderRegex is used per Shader. Works Ok independently. But when i used together don't work...the only way that both works Ok, is if a dump the asm shader, manually paste both fixes and in the second fix use the SAME stereoparams register from the first fix...if i use different stereoparams register for both pattern the shader is broke....In the log you can see that there are defined 2 stereoparams register, 1 for the first ShaderRegex and second for the other, BUT that seems to don't like to 3Dmigoto or the shader....because the shader is broken.
[/quote]
Sounds like you have a "bug" there (the same shader gets corrected 2 times)... At least from my understanding based on your explanation.
In others shaders both ShaderRegex are working OK when only 1 ShaderRegex is used per Shader. Works Ok independently. But when i used together don't work...the only way that both works Ok, is if a dump the asm shader, manually paste both fixes and in the second fix use the SAME stereoparams register from the first fix...if i use different stereoparams register for both pattern the shader is broke....In the log you can see that there are defined 2 stereoparams register, 1 for the first ShaderRegex and second for the other, BUT that seems to don't like to 3Dmigoto or the shader....because the shader is broken.
Sounds like you have a "bug" there (the same shader gets corrected 2 times)... At least from my understanding based on your explanation.
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
[quote="DarkStarSword"]a little teaser of a new feature you can look forward to that is going to replace the beeps with something a little more informative (I will be looking for feedback on this):
[url=https://forums.geforce.com/cmd/default/download-comment-attachment/74526/][img]https://forums.geforce.com/cmd/default/download-comment-attachment/74526/[/img][/url]
[/quote]
I see Bo3b has now released 1.3.1, so we will be looking for feedback on this new feature. I've tweaked the fonts a little since this screenshot, but essentially there are currently four levels of severity of different messages you may see - all of these will also be in the log file, so if they disappear too quickly you can still find them there.
[list]
[.] Green: Informational message to replace high beeps, confirming things like shader or d3dx.ini reload, successful copy on mark to ShaderFixes, etc. These messages will be hidden if hunting=0 and quickly disappear after 2 seconds.[/.]
[.] Yellow: Notifications that may be of interest to a shaderhacker, but not severe enough to bother an end user (hidden if hunting=0). Of note this is used to show HLSL warnings & errors in custom shaders and HLSL errors (not warnings) in replaced shaders on F10, and warns if a custom resource failed to be substantiated. Displayed for 5 seconds.[/.]
[.] Orange: Warnings displayed to both shaderhackers and end users for 10 seconds. Most of the possible messages fall into this category, and it includes things like ini parse errors, failures reloading shaders, etc.[/.]
[.] Red: Dire warnings displayed to both shaderhackers and end users for 20 seconds. Warns about severe issues, such as the profile not being installed or core functionality that hasn't worked. In a future version (I don't know how far yet) of 3DMigoto this will also warn if the game is running in DX12 mode (this situation currently just beeps instead). Some of these still include audible warnings to drive the point home, or when we aren't sure we're even going to be able to display a message at all.[/.]
[/list]
The timings I've chosen are pretty arbitrary - I didn't want the informational messages to be a bother so they disappear pretty quickly, but I did want the more severe messages to be displayed long enough to actually read them, but again not long enough to be a bother. This is an area I'd definitely like feedback on after you have been able to try these out when working on a real fix for a while - are any of the messages displayed for too long/short? Keep in mind of course that for a message that appears on F10 you can always press F10 again to bring it back, or refer to the log file, and I'd rather that than have any of these messages outstay their welcome. Of course if you fix the issue causing the warning and hit F10 they will disappear.
Currently a maximum of the six most severe messages will be displayed at a time to prevent walls of text that may occur in some circumstances, e.g. if a custom shader is missing or fails to compile than every run= line that refers to it will also issue a warning, but we probably don't care about those. Queued messages will still be displayed after the existing messages on screen time out. Six simultaneous messages was just an arbitrary choice - should it be higher? (I'm sort of thinking... maybe 10?)
Pressing F10 will clear out any messages that are currently displayed, so that you can be sure any messages you see afterwards are from the current reload attempt, not an old one. There's a part of me that actually misses the confirmation beep on F10, but that may be just because I'm used to it, so I want to give the new system a fair chance and see how it fairs in practice, and would ask that anyone else trying it out do the same. That's not to say we couldn't bring the confirmation beep back, but let's at least give this a fair go without it before deciding that.
Currently there are no tunable settings for these messages - we could add them, but I want to see if we can find settings that everyone is happy with.
Any other feedback is of course welcome :)
If anyone is using my custom cb debug shader you will notice it generates some warnings claiming that NaNs aren't possible - this is actually a HLSL compiler bug, as they most certainly are possible (you can generate these same warnings with float x = 1.#QNAN; if (isnan(x)) { ... } - the compiler isn't even bright enough to realise that something literally just set to NaN a moment ago could still be NaN in the very next line), but does indicate that the compiler has stripped out some important code from this shader that is there to deal with them, so they do not correctly display as NaN. A future version of 3DMigoto will include a flag to tell the compiler that it is wrong to fix this issue.
DarkStarSword said:a little teaser of a new feature you can look forward to that is going to replace the beeps with something a little more informative (I will be looking for feedback on this):
I see Bo3b has now released 1.3.1, so we will be looking for feedback on this new feature. I've tweaked the fonts a little since this screenshot, but essentially there are currently four levels of severity of different messages you may see - all of these will also be in the log file, so if they disappear too quickly you can still find them there.
Green: Informational message to replace high beeps, confirming things like shader or d3dx.ini reload, successful copy on mark to ShaderFixes, etc. These messages will be hidden if hunting=0 and quickly disappear after 2 seconds.
Yellow: Notifications that may be of interest to a shaderhacker, but not severe enough to bother an end user (hidden if hunting=0). Of note this is used to show HLSL warnings & errors in custom shaders and HLSL errors (not warnings) in replaced shaders on F10, and warns if a custom resource failed to be substantiated. Displayed for 5 seconds.
Orange: Warnings displayed to both shaderhackers and end users for 10 seconds. Most of the possible messages fall into this category, and it includes things like ini parse errors, failures reloading shaders, etc.
Red: Dire warnings displayed to both shaderhackers and end users for 20 seconds. Warns about severe issues, such as the profile not being installed or core functionality that hasn't worked. In a future version (I don't know how far yet) of 3DMigoto this will also warn if the game is running in DX12 mode (this situation currently just beeps instead). Some of these still include audible warnings to drive the point home, or when we aren't sure we're even going to be able to display a message at all.
The timings I've chosen are pretty arbitrary - I didn't want the informational messages to be a bother so they disappear pretty quickly, but I did want the more severe messages to be displayed long enough to actually read them, but again not long enough to be a bother. This is an area I'd definitely like feedback on after you have been able to try these out when working on a real fix for a while - are any of the messages displayed for too long/short? Keep in mind of course that for a message that appears on F10 you can always press F10 again to bring it back, or refer to the log file, and I'd rather that than have any of these messages outstay their welcome. Of course if you fix the issue causing the warning and hit F10 they will disappear.
Currently a maximum of the six most severe messages will be displayed at a time to prevent walls of text that may occur in some circumstances, e.g. if a custom shader is missing or fails to compile than every run= line that refers to it will also issue a warning, but we probably don't care about those. Queued messages will still be displayed after the existing messages on screen time out. Six simultaneous messages was just an arbitrary choice - should it be higher? (I'm sort of thinking... maybe 10?)
Pressing F10 will clear out any messages that are currently displayed, so that you can be sure any messages you see afterwards are from the current reload attempt, not an old one. There's a part of me that actually misses the confirmation beep on F10, but that may be just because I'm used to it, so I want to give the new system a fair chance and see how it fairs in practice, and would ask that anyone else trying it out do the same. That's not to say we couldn't bring the confirmation beep back, but let's at least give this a fair go without it before deciding that.
Currently there are no tunable settings for these messages - we could add them, but I want to see if we can find settings that everyone is happy with.
Any other feedback is of course welcome :)
If anyone is using my custom cb debug shader you will notice it generates some warnings claiming that NaNs aren't possible - this is actually a HLSL compiler bug, as they most certainly are possible (you can generate these same warnings with float x = 1.#QNAN; if (isnan(x)) { ... } - the compiler isn't even bright enough to realise that something literally just set to NaN a moment ago could still be NaN in the very next line), but does indicate that the compiler has stripped out some important code from this shader that is there to deal with them, so they do not correctly display as NaN. A future version of 3DMigoto will include a flag to tell the compiler that it is wrong to fix this issue.
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="bo3b"]Just to clarify one piece there- you cannot do two of these:
[code]dcl_resource_texture2d (float,float,float,float) t125[/code]
But it is OK to do two of these:
[code]ld_indexable(texture2d)(float,float,float,float) ${stereo}.xyzw, l(0, 0, 0, 0), t125.xyzw\n[/code]
If you have two of the first, that will cause it to not assemble, because of a duplicate declaration. For a single shader, changed with two regex, you'd want only one to include that dcl.[/quote]
I don't think this is the problem in this case - The ShaderRegex InsertDeclarations section is used to prevent inserting duplicate declarations, and looking at DHR's universal fix it appears to have both of these in the correct sections.
Still worth double checking that the patched shader in the log looks right of course.
[quote="DHR"]I saw this in ECHO, when i was testing the UE4 Universal Fix....and now i don't remember in what part i see the shader...damn! Is 1 shader in the whole game, and this game have a lot of fixed shaders....give me some time to track that shader again and of course do more test....if you already test that sceneario, probably was a mistake from my side :([/quote]
Yeah, I don't have that game to test, but if you do hit it again please send me the original shader (The .bin from export_binary=1 is my preferred format, otherwise the assembly .txt is fine) and what the d3d11_log.txt shows ShaderRegex is doing to it and I'll see if I can spot something amiss. I might still end up having to try it live in game - something about this doesn't add up, and it might not be something I can spot from the assembly alone. If you find the same problem in another game, let me know.
[quote="Helifax"]Sounds like you have a "bug" there (the same shader gets corrected 2 times)... At least from my understanding based on your explanation.[/quote]
If I'm understanding correctly DHR does want both patterns applied to the shader, which sounds like it is working, but for some unknown reason the second pattern is not loading StereoParams, even though it should be. This doesn't make sense and something doesn't add up, but it wouldn't be the first time something didn't make sense in DX assembly either...
Now, if your interpretation is right and one of the patterns was supposed to prevent the second applying - there's no way to explicitly tell 3DMigoto this at the moment, but it could be achieved by having the first pattern modify the shader such that the second cannot match it (e.g. by inserting a comment in the middle of the text the second is matching, or having the second pattern use negative look ahead/behind regex to check that a comment from the first is not present). The ShaderRegex sections are always run in a consistent order (sorted alphabetically by their section names), so you can control which takes priority over the other by naming them appropriately.
If you have two of the first, that will cause it to not assemble, because of a duplicate declaration. For a single shader, changed with two regex, you'd want only one to include that dcl.
I don't think this is the problem in this case - The ShaderRegex InsertDeclarations section is used to prevent inserting duplicate declarations, and looking at DHR's universal fix it appears to have both of these in the correct sections.
Still worth double checking that the patched shader in the log looks right of course.
DHR said:I saw this in ECHO, when i was testing the UE4 Universal Fix....and now i don't remember in what part i see the shader...damn! Is 1 shader in the whole game, and this game have a lot of fixed shaders....give me some time to track that shader again and of course do more test....if you already test that sceneario, probably was a mistake from my side :(
Yeah, I don't have that game to test, but if you do hit it again please send me the original shader (The .bin from export_binary=1 is my preferred format, otherwise the assembly .txt is fine) and what the d3d11_log.txt shows ShaderRegex is doing to it and I'll see if I can spot something amiss. I might still end up having to try it live in game - something about this doesn't add up, and it might not be something I can spot from the assembly alone. If you find the same problem in another game, let me know.
Helifax said:Sounds like you have a "bug" there (the same shader gets corrected 2 times)... At least from my understanding based on your explanation.
If I'm understanding correctly DHR does want both patterns applied to the shader, which sounds like it is working, but for some unknown reason the second pattern is not loading StereoParams, even though it should be. This doesn't make sense and something doesn't add up, but it wouldn't be the first time something didn't make sense in DX assembly either...
Now, if your interpretation is right and one of the patterns was supposed to prevent the second applying - there's no way to explicitly tell 3DMigoto this at the moment, but it could be achieved by having the first pattern modify the shader such that the second cannot match it (e.g. by inserting a comment in the middle of the text the second is matching, or having the second pattern use negative look ahead/behind regex to check that a comment from the first is not present). The ShaderRegex sections are always run in a consistent order (sorted alphabetically by their section names), so you can control which takes priority over the other by naming them appropriately.
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]the only way that both works Ok, is if a dump the asm shader, manually paste both fixes and in the second fix use the SAME stereoparams register from the first fix...[/quote]Here's a thought - I'm not sure it explains what's going on, but when you did this test did you define a ShaderOverride for it with the same command list as the ShaderRegex, since the ShaderRegex will not apply its command lists to any manually replaced shader found in ShaderFixes?
Also worth noting that if the shader is *not* in ShaderFixes but *does* have a ShaderOverride, ShaderRegex *will* still apply its command list, appended to the end of the ShaderOverride command list.
[quote] manually paste both fixes [/quote]Grab the patched version from the d3d11_log.txt instead, just in case you might be manually applying both fixes in a different way to ShaderRegex (maybe it only applied the first one, or they didn't combine in the way you expected?).
the only way that both works Ok, is if a dump the asm shader, manually paste both fixes and in the second fix use the SAME stereoparams register from the first fix...
Here's a thought - I'm not sure it explains what's going on, but when you did this test did you define a ShaderOverride for it with the same command list as the ShaderRegex, since the ShaderRegex will not apply its command lists to any manually replaced shader found in ShaderFixes?
Also worth noting that if the shader is *not* in ShaderFixes but *does* have a ShaderOverride, ShaderRegex *will* still apply its command list, appended to the end of the ShaderOverride command list.
manually paste both fixes
Grab the patched version from the d3d11_log.txt instead, just in case you might be manually applying both fixes in a different way to ShaderRegex (maybe it only applied the first one, or they didn't combine in the way you expected?).
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
When happens and test i add in the ini the ShaderOverride with the command list only for that shader, if not the entire shader disappear. And also copied the fix (both parts) from the d3d11_log.txt.
I will try to catch again that shader or if i see it in other game, i will test and send you all the data. I only see it 1 time, so is not a common case.
Thanks for this new feature, very handy!! i will test.
When happens and test i add in the ini the ShaderOverride with the command list only for that shader, if not the entire shader disappear. And also copied the fix (both parts) from the d3d11_log.txt.
I will try to catch again that shader or if i see it in other game, i will test and send you all the data. I only see it 1 time, so is not a common case.
Thanks for this new feature, very handy!! i will test.
Hey Guys,
DCS 2.5 Open Beta was released and I tried Migoto 1.2.71 I can get it working but ingame looks all Psychedelic colors..
Now sure what is going on but I was trying to make a fix.. I used on Older version of Migot and that worked fine but I would like to use the newer version of Migoto..
The version I used that worked was from DCS 1.5/2.2 fix from Lefuneste on the blog.. I tried several Previous version they all did the same thing with the colors..
Also I want to point out DCS uses Defered shadding so maybe that is a clue.. If you need more info Please let me know..
DCS 2.5 Open Beta was released and I tried Migoto 1.2.71 I can get it working but ingame looks all Psychedelic colors..
Now sure what is going on but I was trying to make a fix.. I used on Older version of Migot and that worked fine but I would like to use the newer version of Migoto..
The version I used that worked was from DCS 1.5/2.2 fix from Lefuneste on the blog.. I tried several Previous version they all did the same thing with the colors..
Also I want to point out DCS uses Defered shadding so maybe that is a clue.. If you need more info Please let me know..
[quote="DarkStarSword"]I see Bo3b has now released 1.3.1, so we will be looking for feedback on this new feature. I've tweaked the fonts a little since this screenshot, but essentially there are currently four levels of severity of different messages you may see - all of these will also be in the log file, so if they disappear too quickly you can still find them there.[/quote]
This is a very nice feature...really great...many thanks!
The timing for show the message are ok for me.
2 things that may be good:
1) Is possible to put a black background on the messages, sometimes i can't read because the game have some similar colors (blue sky for example, HUD elements that share the same space in the screen).
2) Is possible to also have the beeps and boops....i really miss those sounds :)
DarkStarSword said:I see Bo3b has now released 1.3.1, so we will be looking for feedback on this new feature. I've tweaked the fonts a little since this screenshot, but essentially there are currently four levels of severity of different messages you may see - all of these will also be in the log file, so if they disappear too quickly you can still find them there.
This is a very nice feature...really great...many thanks!
The timing for show the message are ok for me.
2 things that may be good:
1) Is possible to put a black background on the messages, sometimes i can't read because the game have some similar colors (blue sky for example, HUD elements that share the same space in the screen).
2) Is possible to also have the beeps and boops....i really miss those sounds :)
[quote="DHR"][quote="DarkStarSword"]I see Bo3b has now released 1.3.1, so we will be looking for feedback on this new feature. I've tweaked the fonts a little since this screenshot, but essentially there are currently four levels of severity of different messages you may see - all of these will also be in the log file, so if they disappear too quickly you can still find them there.[/quote]
This is a very nice feature...really great...many thanks!
The timing for show the message are ok for me.
2 things that may be good:
1) Is possible to put a black background on the messages, sometimes i can't read because the game have some similar colors (blue sky for example, HUD elements that share the same space in the screen).
2) Is possible to also have the beeps and boops....i really miss those sounds :) [/quote]
I have to agree with both of them! (Bring back the beep/boop please ^_^)
DarkStarSword said:I see Bo3b has now released 1.3.1, so we will be looking for feedback on this new feature. I've tweaked the fonts a little since this screenshot, but essentially there are currently four levels of severity of different messages you may see - all of these will also be in the log file, so if they disappear too quickly you can still find them there.
This is a very nice feature...really great...many thanks!
The timing for show the message are ok for me.
2 things that may be good:
1) Is possible to put a black background on the messages, sometimes i can't read because the game have some similar colors (blue sky for example, HUD elements that share the same space in the screen).
2) Is possible to also have the beeps and boops....i really miss those sounds :)
I have to agree with both of them! (Bring back the beep/boop please ^_^)
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
Yes, ShaderRegex used 2 register for stereoparams, but the second one in the shader break the second fix and break the shader....if i copy paste both fixes manually in the same shader -ASM- (from the shaderregex log) and use the same register from stereoparams from the first fix in the second, the entire shader is fixed correcly...i need to use the same register stereoparams in both fixes.
In both ShaderRegex i have defined the stereoparams, because they works independant in some shaders.
Thanks for the 1.2.72 !! i will test later.
Nice hunting new feature!!! :)
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
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
Is one shader that need fixing using [ShaderRegex_Objects_1] + [ShaderRegexDecals1]. Both have declared:
and
In others shaders both ShaderRegex are working OK when only 1 ShaderRegex is used per Shader. Works Ok independently. But when i used together don't work...the only way that both works Ok, is if a dump the asm shader, manually paste both fixes and in the second fix use the SAME stereoparams register from the first fix...if i use different stereoparams register for both pattern the shader is broke....In the log you can see that there are defined 2 stereoparams register, 1 for the first ShaderRegex and second for the other, BUT that seems to don't like to 3Dmigoto or the shader....because the shader is broken.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
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
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Just to clarify one piece there- you cannot do two of these:
But it is OK to do two of these:
If you have two of the first, that will cause it to not assemble, because of a duplicate declaration. For a single shader, changed with two regex, you'd want only one to include that dcl.
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
Sounds like you have a "bug" there (the same shader gets corrected 2 times)... At least from my understanding from you explanation.
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)
Sounds like you have a "bug" there (the same shader gets corrected 2 times)... At least from my understanding based on your explanation.
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)
I see Bo3b has now released 1.3.1, so we will be looking for feedback on this new feature. I've tweaked the fonts a little since this screenshot, but essentially there are currently four levels of severity of different messages you may see - all of these will also be in the log file, so if they disappear too quickly you can still find them there.
The timings I've chosen are pretty arbitrary - I didn't want the informational messages to be a bother so they disappear pretty quickly, but I did want the more severe messages to be displayed long enough to actually read them, but again not long enough to be a bother. This is an area I'd definitely like feedback on after you have been able to try these out when working on a real fix for a while - are any of the messages displayed for too long/short? Keep in mind of course that for a message that appears on F10 you can always press F10 again to bring it back, or refer to the log file, and I'd rather that than have any of these messages outstay their welcome. Of course if you fix the issue causing the warning and hit F10 they will disappear.
Currently a maximum of the six most severe messages will be displayed at a time to prevent walls of text that may occur in some circumstances, e.g. if a custom shader is missing or fails to compile than every run= line that refers to it will also issue a warning, but we probably don't care about those. Queued messages will still be displayed after the existing messages on screen time out. Six simultaneous messages was just an arbitrary choice - should it be higher? (I'm sort of thinking... maybe 10?)
Pressing F10 will clear out any messages that are currently displayed, so that you can be sure any messages you see afterwards are from the current reload attempt, not an old one. There's a part of me that actually misses the confirmation beep on F10, but that may be just because I'm used to it, so I want to give the new system a fair chance and see how it fairs in practice, and would ask that anyone else trying it out do the same. That's not to say we couldn't bring the confirmation beep back, but let's at least give this a fair go without it before deciding that.
Currently there are no tunable settings for these messages - we could add them, but I want to see if we can find settings that everyone is happy with.
Any other feedback is of course welcome :)
If anyone is using my custom cb debug shader you will notice it generates some warnings claiming that NaNs aren't possible - this is actually a HLSL compiler bug, as they most certainly are possible (you can generate these same warnings with float x = 1.#QNAN; if (isnan(x)) { ... } - the compiler isn't even bright enough to realise that something literally just set to NaN a moment ago could still be NaN in the very next line), but does indicate that the compiler has stripped out some important code from this shader that is there to deal with them, so they do not correctly display as NaN. A future version of 3DMigoto will include a flag to tell the compiler that it is wrong to fix this issue.
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 don't think this is the problem in this case - The ShaderRegex InsertDeclarations section is used to prevent inserting duplicate declarations, and looking at DHR's universal fix it appears to have both of these in the correct sections.
Still worth double checking that the patched shader in the log looks right of course.
Yeah, I don't have that game to test, but if you do hit it again please send me the original shader (The .bin from export_binary=1 is my preferred format, otherwise the assembly .txt is fine) and what the d3d11_log.txt shows ShaderRegex is doing to it and I'll see if I can spot something amiss. I might still end up having to try it live in game - something about this doesn't add up, and it might not be something I can spot from the assembly alone. If you find the same problem in another game, let me know.
If I'm understanding correctly DHR does want both patterns applied to the shader, which sounds like it is working, but for some unknown reason the second pattern is not loading StereoParams, even though it should be. This doesn't make sense and something doesn't add up, but it wouldn't be the first time something didn't make sense in DX assembly either...
Now, if your interpretation is right and one of the patterns was supposed to prevent the second applying - there's no way to explicitly tell 3DMigoto this at the moment, but it could be achieved by having the first pattern modify the shader such that the second cannot match it (e.g. by inserting a comment in the middle of the text the second is matching, or having the second pattern use negative look ahead/behind regex to check that a comment from the first is not present). The ShaderRegex sections are always run in a consistent order (sorted alphabetically by their section names), so you can control which takes priority over the other by naming them appropriately.
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
Also worth noting that if the shader is *not* in ShaderFixes but *does* have a ShaderOverride, ShaderRegex *will* still apply its command list, appended to the end of the ShaderOverride command list.
Grab the patched version from the d3d11_log.txt instead, just in case you might be manually applying both fixes in a different way to ShaderRegex (maybe it only applied the first one, or they didn't combine in the way you expected?).
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 will try to catch again that shader or if i see it in other game, i will test and send you all the data. I only see it 1 time, so is not a common case.
Thanks for this new feature, very handy!! i will test.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
DCS 2.5 Open Beta was released and I tried Migoto 1.2.71 I can get it working but ingame looks all Psychedelic colors..
Now sure what is going on but I was trying to make a fix.. I used on Older version of Migot and that worked fine but I would like to use the newer version of Migoto..
The version I used that worked was from DCS 1.5/2.2 fix from Lefuneste on the blog.. I tried several Previous version they all did the same thing with the colors..
Also I want to point out DCS uses Defered shadding so maybe that is a clue.. If you need more info Please let me know..
Intel i5 7600K @ 4.8ghz / MSI Z270 SLI / Asus 1080GTX - 416.16 / Optoma HD142x Projector / 1 4'x10' Curved Screen PVC / TrackIR / HOTAS Cougar / Cougar MFD's / Track IR / NVidia 3D Vision / Win 10 64bit
This is a very nice feature...really great...many thanks!
The timing for show the message are ok for me.
2 things that may be good:
1) Is possible to put a black background on the messages, sometimes i can't read because the game have some similar colors (blue sky for example, HUD elements that share the same space in the screen).
2) Is possible to also have the beeps and boops....i really miss those sounds :)
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
I have to agree with both of them! (Bring back the beep/boop please ^_^)
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)