Yes is a bigger shader.
I take a look and i think the CS is not the place to correct the lights, but is related to the problematic PS.
There are different PS related to each other...with different VS (according to shaderusage.txt), that's very strange. I need more time to take a look, something else is going on.
Yes is a bigger shader.
I take a look and i think the CS is not the place to correct the lights, but is related to the problematic PS.
There are different PS related to each other...with different VS (according to shaderusage.txt), that's very strange. I need more time to take a look, something else is going on.
I was taking a very small break from Tales of Zestiria and decided to play Blazblue Calamity Trigger. Backgrounds and effects work in 3D perfectly (aside from the locked internal resolution), but characters are at screen depth. With a convergence adjustment, they can be lined to their supposed position.
I wanted to see if I could change their position (if I could get a good formula, it would be perfect or almost perfect at any convergence). Buuuuut... there is a problem that bo3b faced in the past:
https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/111/
"preshader" code. With screen width and height being used in a constant that gets overwritten later. First I wanted to use some fixed depth with a hotkey. Here is the shader (it was vs_1_1 and had to be converted):
[code]
//Characters.
//
// Generated by Microsoft (R) D3DX9 Shader Compiler 9.15.779.0000
//
// Parameters:
//
// float fScreenHeigft;
// float fScreenWidth;
//
//
// Registers:
//
// Name Reg Size
// ------------- ----- ----
// fScreenWidth c0 1
// fScreenHeigft c1 1
//
//
// Default values:
//
// fScreenWidth
// c0 = { 0, 0, 0, 0 };
//
// fScreenHeigft
// c1 = { 0, 0, 0, 0 };
//
//preshader
//rcp c3.x, c0.x
//rcp c4.x, c1.x
// approximately 2 instructions used
//
// Generated by Microsoft (R) D3DX9 Shader Compiler 9.15.779.0000
//
// Parameters:
//
// float4x4 matWorld;
//
//
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// matWorld c0 3
//
//
// Default values:
//
// matWorld
// c0 = { 0, 0, 0, 0 };
// c1 = { 0, 0, 0, 0 };
// c2 = { 0, 0, 0, 0 };
//
vs_3_0
def c5, 1, 0, -0.5, -1
def c220, 0.40, 0, 0.0625, 0
def c201, 1280, 768, 0, 0
dcl_2d s0
dcl_position o10
dcl_texcoord o0.xy
dcl_color o8
dcl_position v0
dcl_texcoord v1
dcl_color v2
rcp r15.x, c201.x
rcp r16.x, c201.y
mad r0, v0.xyzx, c5.xxxy, c5.yyyx
dp4 o10.z, r0, c2
dp4 r1.w, r0, c0
dp4 r0.w, r0, c1
add r1.w, r1.w, c5.z
add r2.w, r1.w, r1.w
add r1.w, r0.w, c5.z
mov r0.xw, c5
mad r10.x, r2.w, r15.x, r0.w
texldl r11, c220.z, s0
mul r11.x, r11.x, -c235.x
add r10.x, r10.x, -r11.x
mov o10.x, r10.x
//mad o10.x, r2.w, r15.x, r0.w
add r0.w, r1.w, r1.w
mad o10.y, r0.w, -r16.x, r0.x
mov o10.w, c5.x
mul o0.xy, v1, c5.xwzw
mov o8, v2
// approximately 14 instruction slots used
[/code]
I created c201 to use the resolution I found in the LOG.txt, that refers to the internal resolution, I'm pretty sure of it:
[code]CreateRenderTarget
CreateRenderTarget Format 22, Width 1280, Height 768, Format 22, MultiSample 4, MultisampleQuality 0 Mode 0 Index
CreateDepthStencilSurface Format 75, Width 1280, Height 768, Format 75, MultiSample 4, MultisampleQuality 0 Mode 0 Index 0 [/code]
If I use 2560x1440, for example, characters are small and using the top left 1/4 of the screen. So I think I got it right, although some main meny elements disappeared.
When I enter a battle, the characters are showing, but when I jump, for example, they (and other post processing effects, which should be unrelated!) disappear until my character is on the ground again.
The shader doesn't give any errors in the log, but the hotkey I made for the depth doesn't work. I tried the same for the HUD and it also didn't work (it has the same preshader problem).
Has any solution for this been found since 2013? If not, I'll just lock the convergence to what is needed (but I would like to see the characters at some depth :( ).
Edit: untouched vs_3_0 shader:
[code]
//
// Generated by Microsoft (R) D3DX9 Shader Compiler 9.15.779.0000
//
// Parameters:
//
// float fScreenHeigft;
// float fScreenWidth;
//
//
// Registers:
//
// Name Reg Size
// ------------- ----- ----
// fScreenWidth c0 1
// fScreenHeigft c1 1
//
//
// Default values:
//
// fScreenWidth
// c0 = { 0, 0, 0, 0 };
//
// fScreenHeigft
// c1 = { 0, 0, 0, 0 };
//
preshader
rcp c3.x, c0.x
rcp c4.x, c1.x
// approximately 2 instructions used
//
// Generated by Microsoft (R) D3DX9 Shader Compiler 9.15.779.0000
//
// Parameters:
//
// float4x4 matWorld;
//
//
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// matWorld c0 3
//
//
// Default values:
//
// matWorld
// c0 = { 0, 0, 0, 0 };
// c1 = { 0, 0, 0, 0 };
// c2 = { 0, 0, 0, 0 };
//
vs_3_0
def c5, 1, 0, -0.5, -1
dcl_position o10
dcl_texcoord o0.xy
dcl_color o8
dcl_position v0
dcl_texcoord v1
dcl_color v2
mad r0, v0.xyzx, c5.xxxy, c5.yyyx
dp4 o10.z, r0, c2
dp4 r1.w, r0, c0
dp4 r0.w, r0, c1
add r1.w, r1.w, c5.z
add r2.w, r1.w, r1.w
add r1.w, r0.w, c5.z
mov r0.xw, c5
mad o10.x, r2.w, c3.x, r0.w
add r0.w, r1.w, r1.w
mad o10.y, r0.w, -c4.x, r0.x
mov o10.w, c5.x
mul o0.xy, v1, c5.xwzw
mov o8, v2
// approximately 14 instruction slots used
[/code]
I was taking a very small break from Tales of Zestiria and decided to play Blazblue Calamity Trigger. Backgrounds and effects work in 3D perfectly (aside from the locked internal resolution), but characters are at screen depth. With a convergence adjustment, they can be lined to their supposed position.
"preshader" code. With screen width and height being used in a constant that gets overwritten later. First I wanted to use some fixed depth with a hotkey. Here is the shader (it was vs_1_1 and had to be converted):
I created c201 to use the resolution I found in the LOG.txt, that refers to the internal resolution, I'm pretty sure of it:
CreateRenderTarget
CreateRenderTarget Format 22, Width 1280, Height 768, Format 22, MultiSample 4, MultisampleQuality 0 Mode 0 Index
CreateDepthStencilSurface Format 75, Width 1280, Height 768, Format 75, MultiSample 4, MultisampleQuality 0 Mode 0 Index 0
If I use 2560x1440, for example, characters are small and using the top left 1/4 of the screen. So I think I got it right, although some main meny elements disappeared.
When I enter a battle, the characters are showing, but when I jump, for example, they (and other post processing effects, which should be unrelated!) disappear until my character is on the ground again.
The shader doesn't give any errors in the log, but the hotkey I made for the depth doesn't work. I tried the same for the HUD and it also didn't work (it has the same preshader problem).
Has any solution for this been found since 2013? If not, I'll just lock the convergence to what is needed (but I would like to see the characters at some depth :( ).
When I last played that game, I found simply adjusting the convergence to the point that it pushed the characters in line with the background was good enough. Did you try that yet, or are you wanting to be able to adjust the convergence to be more or less than what it would take to achieve that alignment?
When I last played that game, I found simply adjusting the convergence to the point that it pushed the characters in line with the background was good enough. Did you try that yet, or are you wanting to be able to adjust the convergence to be more or less than what it would take to achieve that alignment?
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
[quote="DJ-RK"]Did you try that yet, or are you wanting to be able to adjust the convergence to be more or less than what it would take to achieve that alignment?[/quote]
I said "With a convergence adjustment, they can be lined to their supposed position.". So yes, I already know ow to use the correct convergence. I just wanted to try changing the character depth to properly align it at all convergence settings. At least "more or less".
DJ-RK said:Did you try that yet, or are you wanting to be able to adjust the convergence to be more or less than what it would take to achieve that alignment?
I said "With a convergence adjustment, they can be lined to their supposed position.". So yes, I already know ow to use the correct convergence. I just wanted to try changing the character depth to properly align it at all convergence settings. At least "more or less".
Sorry, my bad. Did a brief scan of your post and missed where you said that. (must have missed that whole paragraph you mentioned it, lol)
I take it you're passing in a constant on register c235? You sure that's not in conflict with a register already in use by another shader? Have you tried using just a local constant, like the ones provided in c5 maybe (just to see if they work)?
Honestly, for me I find Helixmod too tempermental and unstable these days. I've tried doing very basic fixes (halo's, etc) that I can do with my eyes closed when working with DX11/3DMigoto, but do weird things in Helixmod (like shifting both eyes in the same direction), so I wouldn't put it past you having done the right thing but being caught up on some weird 'gotcha'
Sorry, my bad. Did a brief scan of your post and missed where you said that. (must have missed that whole paragraph you mentioned it, lol)
I take it you're passing in a constant on register c235? You sure that's not in conflict with a register already in use by another shader? Have you tried using just a local constant, like the ones provided in c5 maybe (just to see if they work)?
Honestly, for me I find Helixmod too tempermental and unstable these days. I've tried doing very basic fixes (halo's, etc) that I can do with my eyes closed when working with DX11/3DMigoto, but do weird things in Helixmod (like shifting both eyes in the same direction), so I wouldn't put it past you having done the right thing but being caught up on some weird 'gotcha'
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
[quote="DJ-RK"]
I take it you're passing in a constant on register c235? You sure that's not in conflict with a register already in use by another shader? Have you tried using just a local constant, like the ones provided in c5 maybe (just to see if they work)?[/quote]
I tried commenting all code concerning that constant (also in DX9Settings.ini), and the result was the same. The problem isn't there.
Fake edit: Heyyy, I know what happens!!! Another vertex shader has the same CRC (actually at least 4 vertex shaders are using the same CRC)! So when it appears on screen, bam! Conflict.
Edit: I'll follow the "Overriding an Individual Instance of a Shader" section of the Helixmod feture list and report back.
Edit 2: I could manually convert its pixel shader to ps_3_0 and then put the "9A8ED0D6.txt.ps" name to the vertex shader. Now it's displaying correctly, without log or visual errors. My depth hotkey isn't working, so it's what I'll be modifying now. Let's see if I can.
Edit 3: static (without hotkey) depth works! Now I'll try to make a good formula.
DJ-RK said:
I take it you're passing in a constant on register c235? You sure that's not in conflict with a register already in use by another shader? Have you tried using just a local constant, like the ones provided in c5 maybe (just to see if they work)?
I tried commenting all code concerning that constant (also in DX9Settings.ini), and the result was the same. The problem isn't there.
Fake edit: Heyyy, I know what happens!!! Another vertex shader has the same CRC (actually at least 4 vertex shaders are using the same CRC)! So when it appears on screen, bam! Conflict.
Edit: I'll follow the "Overriding an Individual Instance of a Shader" section of the Helixmod feture list and report back.
Edit 2: I could manually convert its pixel shader to ps_3_0 and then put the "9A8ED0D6.txt.ps" name to the vertex shader. Now it's displaying correctly, without log or visual errors. My depth hotkey isn't working, so it's what I'll be modifying now. Let's see if I can.
Edit 3: static (without hotkey) depth works! Now I'll try to make a good formula.
I have some time and motivation this weekend. I think I will try to continue my classes in the shaderhackers school. Stopped at the point where you have to bind the shaders. ;)
I have some time and motivation this weekend. I think I will try to continue my classes in the shaderhackers school. Stopped at the point where you have to bind the shaders. ;)
Screenshot example:
[img]http://u.cubeupload.com/masterotaku/BBCT001.jpg[/img]
It will take a bit more time to fix character reflections (they disappeared in the screenshot because the shader is incomplete) because the preshader code is 8 lines long, but I know what to do.
After that, a bit of testing and maybe changing the HUD, it will be release time!
When the other Blazblue games are on sale (at a fair price), I'll buy them and fix them too.
It will take a bit more time to fix character reflections (they disappeared in the screenshot because the shader is incomplete) because the preshader code is 8 lines long, but I know what to do.
After that, a bit of testing and maybe changing the HUD, it will be release time!
When the other Blazblue games are on sale (at a fair price), I'll buy them and fix them too.
Sorry for the double post. There is an instruction from the original shader that I don't know how to convert (the log says that it doesn't recognize "neg"):
That's really weird that they generate an ASM instruction that is not valid.
I took a quick look, and I don't think that is a legitimate instruction. It's also not an intrinsic of any form, it's just a weird disassembler bug. There is an instruction 'ineg' for an integer negate, but that's only in SM4 and above.
For this one, we'll just have to guess what was intended. I think that your 'mov r19.w, -r18.w' is right. That doesn't have any constant register (read-only) problems, and should be right.
Since it doesn't work, that suggests something else is going wrong.
The problem with preshaders is that they have access to data that we do not have at shader time itself.
In the example I looked at earlier (Fear), the clouds were moved by a preshader, and those values were never available later. So in vs_3_0 without preshaders, there was no way to make the clouds move, because the original state was unavailable.
It would maybe be possible to do something really heroic like saving a cloud state in a HelixMod variable, but there's not a lot of incentive for a smallish effect.
For this example, my best guess is that there is constant state information that is now unchanging once the preshader is no longer running. In particular, we don't have any idea what the vEXPos does, or how it should change.
Best bet is to try to get a feel for what the effect is supposed to be doing, and maybe work out an alternate approach. In the Fear example, I just set the clouds to a fixed location.
That's really weird that they generate an ASM instruction that is not valid.
I took a quick look, and I don't think that is a legitimate instruction. It's also not an intrinsic of any form, it's just a weird disassembler bug. There is an instruction 'ineg' for an integer negate, but that's only in SM4 and above.
For this one, we'll just have to guess what was intended. I think that your 'mov r19.w, -r18.w' is right. That doesn't have any constant register (read-only) problems, and should be right.
Since it doesn't work, that suggests something else is going wrong.
The problem with preshaders is that they have access to data that we do not have at shader time itself.
In the example I looked at earlier (Fear), the clouds were moved by a preshader, and those values were never available later. So in vs_3_0 without preshaders, there was no way to make the clouds move, because the original state was unavailable.
It would maybe be possible to do something really heroic like saving a cloud state in a HelixMod variable, but there's not a lot of incentive for a smallish effect.
For this example, my best guess is that there is constant state information that is now unchanging once the preshader is no longer running. In particular, we don't have any idea what the vEXPos does, or how it should change.
Best bet is to try to get a feel for what the effect is supposed to be doing, and maybe work out an alternate approach. In the Fear example, I just set the clouds to a fixed location.
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 could make the effect appear, using once again the vertex shader to pixel shader association ("30E30EF5.txt.ps") (I need to do that for most vertex shaders I'm touching). The "neg substitute" was:
[code]mov r19.w, -r18.w[/code]
Sprites are at the correct depth that I wanted.
Using "mov r19.w, r18.w" instead made it appear in a wrong Y position. However, in all cases the reflection sprites are flickering like mad. Something must be wrong in the vs_3_0 conversion (I don't know where yet). The pixel shader conversion I made is correct, for example.
Original PS:
[code]
//
// Generated by Microsoft (R) D3DX9 Shader Compiler 9.15.779.0000
//
// Parameters:
//
// sampler2D PalSamp;
// sampler2D SampTex;
//
//
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// SampTex s0 1
// PalSamp s1 1
//
ps_1_4
def c0, 0.999949992, 0.999949992, 0.999949992, 0
texld r0, t0
mul r1.xyz, r0.w, c0
phase
texcrd r0.xyz, t1
texld r1, r1
mul r1, r1, v0
cmp r0.w, -r0.x, c0.w, r1.w
+ mov r0.xyz, r1
// approximately 6 instruction slots used (3 texture, 3 arithmetic)
[/code]
Converted:
[code]
//Character reflection PS.
//
// Generated by Microsoft (R) D3DX9 Shader Compiler 9.15.779.0000
//
// Parameters:
//
// sampler2D PalSamp;
// sampler2D SampTex;
//
//
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// SampTex s0 1
// PalSamp s1 1
//
ps_3_0
def c0, 0.999949992, 0.999949992, 0.999949992, 0
dcl_color v0
dcl_texcoord v1.xy
dcl_texcoord v2.xy
dcl_2d s0
dcl_2d s1
dcl_2d s2
//texld r0, t0
texldl r0, v1, s0
mul r1.xyz, r0.w, c0
//phase
//texcrd r0.xyz, t1
//texcrd r0.xyz, v2
texldl r0, v2, s2
texldl r1, r1, s1
mul r1, r1, v0
cmp r0.w, -r0.x, c0.w, r1.w
//+ mov r0.xyz, r1
mov r0.xyz, r1
mov oC0, r0
// approximately 6 instruction slots used (3 texture, 3 arithmetic)
[/code]
Using that PS without the vertex shader displays the sprites correctly (at screen depth, of course) and doesn't produce any error. I think this part is right, so the vertex shader must be wrong.
Edit: by the way, does anyone want to download what I have for now?
I could make the effect appear, using once again the vertex shader to pixel shader association ("30E30EF5.txt.ps") (I need to do that for most vertex shaders I'm touching). The "neg substitute" was:
mov r19.w, -r18.w
Sprites are at the correct depth that I wanted.
Using "mov r19.w, r18.w" instead made it appear in a wrong Y position. However, in all cases the reflection sprites are flickering like mad. Something must be wrong in the vs_3_0 conversion (I don't know where yet). The pixel shader conversion I made is correct, for example.
// approximately 6 instruction slots used (3 texture, 3 arithmetic)
Using that PS without the vertex shader displays the sprites correctly (at screen depth, of course) and doesn't produce any error. I think this part is right, so the vertex shader must be wrong.
Edit: by the way, does anyone want to download what I have for now?
Found a very weird issue:
I think it has to do with the HLSL Shader Compiler or something. In short, if I dump this shader in HLSL and don't modify it, it doesn't work properly. Some UI elements are missing.
So, I did some testing:
This is the shader code as HLSL:
[code]
cbuffer cbPerObject : register(b0)
{
row_major float4x4 g_worldViewProj : packoffset(c0);
row_major float4x4 g_world : packoffset(c4);
row_major float4x4 g_worldView : packoffset(c8);
float4 g_uvScrolling : packoffset(c12);
float4 g_texCoordScaleBias : packoffset(c13);
float4 g_boundingSphere : packoffset(c14);
}
cbuffer cbGUI : register(b1)
{
float4 g_elementClipRectangle : packoffset(c0);
float4 g_elementClipCircle : packoffset(c1);
float4 g_elementClipLine1 : packoffset(c2);
float4 g_elementClipLine2 : packoffset(c3);
float4 g_radialClipPosition : packoffset(c4);
float4 g_radialClipGradient : packoffset(c5);
float g_desaturateTextureAmount : packoffset(c6);
float g_globalAlpha : packoffset(c6.y);
float g_globalScale : packoffset(c6.z);
float g_colorDodgeMaxAtLastIteration : packoffset(c6.w);
bool g_isFont : packoffset(c7);
bool g_useClampSampler : packoffset(c7.y);
bool g_isColorDodge : packoffset(c7.z);
bool g_is2D : packoffset(c7.w);
}
// 3Dmigoto declarations
#define cmp -
Texture1D<float4> IniParams : register(t120);
Texture2D<float4> StereoParams : register(t125);
void main(
float3 v0 : POSITION0,
float4 v1 : COLOR0,
float2 v2 : TEXCOORD0,
out float4 o0 : SV_POSITION0,
out float4 o1 : COLOR0,
out float2 o2 : TEXCOORD0,
out float2 p2 : TEXCOORD1)
{
float4 r0;
uint4 bitmask, uiDest;
float4 fDest;
r0.xyzw = g_worldViewProj._m10_m11_m12_m13 * v0.yyyy;
r0.xyzw = v0.xxxx * g_worldViewProj._m00_m01_m02_m03 + r0.xyzw;
r0.xyzw = v0.zzzz * g_worldViewProj._m20_m21_m22_m23 + r0.xyzw;
o0.xyzw = g_worldViewProj._m30_m31_m32_m33 + r0.xyzw;
o1.w = g_globalAlpha * v1.w;
o1.xyz = v1.xyz;
p2.xy = g_isFont ? v0.xy : float2(0,0);
o2.xy = v2.xy;
return;
}
[/code]
And this is the original ASM dumped:
[code]
vs_4_0
dcl_constantbuffer cb0[4], immediateIndexed
dcl_constantbuffer cb1[8], immediateIndexed
dcl_input v0.xyz
dcl_input v1.xyzw
dcl_input v2.xy
dcl_output_siv o0.xyzw, position
dcl_output o1.xyzw
dcl_output o2.xy
dcl_output o2.zw
dcl_temps 1
mul r0.xyzw, v0.yyyy, cb0[1].xyzw
mad r0.xyzw, v0.xxxx, cb0[0].xyzw, r0.xyzw
mad r0.xyzw, v0.zzzz, cb0[2].xyzw, r0.xyzw
add o0.xyzw, r0.xyzw, cb0[3].xyzw
mul o1.w, v1.w, cb1[6].y
mov o1.xyz, v1.xyzx
movc o2.zw, cb1[7].wwww, v0.xxxy, l(0,0,0,0)
mov o2.xy, v2.xyxx
ret
[/code]
The HLSL doesn't work, but the ASM does work!
So I took it to the next level. I tried [color="green"]FXC[/color] on the HLSL to see if I get the same ASM code.
Output from FXC:
[code]
vs_4_0
dcl_constantbuffer CB0[4], immediateIndexed
dcl_constantbuffer CB1[8], immediateIndexed
dcl_input v0.xyz
dcl_input v1.xyzw
dcl_input v2.xy
dcl_output_siv o0.xyzw, position
dcl_output o1.xyzw
dcl_output o2.xy
dcl_output o2.zw
dcl_temps 1
mul r0.xyzw, v0.yyyy, cb0[1].xyzw
mad r0.xyzw, v0.xxxx, cb0[0].xyzw, r0.xyzw
mad r0.xyzw, v0.zzzz, cb0[2].xyzw, r0.xyzw
add o0.xyzw, r0.xyzw, cb0[3].xyzw
mul o1.w, v1.w, cb1[6].y
mov o1.xyz, v1.xyzx
mov o2.xy, v2.xyxx
movc o2.zw, cb1[7].xxxx, v0.xxxy, l(0,0,0,0)
ret
[/code]
Now if I take this ASM block and try to use it, I get exactly what I see with the HLSL code. It doesn't work.
So, I think the decompiler has some issues here or gets confused?
In any case, I fixed my shader by running my code in HLSL and using FXC to get the ASM blocks and put it in the Original ASM code and this fixes the issue.
I wanted to share this around, so other people are aware of this workaround;) (patching ASM shaders from HSL code generated by FXC).
My last shader ASM looks like this:
[code]
vs_4_0
dcl_constantbuffer cb0[4], immediateIndexed
dcl_constantbuffer cb1[8], immediateIndexed
// Add our resources
dcl_resource_texture1d (float,float,float,float) t120
dcl_resource_texture2d (float,float,float,float) t125
dcl_input v0.xyz
dcl_input v1.xyzw
dcl_input v2.xy
dcl_output_siv o0.xyzw, position
dcl_output o1.xyzw
dcl_output o2.xy
dcl_output o2.zw
dcl_temps 4
mul r0.xyzw, v0.yyyy, cb0[1].xyzw
mad r0.xyzw, v0.xxxx, cb0[0].xyzw, r0.xyzw
mad r0.xyzw, v0.zzzz, cb0[2].xyzw, r0.xyzw
// Put the result in r0 instead or writting it directly to oO
//add o0.xyzw, r0.xyzw, cb0[3].xyzw
add r0.xyzw, r0.xyzw, cb0[3].xyzw
// Do our fancy stuff here. Code was obtained using FXC from HLSL
lt r1.xy, l(-0.050000, -0.100000, 0.000000, 0.000000), r0.xyxx
lt r1.zw, r0.xxxy, l(0.000000, 0.000000, 0.050000, 0.100000)
and r1.x, r1.z, r1.x
and r1.x, r1.y, r1.x
and r1.x, r1.w, r1.x
ld r2.xyzw, l(0, 0, 0, 0), t125.xyzw
ld r3.xyzw, l(0, 0, 0, 0), t120.xyzw
mad r1.yz, r2.xxxx, r3.yyxy, r0.xxxx
mov o0.yzw, r0.yyzw
eq r0.x, r3.w, l(1.000000)
movc r0.x, r0.x, r1.y, r1.z
movc o0.x, r1.x, r0.x, r1.z
// Rest of the ASM code is un-changed
mul o1.w, v1.w, cb1[6].y
mov o1.xyz, v1.xyzx
movc o2.zw, cb1[7].wwww, v0.xxxy, l(0,0,0,0)
mov o2.xy, v2.xyxx
ret
[/code]
Hope this might help someone:)
Edit:
For reference, the decompiler/compiler has an issue here:
Original ASM:
[code]
movc o2.zw, cb1[7].wwww, v0.xxxy, l(0,0,0,0)
[/code]
Re-compiled ASM:
[code]
movc o2.zw, cb1[7].xxxx, v0.xxxy, l(0,0,0,0)
[/code]
I think it has to do with the HLSL Shader Compiler or something. In short, if I dump this shader in HLSL and don't modify it, it doesn't work properly. Some UI elements are missing.
Now if I take this ASM block and try to use it, I get exactly what I see with the HLSL code. It doesn't work.
So, I think the decompiler has some issues here or gets confused?
In any case, I fixed my shader by running my code in HLSL and using FXC to get the ASM blocks and put it in the Original ASM code and this fixes the issue.
I wanted to share this around, so other people are aware of this workaround;) (patching ASM shaders from HSL code generated by FXC).
// Rest of the ASM code is un-changed
mul o1.w, v1.w, cb1[6].y
mov o1.xyz, v1.xyzx
movc o2.zw, cb1[7].wwww, v0.xxxy, l(0,0,0,0)
mov o2.xy, v2.xyxx
ret
Hope this might help someone:)
Edit:
For reference, the decompiler/compiler has an issue here:
Original ASM:
movc o2.zw, cb1[7].wwww, v0.xxxy, l(0,0,0,0)
Re-compiled ASM:
movc o2.zw, cb1[7].xxxx, v0.xxxy, l(0,0,0,0)
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
Yep, that is the sort of thing to keep an eye out for with the Decompiler. It's pretty good, but far from flawless. From a computer science perspective, it's a bit of a miracle that it works as well as it does given the flaws. From a ShaderHacker perspective, it has a lot of drawbacks.
The most serious problem I've seen recently is that it can generate code that compiles, but will cause the GPU to hang, causing a TDR driver crash/timeout. This was the problem on both Mirrors Edge and Just Cause 3. I painstakingly hand-fixed the shader in JC3 to understand the problem better, and figured out that it was making an infinite loop because of float to uint conversions. I learned enough to make Decompiler improvements, but won't get time to fix this very soon.
In this case, it mishandled the 'bool' type. It's more solid in the float and float4 types, there are likely to be glitches with any unusual data types.
The best way to determine whether a shader has decompiled properly or not, is to use the F9 'Show original' key. When you are running and the shader is loaded, if you use F9, you can see the image with the original ASM/bin shader. If it changes- the Decompiler created a bad HLSL file.
You can then either use ASM, experiment to see what happened, or ask me to hand-fix the shader. I do the FXC compile all the time and can find and fix most known problems.
This is a new one to me. The actual problem here is the packing of the bool variables. The Decompiler used the wrong variable name.
The actual correct line would be:
[code]p2.xy = g_is2D ? v0.xy : float2(0,0);
[/code]
If you replace that line in the HLSL, I expect you will get identical ASM.
Yep, that is the sort of thing to keep an eye out for with the Decompiler. It's pretty good, but far from flawless. From a computer science perspective, it's a bit of a miracle that it works as well as it does given the flaws. From a ShaderHacker perspective, it has a lot of drawbacks.
The most serious problem I've seen recently is that it can generate code that compiles, but will cause the GPU to hang, causing a TDR driver crash/timeout. This was the problem on both Mirrors Edge and Just Cause 3. I painstakingly hand-fixed the shader in JC3 to understand the problem better, and figured out that it was making an infinite loop because of float to uint conversions. I learned enough to make Decompiler improvements, but won't get time to fix this very soon.
In this case, it mishandled the 'bool' type. It's more solid in the float and float4 types, there are likely to be glitches with any unusual data types.
The best way to determine whether a shader has decompiled properly or not, is to use the F9 'Show original' key. When you are running and the shader is loaded, if you use F9, you can see the image with the original ASM/bin shader. If it changes- the Decompiler created a bad HLSL file.
You can then either use ASM, experiment to see what happened, or ask me to hand-fix the shader. I do the FXC compile all the time and can find and fix most known problems.
This is a new one to me. The actual problem here is the packing of the bool variables. The Decompiler used the wrong variable name.
The actual correct line would be:
p2.xy = g_is2D ? v0.xy : float2(0,0);
If you replace that line in the HLSL, I expect you will get identical ASM.
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 did it (the Blazblue reflections)! There were a few typos I made (that's where the buggy graphics came from), and I had to use "v1" as the "vEXPos" substitute. I'll release the fix on the blog very soon. If anyone is curious, here is the final vertex shader code:
Now that my Blazblue fix is complete, I feel bad not giving HUD depth options. Here is the situation:
Modifying the general HUD vertex shader alone breaks other effects just by existing. So I need to use the ".txt.ps" thing, and "yaay!, it works", but anything other than screen depth modifies the bloom shader position (they use the same pixel shader, lol).
My idea is using texture filtering, which I have done for other games. But this time I need 3 cases inside the shader:
1- HUD textures that will use fixed depth presets with a hotkey.
2- Some textures will need a different depth, the same as the character sprites (Hakumen circle symbols are part of the HUD shader instead of the sprites shader).
3- The "else" case where nothing is modified, to not break bloom.
Can it be done? Using two "[VSnnnnnnnn]" sections for example for the same shader? Although this time I need to use the ".txt.ps" thing and I don't know what CRC I should write.
Another option would be finding the bloom vertex shader and doing a reverse fix, but that doesn't solve the two different depths I need. Besides, this game is very picky about using vertex shaders directly, so it may not work.
I'll try some things tonight (more that 12 hours from now :( ), although I don't have too much time today.
Edit: I wish texture filtering were this easy with 3Dmigoto. I haven't figured it out yet, haha.
Edit 2: I have just seen this wiki for the first time: https://github.com/bo3b/3Dmigoto/wiki
Now that my Blazblue fix is complete, I feel bad not giving HUD depth options. Here is the situation:
Modifying the general HUD vertex shader alone breaks other effects just by existing. So I need to use the ".txt.ps" thing, and "yaay!, it works", but anything other than screen depth modifies the bloom shader position (they use the same pixel shader, lol).
My idea is using texture filtering, which I have done for other games. But this time I need 3 cases inside the shader:
1- HUD textures that will use fixed depth presets with a hotkey.
2- Some textures will need a different depth, the same as the character sprites (Hakumen circle symbols are part of the HUD shader instead of the sprites shader).
3- The "else" case where nothing is modified, to not break bloom.
Can it be done? Using two "[VSnnnnnnnn]" sections for example for the same shader? Although this time I need to use the ".txt.ps" thing and I don't know what CRC I should write.
Another option would be finding the bloom vertex shader and doing a reverse fix, but that doesn't solve the two different depths I need. Besides, this game is very picky about using vertex shaders directly, so it may not work.
I'll try some things tonight (more that 12 hours from now :( ), although I don't have too much time today.
Edit: I wish texture filtering were this easy with 3Dmigoto. I haven't figured it out yet, haha.
I take a look and i think the CS is not the place to correct the lights, but is related to the problematic PS.
There are different PS related to each other...with different VS (according to shaderusage.txt), that's very strange. I need more time to take a look, something else is going on.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
I wanted to see if I could change their position (if I could get a good formula, it would be perfect or almost perfect at any convergence). Buuuuut... there is a problem that bo3b faced in the past:
https://forums.geforce.com/default/topic/513190/3d-vision/how-to-fix-disable-shaders-in-games-dll-guide-and-fixes-/111/
"preshader" code. With screen width and height being used in a constant that gets overwritten later. First I wanted to use some fixed depth with a hotkey. Here is the shader (it was vs_1_1 and had to be converted):
I created c201 to use the resolution I found in the LOG.txt, that refers to the internal resolution, I'm pretty sure of it:
If I use 2560x1440, for example, characters are small and using the top left 1/4 of the screen. So I think I got it right, although some main meny elements disappeared.
When I enter a battle, the characters are showing, but when I jump, for example, they (and other post processing effects, which should be unrelated!) disappear until my character is on the ground again.
The shader doesn't give any errors in the log, but the hotkey I made for the depth doesn't work. I tried the same for the HUD and it also didn't work (it has the same preshader problem).
Has any solution for this been found since 2013? If not, I'll just lock the convergence to what is needed (but I would like to see the characters at some depth :( ).
Edit: untouched vs_3_0 shader:
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king
I said "With a convergence adjustment, they can be lined to their supposed position.". So yes, I already know ow to use the correct convergence. I just wanted to try changing the character depth to properly align it at all convergence settings. At least "more or less".
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
I take it you're passing in a constant on register c235? You sure that's not in conflict with a register already in use by another shader? Have you tried using just a local constant, like the ones provided in c5 maybe (just to see if they work)?
Honestly, for me I find Helixmod too tempermental and unstable these days. I've tried doing very basic fixes (halo's, etc) that I can do with my eyes closed when working with DX11/3DMigoto, but do weird things in Helixmod (like shifting both eyes in the same direction), so I wouldn't put it past you having done the right thing but being caught up on some weird 'gotcha'
3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot
Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king
I tried commenting all code concerning that constant (also in DX9Settings.ini), and the result was the same. The problem isn't there.
Fake edit: Heyyy, I know what happens!!! Another vertex shader has the same CRC (actually at least 4 vertex shaders are using the same CRC)! So when it appears on screen, bam! Conflict.
Edit: I'll follow the "Overriding an Individual Instance of a Shader" section of the Helixmod feture list and report back.
Edit 2: I could manually convert its pixel shader to ps_3_0 and then put the "9A8ED0D6.txt.ps" name to the vertex shader. Now it's displaying correctly, without log or visual errors. My depth hotkey isn't working, so it's what I'll be modifying now. Let's see if I can.
Edit 3: static (without hotkey) depth works! Now I'll try to make a good formula.
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
Intel Core i7-3820, 4 X 3,60 GHz overclocked to 4,50 GHz ; EVGA Titan X 12VRAM ; 16 GB Corsair Vengeance DDR-1600 (4x 4 GB) ; Asus VG278H 27-inch incl. 3D vision 2 glasses, integrated transmitter ; Xbox One Elite wireless controller ; Windows 10HTC VIVE 2,5 m2 roomscale3D VISION GAMERS - VISIT ME ON STEAM and feel free to add me: http://steamcommunity.com/profiles/76561198064106555 YOUTUBE: https://www.youtube.com/channel/UC1UE5TPoF0HX0HVpF_E4uPQ STEAM CURATOR: https://store.steampowered.com/curator/33611530-Streaming-Deluxe/
It will take a bit more time to fix character reflections (they disappeared in the screenshot because the shader is incomplete) because the preshader code is 8 lines long, but I know what to do.
After that, a bit of testing and maybe changing the HUD, it will be release time!
When the other Blazblue games are on sale (at a fair price), I'll buy them and fix them too.
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
All was going fine until I found that. I can't find it in the Microsoft MSDN documentation (not here https://msdn.microsoft.com/es-es/library/windows/desktop/bb172936(v=vs.85).aspx nor here https://msdn.microsoft.com/es-es/library/windows/desktop/bb172938(v=vs.85).aspx).
Things I've tried that didn't work, because I don't know what's the equivalent:
Obviously the first one produced an error, and the other two made the effect disappear at all convergence and separation settings. Help :(.
Entire shader (4381AEA6.txt). Se line 104:
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
I took a quick look, and I don't think that is a legitimate instruction. It's also not an intrinsic of any form, it's just a weird disassembler bug. There is an instruction 'ineg' for an integer negate, but that's only in SM4 and above.
For this one, we'll just have to guess what was intended. I think that your 'mov r19.w, -r18.w' is right. That doesn't have any constant register (read-only) problems, and should be right.
Since it doesn't work, that suggests something else is going wrong.
The problem with preshaders is that they have access to data that we do not have at shader time itself.
In the example I looked at earlier (Fear), the clouds were moved by a preshader, and those values were never available later. So in vs_3_0 without preshaders, there was no way to make the clouds move, because the original state was unavailable.
It would maybe be possible to do something really heroic like saving a cloud state in a HelixMod variable, but there's not a lot of incentive for a smallish effect.
For this example, my best guess is that there is constant state information that is now unchanging once the preshader is no longer running. In particular, we don't have any idea what the vEXPos does, or how it should change.
Best bet is to try to get a feel for what the effect is supposed to be doing, and maybe work out an alternate approach. In the Fear example, I just set the clouds to a fixed location.
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
Sprites are at the correct depth that I wanted.
Using "mov r19.w, r18.w" instead made it appear in a wrong Y position. However, in all cases the reflection sprites are flickering like mad. Something must be wrong in the vs_3_0 conversion (I don't know where yet). The pixel shader conversion I made is correct, for example.
Original PS:
Converted:
Using that PS without the vertex shader displays the sprites correctly (at screen depth, of course) and doesn't produce any error. I think this part is right, so the vertex shader must be wrong.
Edit: by the way, does anyone want to download what I have for now?
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
I think it has to do with the HLSL Shader Compiler or something. In short, if I dump this shader in HLSL and don't modify it, it doesn't work properly. Some UI elements are missing.
So, I did some testing:
This is the shader code as HLSL:
And this is the original ASM dumped:
The HLSL doesn't work, but the ASM does work!
So I took it to the next level. I tried FXC on the HLSL to see if I get the same ASM code.
Output from FXC:
Now if I take this ASM block and try to use it, I get exactly what I see with the HLSL code. It doesn't work.
So, I think the decompiler has some issues here or gets confused?
In any case, I fixed my shader by running my code in HLSL and using FXC to get the ASM blocks and put it in the Original ASM code and this fixes the issue.
I wanted to share this around, so other people are aware of this workaround;) (patching ASM shaders from HSL code generated by FXC).
My last shader ASM looks like this:
Hope this might help someone:)
Edit:
For reference, the decompiler/compiler has an issue here:
Original ASM:
Re-compiled ASM:
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)
The most serious problem I've seen recently is that it can generate code that compiles, but will cause the GPU to hang, causing a TDR driver crash/timeout. This was the problem on both Mirrors Edge and Just Cause 3. I painstakingly hand-fixed the shader in JC3 to understand the problem better, and figured out that it was making an infinite loop because of float to uint conversions. I learned enough to make Decompiler improvements, but won't get time to fix this very soon.
In this case, it mishandled the 'bool' type. It's more solid in the float and float4 types, there are likely to be glitches with any unusual data types.
The best way to determine whether a shader has decompiled properly or not, is to use the F9 'Show original' key. When you are running and the shader is loaded, if you use F9, you can see the image with the original ASM/bin shader. If it changes- the Decompiler created a bad HLSL file.
You can then either use ASM, experiment to see what happened, or ask me to hand-fix the shader. I do the FXC compile all the time and can find and fix most known problems.
This is a new one to me. The actual problem here is the packing of the bool variables. The Decompiler used the wrong variable name.
The actual correct line would be:
If you replace that line in the HLSL, I expect you will get identical ASM.
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
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
Modifying the general HUD vertex shader alone breaks other effects just by existing. So I need to use the ".txt.ps" thing, and "yaay!, it works", but anything other than screen depth modifies the bloom shader position (they use the same pixel shader, lol).
My idea is using texture filtering, which I have done for other games. But this time I need 3 cases inside the shader:
1- HUD textures that will use fixed depth presets with a hotkey.
2- Some textures will need a different depth, the same as the character sprites (Hakumen circle symbols are part of the HUD shader instead of the sprites shader).
3- The "else" case where nothing is modified, to not break bloom.
Can it be done? Using two "[VSnnnnnnnn]" sections for example for the same shader? Although this time I need to use the ".txt.ps" thing and I don't know what CRC I should write.
Another option would be finding the bloom vertex shader and doing a reverse fix, but that doesn't solve the two different depths I need. Besides, this game is very picky about using vertex shaders directly, so it may not work.
I'll try some things tonight (more that 12 hours from now :( ), although I don't have too much time today.
Edit: I wish texture filtering were this easy with 3Dmigoto. I haven't figured it out yet, haha.
Edit 2: I have just seen this wiki for the first time: https://github.com/bo3b/3Dmigoto/wiki
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com