ok, thanks for that info. I'll take a look through it.
Regarding the overlay, how do you guys keep track of which shaders you're working on? For example, there are about 6 different shaders in the Crew that seem to affect the headlights. Turning them on/off one by one (and remembering which ones are which) would surely be a lot easier if I could make a note of where they are rather than blindly flicking through the lot of them until I finally spot them each time. (Or even if there was just some notification that I'd gotten to the end of the shaders and was looping back through them). Those simple numbers (not the hex codes) in the helixmod seemed super useful to me for that purpose.
Don't you guys find working without an overlay hurts your efficiency and costs you time in the long run? (not trying to be a smartarse here - just trying to figure out the best way to go about the workflow).
My current PC is actually a 2-in-1, where my 3rd monitor is connected to a separate PC, connected to my main PC via a home network. So I'll try observing the log file through the 2nd PC while I work, as DarStarSword suggested.
ok, thanks for that info. I'll take a look through it.
Regarding the overlay, how do you guys keep track of which shaders you're working on? For example, there are about 6 different shaders in the Crew that seem to affect the headlights. Turning them on/off one by one (and remembering which ones are which) would surely be a lot easier if I could make a note of where they are rather than blindly flicking through the lot of them until I finally spot them each time. (Or even if there was just some notification that I'd gotten to the end of the shaders and was looping back through them). Those simple numbers (not the hex codes) in the helixmod seemed super useful to me for that purpose.
Don't you guys find working without an overlay hurts your efficiency and costs you time in the long run? (not trying to be a smartarse here - just trying to figure out the best way to go about the workflow).
My current PC is actually a 2-in-1, where my 3rd monitor is connected to a separate PC, connected to my main PC via a home network. So I'll try observing the log file through the 2nd PC while I work, as DarStarSword suggested.
I usually find there's at least a few shaders that have a pretty big effect. Flipping the screen upside down, or turning the main character purple - stuff like that. I just watch for those to come around a second time. A beep code to indicate a complete loop might be nice though.
As for keeping track, I just dump the suspect shaders every time I see them, when I'm at the dumping phase. You can't create duplicates by doing this, so it's pretty easy to identify all the shaders for an effect. Then you can add comments at the top of them with // for later reference. I've also tried making a notepad file to use as an index, where I write down the CRCs and what they do.
I usually find there's at least a few shaders that have a pretty big effect. Flipping the screen upside down, or turning the main character purple - stuff like that. I just watch for those to come around a second time. A beep code to indicate a complete loop might be nice though.
As for keeping track, I just dump the suspect shaders every time I see them, when I'm at the dumping phase. You can't create duplicates by doing this, so it's pretty easy to identify all the shaders for an effect. Then you can add comments at the top of them with // for later reference. I've also tried making a notepad file to use as an index, where I write down the CRCs and what they do.
Can someone help me figure out how to edit these shaders? I've identified various shaders, saved them, and edited them. I can't see any constants in there (like -1.0, -0.5, 0, 0.5, 1.0 in The Ball for example). I tried adding o0=0; to the bottom of various sections, but when I hit F10 or reload the game I can't see any change.
Here's one of the shaders. What would you suggest I edit and how?
For workflow, I typically will find a given shader by seeing it go blank, then mark it with Num3 or Num6. That saves the file Decompiled into ShaderFixes. Sort that folder by most recent date, and you always get the one you touched last. If you Mark it again, it will double high beep to say it's a dupe, but will also 'touch' the file so it sorts to top.
For seeing full cycle, as noted by Pirate there is almost always something obvious that blinks out that lets me know I've cycled all the way around. You can also hold down the key for auto-repeat now and watch it cycle a couple of times if that helps.
I usually will cycle through to find good candidates, then alt-tab out and edit the new file directly. Rather than take notes or remember CRCs, I just edit the header, and add comments to tell me what the file is about.
If I think it's the right one, I'll add a zero output, save, then alt-tab back into the game and hit F10 to reload the shader. If you get a high-beep it worked, if a low beep, a syntax error. You don't need to relaunch the game, it's all live. If you have the right combo, you should see the shader effect disappear.
For your file there, that looks pretty OK. For 3Dmigoto, we want to edit the HLSL, not the ASM. The ASM is only for reference and for trying to determine if it decompiles right. (Since you are the second person to get snagged by this I think I'll remove the ASM from the Mark file by default).
For last few lines:
[code]...
o2.w = 0.000000000e+000;
// Disable bloom output
o0=0;
o1=0;
o2=0;
return;
}[/code]
o0 may not be the only one necessary. In this case, I'd do all three. Usually for pixel shaders, there is only one output. If zero doesn't work, it's worth trying setting them to 1.
For workflow, I typically will find a given shader by seeing it go blank, then mark it with Num3 or Num6. That saves the file Decompiled into ShaderFixes. Sort that folder by most recent date, and you always get the one you touched last. If you Mark it again, it will double high beep to say it's a dupe, but will also 'touch' the file so it sorts to top.
For seeing full cycle, as noted by Pirate there is almost always something obvious that blinks out that lets me know I've cycled all the way around. You can also hold down the key for auto-repeat now and watch it cycle a couple of times if that helps.
I usually will cycle through to find good candidates, then alt-tab out and edit the new file directly. Rather than take notes or remember CRCs, I just edit the header, and add comments to tell me what the file is about.
If I think it's the right one, I'll add a zero output, save, then alt-tab back into the game and hit F10 to reload the shader. If you get a high-beep it worked, if a low beep, a syntax error. You don't need to relaunch the game, it's all live. If you have the right combo, you should see the shader effect disappear.
For your file there, that looks pretty OK. For 3Dmigoto, we want to edit the HLSL, not the ASM. The ASM is only for reference and for trying to determine if it decompiles right. (Since you are the second person to get snagged by this I think I'll remove the ASM from the Mark file by default).
o0 may not be the only one necessary. In this case, I'd do all three. Usually for pixel shaders, there is only one output. If zero doesn't work, it's worth trying setting them to 1.
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"]For workflow, I typically will find a given shader by seeing it go blank, then mark it with Num3 or Num6. That saves the file Decompiled into ShaderFixes. Sort that folder by most recent date, and you always get the one you touched last. If you Mark it again, it will double high beep to say it's a dupe, but will also 'touch' the file so it sorts to top.
For seeing full cycle, as noted by Pirate there is almost always something obvious that blinks out that lets me know I've cycled all the way around. You can also hold down the key for auto-repeat now and watch it cycle a couple of times if that helps.
I usually will cycle through to find good candidates, then alt-tab out and edit the new file directly. Rather than take notes or remember CRCs, I just edit the header, and add comments to tell me what the file is about.[/quote]
Sigh. That to me says that a time-saving overlay should be at the top of your priorities list. I guess it's the age-old issue of you programmer types being from Neptune and us designer types being from Saturn :p
ok, thanks for the help. I'm making good progress here. I'm having to delete all sorts of crap though - lights, reflections, smoke, screen splatters, etc - because there's a lot that doesn't render correctly.
I'll probably try learning how to reposition things eventually. Though for now, I'm just going to try and disable everything I can spot.
Kind of enjoying this :)
bo3b said:For workflow, I typically will find a given shader by seeing it go blank, then mark it with Num3 or Num6. That saves the file Decompiled into ShaderFixes. Sort that folder by most recent date, and you always get the one you touched last. If you Mark it again, it will double high beep to say it's a dupe, but will also 'touch' the file so it sorts to top.
For seeing full cycle, as noted by Pirate there is almost always something obvious that blinks out that lets me know I've cycled all the way around. You can also hold down the key for auto-repeat now and watch it cycle a couple of times if that helps.
I usually will cycle through to find good candidates, then alt-tab out and edit the new file directly. Rather than take notes or remember CRCs, I just edit the header, and add comments to tell me what the file is about.
Sigh. That to me says that a time-saving overlay should be at the top of your priorities list. I guess it's the age-old issue of you programmer types being from Neptune and us designer types being from Saturn :p
ok, thanks for the help. I'm making good progress here. I'm having to delete all sorts of crap though - lights, reflections, smoke, screen splatters, etc - because there's a lot that doesn't render correctly.
I'll probably try learning how to reposition things eventually. Though for now, I'm just going to try and disable everything I can spot.
There's actually an awful lot wrong with the 3D in this game - I just keep finding more and more. Huge problems with water reflections, whole skyscrapers rendered wrong, the reflection on your own car's roof almost never looks right, the map is barely usable.
Some things I even have trouble finding shaders for. I'll keep plugging away, but I don't know that it's a very appropriate game for a first-timer.
If all I manage to do is disable stuff, I'll be hesitant to release my fix, since there'll be barely any game left.
There's actually an awful lot wrong with the 3D in this game - I just keep finding more and more. Huge problems with water reflections, whole skyscrapers rendered wrong, the reflection on your own car's roof almost never looks right, the map is barely usable.
Some things I even have trouble finding shaders for. I'll keep plugging away, but I don't know that it's a very appropriate game for a first-timer.
If all I manage to do is disable stuff, I'll be hesitant to release my fix, since there'll be barely any game left.
[quote="Volnaiskra"]Sigh. That to me says that a time-saving overlay should be at the top of your priorities list. I guess it's the age-old issue of you programmer types being from Neptune and us designer types being from Saturn :p
ok, thanks for the help. I'm making good progress here. I'm having to delete all sorts of crap though - lights, reflections, smoke, screen splatters, etc - because there's a lot that doesn't render correctly.
I'll probably try learning how to reposition things eventually. Though for now, I'm just going to try and disable everything I can spot.
Kind of enjoying this :)[/quote]
I'm confused on how the overlay is actually a significant time saving. I'm more than happy to add something like that if it saves time, I just haven't seen any need for it while using 3Dmigoto.
The primary time saver in 3Dmigoto is the live-loading and live editing of files. This is easily 5x faster than using HelixMod because of not needing to relaunch the game. The marked shaders are already moved into the right spot for fixing, and editing them directly removes the need to write down CRCs or otherwise keep track of annoying details.
The only shaders that are actively hunted are the ones live in the current frame. For most games, I can cycle every shader in the frame in less than a minute.
For your example here of 6 shaders affecting the headlights, you should be able to easily see them all in the ShaderFixes folder as the last 6 at the top of the list. But trust me, if you don't comment them as you find them, you'll shortly have too many to keep track of, and have to hunt them all over again.
I'm not trying to force a specific workflow though, if there are other techniques people want to use, we are open to adding those. Mostly I built everything to match Mike's workflow, and DarkStarSword has added some new stuff to better match his workflow.
Please give me more detail on what you feel would make a faster workflow? Is it only the wraparound?
Volnaiskra said:Sigh. That to me says that a time-saving overlay should be at the top of your priorities list. I guess it's the age-old issue of you programmer types being from Neptune and us designer types being from Saturn :p
ok, thanks for the help. I'm making good progress here. I'm having to delete all sorts of crap though - lights, reflections, smoke, screen splatters, etc - because there's a lot that doesn't render correctly.
I'll probably try learning how to reposition things eventually. Though for now, I'm just going to try and disable everything I can spot.
Kind of enjoying this :)
I'm confused on how the overlay is actually a significant time saving. I'm more than happy to add something like that if it saves time, I just haven't seen any need for it while using 3Dmigoto.
The primary time saver in 3Dmigoto is the live-loading and live editing of files. This is easily 5x faster than using HelixMod because of not needing to relaunch the game. The marked shaders are already moved into the right spot for fixing, and editing them directly removes the need to write down CRCs or otherwise keep track of annoying details.
The only shaders that are actively hunted are the ones live in the current frame. For most games, I can cycle every shader in the frame in less than a minute.
For your example here of 6 shaders affecting the headlights, you should be able to easily see them all in the ShaderFixes folder as the last 6 at the top of the list. But trust me, if you don't comment them as you find them, you'll shortly have too many to keep track of, and have to hunt them all over again.
I'm not trying to force a specific workflow though, if there are other techniques people want to use, we are open to adding those. Mostly I built everything to match Mike's workflow, and DarkStarSword has added some new stuff to better match his workflow.
Please give me more detail on what you feel would make a faster workflow? Is it only the wraparound?
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="Volnaiskra"]There's actually an awful lot wrong with the 3D in this game - I just keep finding more and more. Huge problems with water reflections, whole skyscrapers rendered wrong, the reflection on your own car's roof almost never looks right, the map is barely usable.
Some things I even have trouble finding shaders for. I'll keep plugging away, but I don't know that it's a very appropriate game for a first-timer.
If all I manage to do is disable stuff, I'll be hesitant to release my fix, since there'll be barely any game left.[/quote]
As a basic strategy for disabling effects, in general I recommend to only disable stuff that is eye-burningly annoying. Looking at Ron's earlier screen shots, things like the car rooftops are partly broken, but not eye-burning. The halos around lights and lights in the distance are eye-burning. You may find them just too annoying though.
I wouldn't worry about the fix- taking it from unplayable to playable is a giant leap, and will make any number of people happy.
Maybe not the best game to start with- but really, the best game to start with is one that you want. :->
Volnaiskra said:There's actually an awful lot wrong with the 3D in this game - I just keep finding more and more. Huge problems with water reflections, whole skyscrapers rendered wrong, the reflection on your own car's roof almost never looks right, the map is barely usable.
Some things I even have trouble finding shaders for. I'll keep plugging away, but I don't know that it's a very appropriate game for a first-timer.
If all I manage to do is disable stuff, I'll be hesitant to release my fix, since there'll be barely any game left.
As a basic strategy for disabling effects, in general I recommend to only disable stuff that is eye-burningly annoying. Looking at Ron's earlier screen shots, things like the car rooftops are partly broken, but not eye-burning. The halos around lights and lights in the distance are eye-burning. You may find them just too annoying though.
I wouldn't worry about the fix- taking it from unplayable to playable is a giant leap, and will make any number of people happy.
Maybe not the best game to start with- but really, the best game to start with is one that you want. :->
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
@DarkStarSword: Sorry, my comprehension is slipping.
I've isolated a headlight bloom effect. It appears to be a halo, because when I set it to 1 it affects a large area around each light, but not the whole screen.
I looked at your first example (life is strange), but that was helixmod, which doesn't seem very familiar to me after spending the evening in 3dmigoto. The code seems different. Also, I don't think setting bloom to infinity will help in this case because the shaders in question often affect lights very close to the camera.
Your 3rd example (FC4) sounds like it might be appropriate, but when I tried to copy/paste some of your code it didn't do anything.
Here's the shader. What should I try entering, and where? Do I need to define/declare constants? If so, where? Do I need try the separation*W thing? What would the syntax for that be?
[code]//headlight bloom?
Texture2D<float4> t1 : register(t1);
Texture2D<float4> t0 : register(t0);
SamplerState s1_s : register(s1);
SamplerState s0_s : register(s0);
Texture2D<float4> StereoParams : register(t125);
Texture1D<float4> IniParams : register(t120);
void main(
float4 v0 : SV_POSITION0,
float v1 : SV_ClipDistance0,
float4 v2 : TEXCOORD0,
float4 v3 : TEXCOORD1,
out float4 o0 : SV_Target0)
{
float4 r0,r1;
uint4 bitmask, uiDest;
float4 fDest;
r0.xyzw = t0.SampleLevel(s0_s, v2.zw, 0.000000000e+000).xyzw;
r0.x = v3.w < r0.x;
r0.x = r0.x ? 1.000000 : 0;
r1.xyzw = t1.Sample(s1_s, v2.xy).xyzw;
r0.yzw = v3.xyz * r1.www;
o0.xyz = r0.yzw * r0.xxx;
o0.w = 0.000000000e+000;
//disable
//o0=1;
//attempt to fix:
//Volnaiskra: added this but didn't do anything:
// We don't know the depth of the light, so just add separation, which generally looks fine:
float4 stereo = StereoParams.Load(0);
float separation = stereo.x; float convergence = stereo.y;
o0.x += separation;
return;
}
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_POSITION 0 xyzw 0 POS float
// SV_ClipDistance 0 x 1 CLIPDST float
// TEXCOORD 0 xyzw 2 NONE float xyzw
// TEXCOORD 1 xyzw 3 NONE float xyzw
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Target 0 xyzw 0 TARGET float xyzw
//
ps_4_0
dcl_sampler s0, mode_default
dcl_sampler s1, mode_default
dcl_resource_texture2d (float,float,float,float) t0
dcl_resource_texture2d (float,float,float,float) t1
dcl_input_ps linear v2.xyzw
dcl_input_ps linear v3.xyzw
dcl_output o0.xyzw
dcl_temps 2
sample_l r0.xyzw, v2.zwzz, t0.xyzw, s0, l(0.000000)
lt r0.x, v3.w, r0.x
and r0.x, r0.x, l(0x3f800000)
sample r1.xyzw, v2.xyxx, t1.xyzw, s1
mul r0.yzw, r1.wwww, v3.xxyz
mul o0.xyz, r0.xxxx, r0.yzwy
mov o0.w, l(0)
ret
// Approximately 0 instruction slots used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
[/code]
@DarkStarSword: Sorry, my comprehension is slipping.
I've isolated a headlight bloom effect. It appears to be a halo, because when I set it to 1 it affects a large area around each light, but not the whole screen.
I looked at your first example (life is strange), but that was helixmod, which doesn't seem very familiar to me after spending the evening in 3dmigoto. The code seems different. Also, I don't think setting bloom to infinity will help in this case because the shaders in question often affect lights very close to the camera.
Your 3rd example (FC4) sounds like it might be appropriate, but when I tried to copy/paste some of your code it didn't do anything.
Here's the shader. What should I try entering, and where? Do I need to define/declare constants? If so, where? Do I need try the separation*W thing? What would the syntax for that be?
// We don't know the depth of the light, so just add separation, which generally looks fine:
float4 stereo = StereoParams.Load(0);
float separation = stereo.x; float convergence = stereo.y;
o0.x += separation;
return;
}
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_POSITION 0 xyzw 0 POS float
// SV_ClipDistance 0 x 1 CLIPDST float
// TEXCOORD 0 xyzw 2 NONE float xyzw
// TEXCOORD 1 xyzw 3 NONE float xyzw
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Target 0 xyzw 0 TARGET float xyzw
//
ps_4_0
dcl_sampler s0, mode_default
dcl_sampler s1, mode_default
dcl_resource_texture2d (float,float,float,float) t0
dcl_resource_texture2d (float,float,float,float) t1
dcl_input_ps linear v2.xyzw
dcl_input_ps linear v3.xyzw
dcl_output o0.xyzw
dcl_temps 2
sample_l r0.xyzw, v2.zwzz, t0.xyzw, s0, l(0.000000)
lt r0.x, v3.w, r0.x
and r0.x, r0.x, l(0x3f800000)
sample r1.xyzw, v2.xyxx, t1.xyzw, s1
mul r0.yzw, r1.wwww, v3.xxyz
mul o0.xyz, r0.xxxx, r0.yzwy
mov o0.w, l(0)
ret
// Approximately 0 instruction slots used
[quote="bo3b"]I'm confused on how the overlay is actually a significant time saving. I'm more than happy to add something like that if it saves time, I just haven't seen any need for it while using 3Dmigoto.
The primary time saver in 3Dmigoto is the live-loading and live editing of files. This is easily 5x faster than using HelixMod because of not needing to relaunch the game. The marked shaders are already moved into the right spot for fixing, and editing them directly removes the need to write down CRCs or otherwise keep track of annoying details.
The only shaders that are actively hunted are the ones live in the current frame. For most games, I can cycle every shader in the frame in less than a minute.
For your example here of 6 shaders affecting the headlights, you should be able to easily see them all in the ShaderFixes folder as the last 6 at the top of the list. But trust me, if you don't comment them as you find them, you'll shortly have too many to keep track of, and have to hunt them all over again.
I'm not trying to force a specific workflow though, if there are other techniques people want to use, we are open to adding those. Mostly I built everything to match Mike's workflow, and DarkStarSword has added some new stuff to better match his workflow.
Please give me more detail on what you feel would make a faster workflow? Is it only the wraparound?[/quote]
The live loading is great. Because I'm editing the txt files on another computer on the network, I don't even have to alt-tab out of the game. I just save on one computer and press F10 on the other, and voila.
The files getting saved directly into where they need to be is great too. The issue is not on that end. I'm not interested in writing down CRC numbers or even the simple numbers. I just want to be able to have that quick reference available so that I know where I am in the order. The better my mental map of where I am, the more efficiently I can work. The more I have to guess and check and try to remember how far back that huge green shader was, the more resources are being funnelled away from the part of my brain that is trying to solve the actual problem.
Sure, I can cycle through the shaders in 40 seconds, but 40 seconds is a long time. And I won't necessarily know the loop by heart the first time. Realistically, I'll probably have to go through the loop several times before I have a good feeling for the loop.
It's not a huge thing, but it's just about reducing unecessary friction, which is almost always worth it in the long run. Being able to think "hey, doesn't this shader look like that other shader....I think it was about #85?" creates less friction than having to think "hey, doesn't this shader look like that other shader....I think it was about 4 seconds of holding down the NUM2 key after the second of the big green blobs?"
Also, being able to see numbers would help identify when you've skipped over 2 shaders instead of just one (which seems to happen a lot to me).
Finally, I don't always want to have my headphones on while shader hunting. In this case, I was unable to stop the obnoxious music from the game, and it was distracting me from hunting, so I took my headphones off. But without being able to hear the double beep, I couldn't tell when a shader I saved was one I'd already saved. Numbers would help prevent this problem too.
[quote="bo3b"]As a basic strategy for disabling effects, in general I recommend to only disable stuff that is eye-burningly annoying. Looking at Ron's earlier screen shots, things like the car rooftops are partly broken, but not eye-burning. The halos around lights and lights in the distance are eye-burning. You may find them just too annoying though.
I wouldn't worry about the fix- taking it from unplayable to playable is a giant leap, and will make any number of people happy.
Maybe not the best game to start with- but really, the best game to start with is one that you want. :->[/quote]Yeah, the roof is mildly annoying but not eye-burning. There are some serious eye-burning issues with the HUD though, so I'll try and fix that. And the map is atrocious, though there seems to be just one layer that needs to be moved for it to be ok.
There's incorrect lighting all over the place though. Sometimes it's minor, but other times it's an entire skyscraper or an entire lake.
Thief 4 is the game I REALLY want to fix. I'm hoping I can learn enough here that I can fix its various minor foibles.
bo3b said:I'm confused on how the overlay is actually a significant time saving. I'm more than happy to add something like that if it saves time, I just haven't seen any need for it while using 3Dmigoto.
The primary time saver in 3Dmigoto is the live-loading and live editing of files. This is easily 5x faster than using HelixMod because of not needing to relaunch the game. The marked shaders are already moved into the right spot for fixing, and editing them directly removes the need to write down CRCs or otherwise keep track of annoying details.
The only shaders that are actively hunted are the ones live in the current frame. For most games, I can cycle every shader in the frame in less than a minute.
For your example here of 6 shaders affecting the headlights, you should be able to easily see them all in the ShaderFixes folder as the last 6 at the top of the list. But trust me, if you don't comment them as you find them, you'll shortly have too many to keep track of, and have to hunt them all over again.
I'm not trying to force a specific workflow though, if there are other techniques people want to use, we are open to adding those. Mostly I built everything to match Mike's workflow, and DarkStarSword has added some new stuff to better match his workflow.
Please give me more detail on what you feel would make a faster workflow? Is it only the wraparound?
The live loading is great. Because I'm editing the txt files on another computer on the network, I don't even have to alt-tab out of the game. I just save on one computer and press F10 on the other, and voila.
The files getting saved directly into where they need to be is great too. The issue is not on that end. I'm not interested in writing down CRC numbers or even the simple numbers. I just want to be able to have that quick reference available so that I know where I am in the order. The better my mental map of where I am, the more efficiently I can work. The more I have to guess and check and try to remember how far back that huge green shader was, the more resources are being funnelled away from the part of my brain that is trying to solve the actual problem.
Sure, I can cycle through the shaders in 40 seconds, but 40 seconds is a long time. And I won't necessarily know the loop by heart the first time. Realistically, I'll probably have to go through the loop several times before I have a good feeling for the loop.
It's not a huge thing, but it's just about reducing unecessary friction, which is almost always worth it in the long run. Being able to think "hey, doesn't this shader look like that other shader....I think it was about #85?" creates less friction than having to think "hey, doesn't this shader look like that other shader....I think it was about 4 seconds of holding down the NUM2 key after the second of the big green blobs?"
Also, being able to see numbers would help identify when you've skipped over 2 shaders instead of just one (which seems to happen a lot to me).
Finally, I don't always want to have my headphones on while shader hunting. In this case, I was unable to stop the obnoxious music from the game, and it was distracting me from hunting, so I took my headphones off. But without being able to hear the double beep, I couldn't tell when a shader I saved was one I'd already saved. Numbers would help prevent this problem too.
bo3b said:As a basic strategy for disabling effects, in general I recommend to only disable stuff that is eye-burningly annoying. Looking at Ron's earlier screen shots, things like the car rooftops are partly broken, but not eye-burning. The halos around lights and lights in the distance are eye-burning. You may find them just too annoying though.
I wouldn't worry about the fix- taking it from unplayable to playable is a giant leap, and will make any number of people happy.
Maybe not the best game to start with- but really, the best game to start with is one that you want. :->
Yeah, the roof is mildly annoying but not eye-burning. There are some serious eye-burning issues with the HUD though, so I'll try and fix that. And the map is atrocious, though there seems to be just one layer that needs to be moved for it to be ok.
There's incorrect lighting all over the place though. Sometimes it's minor, but other times it's an entire skyscraper or an entire lake.
Thief 4 is the game I REALLY want to fix. I'm hoping I can learn enough here that I can fix its various minor foibles.
When I first started using 3Dmigoto I thought an overlay would be one of the first things on my TODO list, but I quickly found that I didn't really miss it and I had more pressing things to fix, so it's priority dropped down to a wishlist item.
I was actually thinking earlier that it might be handy to add a short click when hunting wraps around - it's not really a bother if I find a shader on the first pass, but some effects are hard to spot and in that case a cue to let me know that I've seen them all would be useful.
Anyway, back to the bloom. Since you have found that it is a halo around the lights you will likely need to move the position of the whole effect - which means the adjustment will need to take place to the output position (and possibly a texcoord or two) of the vertex shader, not the pixel shader you are looking at (o0 in the pixel shader will be the output colour, not the position).
As an alternative to hunting the vertex shader, you can take a look in the ShaderUsage.txt file that would have been produced when you dumped that pixel shader, which will tell you which vertex shader(s) it has been used with (this is another great time saver of 3Dmigoto). Just search for the hash of the pixel shader and look at the ParentVertexShaders list, then copy it from ShaderCache into ShaderFixes.
When I first started using 3Dmigoto I thought an overlay would be one of the first things on my TODO list, but I quickly found that I didn't really miss it and I had more pressing things to fix, so it's priority dropped down to a wishlist item.
I was actually thinking earlier that it might be handy to add a short click when hunting wraps around - it's not really a bother if I find a shader on the first pass, but some effects are hard to spot and in that case a cue to let me know that I've seen them all would be useful.
Anyway, back to the bloom. Since you have found that it is a halo around the lights you will likely need to move the position of the whole effect - which means the adjustment will need to take place to the output position (and possibly a texcoord or two) of the vertex shader, not the pixel shader you are looking at (o0 in the pixel shader will be the output colour, not the position).
As an alternative to hunting the vertex shader, you can take a look in the ShaderUsage.txt file that would have been produced when you dumped that pixel shader, which will tell you which vertex shader(s) it has been used with (this is another great time saver of 3Dmigoto). Just search for the hash of the pixel shader and look at the ParentVertexShaders list, then copy it from ShaderCache into ShaderFixes.
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="Volnaiskra"]Ok, and how do I move the position in the vertex Shader? Do I need to set any constants, and if so, how? [/quote]
No constants necessary in HLSL.
Here is my canonical code for fixing stereo locations in HLSL:
[code]...
// .Load should only be done once, but can be done anywhere in the code.
float4 stereo = StereoParams.Load(0);
float separation = stereo.x; float convergence = stereo.y;
// At this point, "location" is the output position, but missing stereo.
location.x += separation * (location.w - convergence);[/code]
You'll look for the output of the proper vertex shader, probably going to be o0, and apply the prime directive on it.
Given the wild variance of problems and the expected fixes though, it is likely not that simple. The o0 is already fixed by the NVidia driver, so it's not as likely this will be the problem.
Best bet would be to post both the vertex shader and pixel shader that are related to the effect, and we can take a look and walk you through it. Once the first one is more clear the rest will likely be similar.
You'll look for the output of the proper vertex shader, probably going to be o0, and apply the prime directive on it.
Given the wild variance of problems and the expected fixes though, it is likely not that simple. The o0 is already fixed by the NVidia driver, so it's not as likely this will be the problem.
Best bet would be to post both the vertex shader and pixel shader that are related to the effect, and we can take a look and walk you through it. Once the first one is more clear the rest will likely be similar.
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"]You'll look for the output of the proper vertex shader, probably going to be o0, and apply the prime directive on it.
Given the wild variance of problems and the expected fixes though, it is likely not that simple. The o0 is already fixed by the NVidia driver, so it's not as likely this will be the problem.[/quote]It is definitely worth trying first though. One thing I've worked out is that the driver uses heuristics to decide whether to apply the formula or not, and occasionally it decides not to apply it on something that it should have, and in that case manually applying it would work just fine. Whether it is the correct solution or not depends on whether o0.w has the correct depth information or just some constant value, and that varies from game to game.
How does the bloom behave if you vary the convergence setting (without any attempt to fix it)? Is it always drawn at screen depth (driver not applying the formula at all), does it move *much* faster than everything else in the scene (very low W value, likely constant), or comparable to objects at a certain distance (larger W value)?
bo3b said:You'll look for the output of the proper vertex shader, probably going to be o0, and apply the prime directive on it.
Given the wild variance of problems and the expected fixes though, it is likely not that simple. The o0 is already fixed by the NVidia driver, so it's not as likely this will be the problem.
It is definitely worth trying first though. One thing I've worked out is that the driver uses heuristics to decide whether to apply the formula or not, and occasionally it decides not to apply it on something that it should have, and in that case manually applying it would work just fine. Whether it is the correct solution or not depends on whether o0.w has the correct depth information or just some constant value, and that varies from game to game.
How does the bloom behave if you vary the convergence setting (without any attempt to fix it)? Is it always drawn at screen depth (driver not applying the formula at all), does it move *much* faster than everything else in the scene (very low W value, likely constant), or comparable to objects at a certain distance (larger W value)?
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="Volnaiskra"]The live loading is great. Because I'm editing the txt files on another computer on the network, I don't even have to alt-tab out of the game. I just save on one computer and press F10 on the other, and viola.
The files getting saved directly into where they need to be is great too. The issue is not on that end. I'm not interested in writing down CRC numbers or even the simple numbers. I just want to be able to have that quick reference available so that I know where I am in the order. The better my mental map of where I am, the more efficiently I can work. The more I have to guess and check and try to remember how far back that huge green shader was, the more resources are being funnelled away from the part of my brain that is trying to solve the actual problem.
Sure, I can cycle through the shaders in 40 seconds, but 40 seconds is a long time. And I won't necessarily know the loop by heart the first time. Realistically, I'll probably have to go through the loop several times before I have a good feeling for the loop.
It's not a huge thing, but it's just about reducing unecessary friction, which is almost always worth it in the long run. Being able to think "hey, doesn't this shader look like that other shader....I think it was about #85?" creates less friction than having to think "hey, doesn't this shader look like that other shader....I think it was about 4 seconds of holding down the NUM2 key after the second of the big green blobs?"
Also, being able to see numbers would help identify when you've skipped over 2 shaders instead of just one (which seems to happen a lot to me).
Finally, I don't always want to have my headphones on while shader hunting. In this case, I was unable to stop the obnoxious music from the game, and it was distracting me from hunting, so I took my headphones off. But without being able to hear the double beep, I couldn't tell when a shader I saved was one I'd already saved. Numbers would help prevent this problem too.[/quote]
Heh! You kids have it so easy today. :-> When I was hunting shaders back in the day, it took me 15 [i]minutes[/i] to cycle all the shaders. (Earlier HelixMod, <cough>)
More seriously, thanks very much for the detailed observation. I'll take a look at adding on-screen debug sooner. The 'where-am-I' is a good use case, as well as which I'm on, VS or PS.
I'll plan to add these for on-screen:
1) Active PS location (probably x/N format)
2) Active VS location (x/N format)
3) Current convergence and separation. (convergence, a must)
4) Error state of reload (syntax errors go red or something)
5) Duplicate Mark (maybe yellow text for location, red if Decompile failed)
Maybe:
5) Other state, like show_original active.
6) Active toggle override.
Others worth considering?
Edit: BTW, I just lowered the default speed of auto-repeat on shader hunting to make it less twitchy. You can set the speed to whatever you prefer with the d3dx.ini flag 'repeat_rate'.
Volnaiskra said:The live loading is great. Because I'm editing the txt files on another computer on the network, I don't even have to alt-tab out of the game. I just save on one computer and press F10 on the other, and viola.
The files getting saved directly into where they need to be is great too. The issue is not on that end. I'm not interested in writing down CRC numbers or even the simple numbers. I just want to be able to have that quick reference available so that I know where I am in the order. The better my mental map of where I am, the more efficiently I can work. The more I have to guess and check and try to remember how far back that huge green shader was, the more resources are being funnelled away from the part of my brain that is trying to solve the actual problem.
Sure, I can cycle through the shaders in 40 seconds, but 40 seconds is a long time. And I won't necessarily know the loop by heart the first time. Realistically, I'll probably have to go through the loop several times before I have a good feeling for the loop.
It's not a huge thing, but it's just about reducing unecessary friction, which is almost always worth it in the long run. Being able to think "hey, doesn't this shader look like that other shader....I think it was about #85?" creates less friction than having to think "hey, doesn't this shader look like that other shader....I think it was about 4 seconds of holding down the NUM2 key after the second of the big green blobs?"
Also, being able to see numbers would help identify when you've skipped over 2 shaders instead of just one (which seems to happen a lot to me).
Finally, I don't always want to have my headphones on while shader hunting. In this case, I was unable to stop the obnoxious music from the game, and it was distracting me from hunting, so I took my headphones off. But without being able to hear the double beep, I couldn't tell when a shader I saved was one I'd already saved. Numbers would help prevent this problem too.
Heh! You kids have it so easy today. :-> When I was hunting shaders back in the day, it took me 15 minutes to cycle all the shaders. (Earlier HelixMod, <cough>)
More seriously, thanks very much for the detailed observation. I'll take a look at adding on-screen debug sooner. The 'where-am-I' is a good use case, as well as which I'm on, VS or PS.
I'll plan to add these for on-screen:
1) Active PS location (probably x/N format)
2) Active VS location (x/N format)
3) Current convergence and separation. (convergence, a must)
4) Error state of reload (syntax errors go red or something)
5) Duplicate Mark (maybe yellow text for location, red if Decompile failed)
Maybe:
5) Other state, like show_original active.
6) Active toggle override.
Others worth considering?
Edit: BTW, I just lowered the default speed of auto-repeat on shader hunting to make it less twitchy. You can set the speed to whatever you prefer with the d3dx.ini flag 'repeat_rate'.
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
Regarding the overlay, how do you guys keep track of which shaders you're working on? For example, there are about 6 different shaders in the Crew that seem to affect the headlights. Turning them on/off one by one (and remembering which ones are which) would surely be a lot easier if I could make a note of where they are rather than blindly flicking through the lot of them until I finally spot them each time. (Or even if there was just some notification that I'd gotten to the end of the shaders and was looping back through them). Those simple numbers (not the hex codes) in the helixmod seemed super useful to me for that purpose.
Don't you guys find working without an overlay hurts your efficiency and costs you time in the long run? (not trying to be a smartarse here - just trying to figure out the best way to go about the workflow).
My current PC is actually a 2-in-1, where my 3rd monitor is connected to a separate PC, connected to my main PC via a home network. So I'll try observing the log file through the 2nd PC while I work, as DarStarSword suggested.
As for keeping track, I just dump the suspect shaders every time I see them, when I'm at the dumping phase. You can't create duplicates by doing this, so it's pretty easy to identify all the shaders for an effect. Then you can add comments at the top of them with // for later reference. I've also tried making a notepad file to use as an index, where I write down the CRCs and what they do.
Here's one of the shaders. What would you suggest I edit and how?
For seeing full cycle, as noted by Pirate there is almost always something obvious that blinks out that lets me know I've cycled all the way around. You can also hold down the key for auto-repeat now and watch it cycle a couple of times if that helps.
I usually will cycle through to find good candidates, then alt-tab out and edit the new file directly. Rather than take notes or remember CRCs, I just edit the header, and add comments to tell me what the file is about.
If I think it's the right one, I'll add a zero output, save, then alt-tab back into the game and hit F10 to reload the shader. If you get a high-beep it worked, if a low beep, a syntax error. You don't need to relaunch the game, it's all live. If you have the right combo, you should see the shader effect disappear.
For your file there, that looks pretty OK. For 3Dmigoto, we want to edit the HLSL, not the ASM. The ASM is only for reference and for trying to determine if it decompiles right. (Since you are the second person to get snagged by this I think I'll remove the ASM from the Mark file by default).
For last few lines:
o0 may not be the only one necessary. In this case, I'd do all three. Usually for pixel shaders, there is only one output. If zero doesn't work, it's worth trying setting them to 1.
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
Sigh. That to me says that a time-saving overlay should be at the top of your priorities list. I guess it's the age-old issue of you programmer types being from Neptune and us designer types being from Saturn :p
ok, thanks for the help. I'm making good progress here. I'm having to delete all sorts of crap though - lights, reflections, smoke, screen splatters, etc - because there's a lot that doesn't render correctly.
I'll probably try learning how to reposition things eventually. Though for now, I'm just going to try and disable everything I can spot.
Kind of enjoying this :)
Some things I even have trouble finding shaders for. I'll keep plugging away, but I don't know that it's a very appropriate game for a first-timer.
If all I manage to do is disable stuff, I'll be hesitant to release my fix, since there'll be barely any game left.
I'm confused on how the overlay is actually a significant time saving. I'm more than happy to add something like that if it saves time, I just haven't seen any need for it while using 3Dmigoto.
The primary time saver in 3Dmigoto is the live-loading and live editing of files. This is easily 5x faster than using HelixMod because of not needing to relaunch the game. The marked shaders are already moved into the right spot for fixing, and editing them directly removes the need to write down CRCs or otherwise keep track of annoying details.
The only shaders that are actively hunted are the ones live in the current frame. For most games, I can cycle every shader in the frame in less than a minute.
For your example here of 6 shaders affecting the headlights, you should be able to easily see them all in the ShaderFixes folder as the last 6 at the top of the list. But trust me, if you don't comment them as you find them, you'll shortly have too many to keep track of, and have to hunt them all over again.
I'm not trying to force a specific workflow though, if there are other techniques people want to use, we are open to adding those. Mostly I built everything to match Mike's workflow, and DarkStarSword has added some new stuff to better match his workflow.
Please give me more detail on what you feel would make a faster workflow? Is it only the wraparound?
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
As a basic strategy for disabling effects, in general I recommend to only disable stuff that is eye-burningly annoying. Looking at Ron's earlier screen shots, things like the car rooftops are partly broken, but not eye-burning. The halos around lights and lights in the distance are eye-burning. You may find them just too annoying though.
I wouldn't worry about the fix- taking it from unplayable to playable is a giant leap, and will make any number of people happy.
Maybe not the best game to start with- but really, the best game to start with is one that you want. :->
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
I've isolated a headlight bloom effect. It appears to be a halo, because when I set it to 1 it affects a large area around each light, but not the whole screen.
I looked at your first example (life is strange), but that was helixmod, which doesn't seem very familiar to me after spending the evening in 3dmigoto. The code seems different. Also, I don't think setting bloom to infinity will help in this case because the shaders in question often affect lights very close to the camera.
Your 3rd example (FC4) sounds like it might be appropriate, but when I tried to copy/paste some of your code it didn't do anything.
Here's the shader. What should I try entering, and where? Do I need to define/declare constants? If so, where? Do I need try the separation*W thing? What would the syntax for that be?
The live loading is great. Because I'm editing the txt files on another computer on the network, I don't even have to alt-tab out of the game. I just save on one computer and press F10 on the other, and voila.
The files getting saved directly into where they need to be is great too. The issue is not on that end. I'm not interested in writing down CRC numbers or even the simple numbers. I just want to be able to have that quick reference available so that I know where I am in the order. The better my mental map of where I am, the more efficiently I can work. The more I have to guess and check and try to remember how far back that huge green shader was, the more resources are being funnelled away from the part of my brain that is trying to solve the actual problem.
Sure, I can cycle through the shaders in 40 seconds, but 40 seconds is a long time. And I won't necessarily know the loop by heart the first time. Realistically, I'll probably have to go through the loop several times before I have a good feeling for the loop.
It's not a huge thing, but it's just about reducing unecessary friction, which is almost always worth it in the long run. Being able to think "hey, doesn't this shader look like that other shader....I think it was about #85?" creates less friction than having to think "hey, doesn't this shader look like that other shader....I think it was about 4 seconds of holding down the NUM2 key after the second of the big green blobs?"
Also, being able to see numbers would help identify when you've skipped over 2 shaders instead of just one (which seems to happen a lot to me).
Finally, I don't always want to have my headphones on while shader hunting. In this case, I was unable to stop the obnoxious music from the game, and it was distracting me from hunting, so I took my headphones off. But without being able to hear the double beep, I couldn't tell when a shader I saved was one I'd already saved. Numbers would help prevent this problem too.
Yeah, the roof is mildly annoying but not eye-burning. There are some serious eye-burning issues with the HUD though, so I'll try and fix that. And the map is atrocious, though there seems to be just one layer that needs to be moved for it to be ok.
There's incorrect lighting all over the place though. Sometimes it's minor, but other times it's an entire skyscraper or an entire lake.
Thief 4 is the game I REALLY want to fix. I'm hoping I can learn enough here that I can fix its various minor foibles.
I was actually thinking earlier that it might be handy to add a short click when hunting wraps around - it's not really a bother if I find a shader on the first pass, but some effects are hard to spot and in that case a cue to let me know that I've seen them all would be useful.
Anyway, back to the bloom. Since you have found that it is a halo around the lights you will likely need to move the position of the whole effect - which means the adjustment will need to take place to the output position (and possibly a texcoord or two) of the vertex shader, not the pixel shader you are looking at (o0 in the pixel shader will be the output colour, not the position).
As an alternative to hunting the vertex shader, you can take a look in the ShaderUsage.txt file that would have been produced when you dumped that pixel shader, which will tell you which vertex shader(s) it has been used with (this is another great time saver of 3Dmigoto). Just search for the hash of the pixel shader and look at the ParentVertexShaders list, then copy it from ShaderCache into ShaderFixes.
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 constants necessary in HLSL.
Here is my canonical code for fixing stereo locations in HLSL:
You'll look for the output of the proper vertex shader, probably going to be o0, and apply the prime directive on it.
Given the wild variance of problems and the expected fixes though, it is likely not that simple. The o0 is already fixed by the NVidia driver, so it's not as likely this will be the problem.
Best bet would be to post both the vertex shader and pixel shader that are related to the effect, and we can take a look and walk you through it. Once the first one is more clear the rest will likely be similar.
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
How does the bloom behave if you vary the convergence setting (without any attempt to fix it)? Is it always drawn at screen depth (driver not applying the formula at all), does it move *much* faster than everything else in the scene (very low W value, likely constant), or comparable to objects at a certain distance (larger W value)?
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
Heh! You kids have it so easy today. :-> When I was hunting shaders back in the day, it took me 15 minutes to cycle all the shaders. (Earlier HelixMod, <cough>)
More seriously, thanks very much for the detailed observation. I'll take a look at adding on-screen debug sooner. The 'where-am-I' is a good use case, as well as which I'm on, VS or PS.
I'll plan to add these for on-screen:
1) Active PS location (probably x/N format)
2) Active VS location (x/N format)
3) Current convergence and separation. (convergence, a must)
4) Error state of reload (syntax errors go red or something)
5) Duplicate Mark (maybe yellow text for location, red if Decompile failed)
Maybe:
5) Other state, like show_original active.
6) Active toggle override.
Others worth considering?
Edit: BTW, I just lowered the default speed of auto-repeat on shader hunting to make it less twitchy. You can set the speed to whatever you prefer with the d3dx.ini flag 'repeat_rate'.
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