Shader fixes for beginners
I have currently dumped a shader which made the crosshair disappear in Titanfall. [code]// // Generated by Microsoft (R) HLSL Shader Compiler 9.30.9200.16384 // // // Buffer Definitions: // // cbuffer CBufCommonPerCamera // { // // float3 c_cameraOrigin; // Offset: 0 Size: 12 [unused] // float c_zNear; // Offset: 12 Size: 4 [unused] // row_major float4x4 c_cameraRelativeToClip;// Offset: 16 Size: 64 // float4 c_clipPlane; // Offset: 80 Size: 16 [unused] // // struct // { // // float4 k0; // Offset: 96 // float4 k1; // Offset: 112 // float4 k2; // Offset: 128 // float4 k3; // Offset: 144 // float4 k4; // Offset: 160 // // } c_fogParams; // Offset: 96 Size: 80 [unused] // float3 c_skyColor; // Offset: 176 Size: 12 [unused] // float c_shadowBleedFudge; // Offset: 188 Size: 4 [unused] // float c_envMapLightScale; // Offset: 192 Size: 4 [unused] // float3 c_sunColor; // Offset: 196 Size: 12 [unused] // float3 c_sunDir; // Offset: 208 Size: 12 [unused] // float c_gameTime; // Offset: 220 Size: 4 [unused] // // struct // { // // float3 shadowRelConst; // Offset: 224 // float unused_0; // Offset: 236 // float3 shadowRelForX; // Offset: 240 // float unused_1; // Offset: 252 // float3 shadowRelForY; // Offset: 256 // float cascadeWeightScale; // Offset: 268 // float3 shadowRelForZ; // Offset: 272 // float cascadeWeightBias; // Offset: 284 // float4 laterCascadeScale; // Offset: 288 // float4 laterCascadeBias; // Offset: 304 // float2 normToAtlasCoordsScale0;// Offset: 320 // float2 normToAtlasCoordsBias0; // Offset: 328 // float4 normToAtlasCoordsScale12;// Offset: 336 // float4 normToAtlasCoordsBias12;// Offset: 352 // // } c_csm; // Offset: 224 Size: 144 [unused] // uint c_lightTilesX; // Offset: 368 Size: 4 [unused] // float c_minShadowVariance; // Offset: 372 Size: 4 [unused] // float2 c_renderTargetSize; // Offset: 376 Size: 8 [unused] // float2 c_rcpRenderTargetSize; // Offset: 384 Size: 8 [unused] // float c_numCoverageSamples; // Offset: 392 Size: 4 [unused] // float c_rcpNumCoverageSamples; // Offset: 396 Size: 4 [unused] // float c_rimLightRangeScale; // Offset: 400 Size: 4 [unused] // float c_rimLightRangeBias; // Offset: 404 Size: 4 [unused] // float c_rimLightFalloffScale; // Offset: 408 Size: 4 [unused] // float c_rimLightFalloffBias; // Offset: 412 Size: 4 [unused] // float2 c_cloudRelConst; // Offset: 416 Size: 8 [unused] // float2 c_cloudRelForX; // Offset: 424 Size: 8 [unused] // float2 c_cloudRelForY; // Offset: 432 Size: 8 [unused] // float2 c_cloudRelForZ; // Offset: 440 Size: 8 [unused] // // } // // cbuffer CBufModelInstance // { // // struct // { // // row_major float3x4 objectToCameraRelative;// Offset: 0 // float4 diffuseModulation; // Offset: 48 // // struct // { // // float4 ambientSH[3]; // Offset: 64 // float4 skyDirSunVis; // Offset: 112 // uint4 packedLightData; // Offset: 128 // // } lighting; // Offset: 64 // // } c_modelInst; // Offset: 0 Size: 144 // // } // // // Resource Bindings: // // Name Type Format Dim Slot Elements // ------------------------------ ---------- ------- ----------- ---- -------- // CBufCommonPerCamera cbuffer NA NA 2 1 // CBufModelInstance cbuffer NA NA 3 1 // // // // Input signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // POSITION 0 xyz 0 NONE float xyz // COLOR 0 xyzw 1 NONE float xyzw // TEXCOORD 0 xy 2 NONE float xy // // // Output signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // COLOR 0 xyzw 0 NONE float xyzw // TEXCOORD 0 xy 1 NONE float xy // TEXCOORD 1 xyz 2 NONE float xyz // SV_POSITION 0 xyzw 3 POS float xyzw // [/code] [code] vs_4_0 dcl_constantbuffer cb2[5], immediateIndexed dcl_constantbuffer cb3[4], immediateIndexed // current changes dcl_sampler s15, mode_default dcl_resource_texture2d (float,float,float,float) t125 //sample(texture2d)(float,float,float,float) r4.xyzw, l(0.0625, 0.0625, 0.0625, 0.0625), t125.xyzw, s15 // current Changes end dcl_input v0.xyz dcl_input v1.xyzw dcl_input v2.xy dcl_output o0.xyzw dcl_output o1.xy dcl_output o2.xyz dcl_output_siv o3.xyzw, position dcl_temps 1 log r0.xyz, |v1.xyzx| mul r0.xyz, r0.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000) exp r0.xyz, r0.xyzx mul o0.xyz, r0.xyzx, cb3[3].xyzx mul o0.w, v1.w, cb3[3].w mov o1.xy, v2.xyxx dp3 r0.x, v0.xyzx, cb3[0].xyzx add r0.x, r0.x, cb3[0].w dp3 r0.w, v0.xyzx, cb3[1].xyzx add r0.y, r0.w, cb3[1].w dp3 r0.w, v0.xyzx, cb3[2].xyzx add r0.z, r0.w, cb3[2].w mov o2.xyz, r0.xyzx dp3 r0.w, r0.xyzx, cb2[1].xyzx add o3.x, r0.w, cb2[1].w dp3 r0.w, r0.xyzx, cb2[2].xyzx add o3.y, r0.w, cb2[2].w dp3 r0.w, r0.xyzx, cb2[3].xyzx dp3 r0.x, r0.xyzx, cb2[4].xyzx add o3.w, r0.x, cb2[4].w add o3.z, r0.w, cb2[3].w ret // Approximately 22 instruction slots used [/code] Output signature tells me that o3 is SV_POSITION which should be altered if I understand this correctly. If this was less new to me I could probably show the final fix but I will need to fix it first Before that is possible. As I'm a beginner this should be good enough as a starting Point.
I have currently dumped a shader which made the crosshair disappear in Titanfall.

//
// Generated by Microsoft (R) HLSL Shader Compiler 9.30.9200.16384
//
//
// Buffer Definitions:
//
// cbuffer CBufCommonPerCamera
// {
//
// float3 c_cameraOrigin; // Offset: 0 Size: 12 [unused]
// float c_zNear; // Offset: 12 Size: 4 [unused]
// row_major float4x4 c_cameraRelativeToClip;// Offset: 16 Size: 64
// float4 c_clipPlane; // Offset: 80 Size: 16 [unused]
//
// struct
// {
//
// float4 k0; // Offset: 96
// float4 k1; // Offset: 112
// float4 k2; // Offset: 128
// float4 k3; // Offset: 144
// float4 k4; // Offset: 160
//
// } c_fogParams; // Offset: 96 Size: 80 [unused]
// float3 c_skyColor; // Offset: 176 Size: 12 [unused]
// float c_shadowBleedFudge; // Offset: 188 Size: 4 [unused]
// float c_envMapLightScale; // Offset: 192 Size: 4 [unused]
// float3 c_sunColor; // Offset: 196 Size: 12 [unused]
// float3 c_sunDir; // Offset: 208 Size: 12 [unused]
// float c_gameTime; // Offset: 220 Size: 4 [unused]
//
// struct
// {
//
// float3 shadowRelConst; // Offset: 224
// float unused_0; // Offset: 236
// float3 shadowRelForX; // Offset: 240
// float unused_1; // Offset: 252
// float3 shadowRelForY; // Offset: 256
// float cascadeWeightScale; // Offset: 268
// float3 shadowRelForZ; // Offset: 272
// float cascadeWeightBias; // Offset: 284
// float4 laterCascadeScale; // Offset: 288
// float4 laterCascadeBias; // Offset: 304
// float2 normToAtlasCoordsScale0;// Offset: 320
// float2 normToAtlasCoordsBias0; // Offset: 328
// float4 normToAtlasCoordsScale12;// Offset: 336
// float4 normToAtlasCoordsBias12;// Offset: 352
//
// } c_csm; // Offset: 224 Size: 144 [unused]
// uint c_lightTilesX; // Offset: 368 Size: 4 [unused]
// float c_minShadowVariance; // Offset: 372 Size: 4 [unused]
// float2 c_renderTargetSize; // Offset: 376 Size: 8 [unused]
// float2 c_rcpRenderTargetSize; // Offset: 384 Size: 8 [unused]
// float c_numCoverageSamples; // Offset: 392 Size: 4 [unused]
// float c_rcpNumCoverageSamples; // Offset: 396 Size: 4 [unused]
// float c_rimLightRangeScale; // Offset: 400 Size: 4 [unused]
// float c_rimLightRangeBias; // Offset: 404 Size: 4 [unused]
// float c_rimLightFalloffScale; // Offset: 408 Size: 4 [unused]
// float c_rimLightFalloffBias; // Offset: 412 Size: 4 [unused]
// float2 c_cloudRelConst; // Offset: 416 Size: 8 [unused]
// float2 c_cloudRelForX; // Offset: 424 Size: 8 [unused]
// float2 c_cloudRelForY; // Offset: 432 Size: 8 [unused]
// float2 c_cloudRelForZ; // Offset: 440 Size: 8 [unused]
//
// }
//
// cbuffer CBufModelInstance
// {
//
// struct
// {
//
// row_major float3x4 objectToCameraRelative;// Offset: 0
// float4 diffuseModulation; // Offset: 48
//
// struct
// {
//
// float4 ambientSH[3]; // Offset: 64
// float4 skyDirSunVis; // Offset: 112
// uint4 packedLightData; // Offset: 128
//
// } lighting; // Offset: 64
//
// } c_modelInst; // Offset: 0 Size: 144
//
// }
//
//
// Resource Bindings:
//
// Name Type Format Dim Slot Elements
// ------------------------------ ---------- ------- ----------- ---- --------
// CBufCommonPerCamera cbuffer NA NA 2 1
// CBufModelInstance cbuffer NA NA 3 1
//
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// POSITION 0 xyz 0 NONE float xyz
// COLOR 0 xyzw 1 NONE float xyzw
// TEXCOORD 0 xy 2 NONE float xy
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// COLOR 0 xyzw 0 NONE float xyzw
// TEXCOORD 0 xy 1 NONE float xy
// TEXCOORD 1 xyz 2 NONE float xyz
// SV_POSITION 0 xyzw 3 POS float xyzw
//

vs_4_0
dcl_constantbuffer cb2[5], immediateIndexed
dcl_constantbuffer cb3[4], immediateIndexed
// current changes
dcl_sampler s15, mode_default
dcl_resource_texture2d (float,float,float,float) t125
//sample(texture2d)(float,float,float,float) r4.xyzw, l(0.0625, 0.0625, 0.0625, 0.0625), t125.xyzw, s15
// current Changes end
dcl_input v0.xyz
dcl_input v1.xyzw
dcl_input v2.xy
dcl_output o0.xyzw
dcl_output o1.xy
dcl_output o2.xyz
dcl_output_siv o3.xyzw, position
dcl_temps 1
log r0.xyz, |v1.xyzx|
mul r0.xyz, r0.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
exp r0.xyz, r0.xyzx
mul o0.xyz, r0.xyzx, cb3[3].xyzx
mul o0.w, v1.w, cb3[3].w
mov o1.xy, v2.xyxx
dp3 r0.x, v0.xyzx, cb3[0].xyzx
add r0.x, r0.x, cb3[0].w
dp3 r0.w, v0.xyzx, cb3[1].xyzx
add r0.y, r0.w, cb3[1].w
dp3 r0.w, v0.xyzx, cb3[2].xyzx
add r0.z, r0.w, cb3[2].w
mov o2.xyz, r0.xyzx
dp3 r0.w, r0.xyzx, cb2[1].xyzx
add o3.x, r0.w, cb2[1].w
dp3 r0.w, r0.xyzx, cb2[2].xyzx
add o3.y, r0.w, cb2[2].w
dp3 r0.w, r0.xyzx, cb2[3].xyzx
dp3 r0.x, r0.xyzx, cb2[4].xyzx
add o3.w, r0.x, cb2[4].w
add o3.z, r0.w, cb2[3].w
ret
// Approximately 22 instruction slots used


Output signature tells me that o3 is SV_POSITION which should be altered if I understand this correctly. If this was less new to me I could probably show the final fix but I will need to fix it first Before that is possible. As I'm a beginner this should be good enough as a starting Point.

Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?

donations: ulfjalmbrant@hotmail.com

#1
Posted 08/01/2014 08:24 AM   
I am very fluent in hardware, been building PC's for over 15 year's, but on the other side of the stream: Coding.. not so much.. Oh I can install the shit out of windows and tweak it out, specialty software, CAD's and Photoshop, no problem.. BUT, When I look at the above shader dumps.. Well, let's just say I feel a bit like 'Neo' must have felt when he gazed upon "The Matrix" code for the first time. That said, I am trying to learn this bit by bit and in that process I had a thought - maybe it's possible to program an app like 'Cheat Engine' that has a built in, hands-on tutorial system. The tutorial could be broken up into levels of difficulty, or by the varying types of shaders & game engines that access them, or even both. For those of you that don't know "Cheat Engine," google it up and run the app, the tutorial is triggered upon start and walks you right through using actual exe's and dll's. It's pretty choice and have learned ALOT via that app! Anyway, nice job on the dump, looking at it more carefully I can make out what must be coordinates and the very first three digits are the various types of files or simply part of the address where the shader is needed and when? Well, Rome wasn't built in a day right? I hope to have something usable soon myself, but haven't been able to wade through the tut's and files as much as I would have liked, but I have some more time coming up to dabble. My overall goal is to be able to specialize in 'Unity Engine' fixes - SOOO Many good games run on the 'UE' and nearly ALL (if not, all)are broken. They are broken, collectively, in nearly identical ways, lighting & Halos mostly with some shadow issues mixed in for good measure. Well, Good luck with your fix! ~Nutz
I am very fluent in hardware, been building PC's for over 15 year's, but on the other side of the stream: Coding.. not so much..

Oh I can install the shit out of windows and tweak it out, specialty software, CAD's and Photoshop, no problem..

BUT, When I look at the above shader dumps.. Well, let's just say I feel a bit like 'Neo' must have felt when he gazed upon "The Matrix" code for the first time.

That said, I am trying to learn this bit by bit and in that process I had a thought - maybe it's possible to program an app like 'Cheat Engine' that has a built in, hands-on tutorial system.

The tutorial could be broken up into levels of difficulty, or by the varying types of shaders & game engines that access them, or even both.

For those of you that don't know "Cheat Engine," google it up and run the app, the tutorial is triggered upon start and walks you right through using actual exe's and dll's. It's pretty choice and have learned ALOT via that app!

Anyway, nice job on the dump, looking at it more carefully I can make out what must be coordinates and the very first three digits are the various types of files or simply part of the address where the shader is needed and when?

Well, Rome wasn't built in a day right? I hope to have something usable soon myself, but haven't been able to wade through the tut's and files as much as I would have liked, but I have some more time coming up to dabble.

My overall goal is to be able to specialize in 'Unity Engine' fixes - SOOO Many good games run on the 'UE' and nearly ALL (if not, all)are broken. They are broken, collectively, in nearly identical ways, lighting & Halos mostly with some shadow issues mixed in for good measure.

Well, Good luck with your fix!

~Nutz

---- Core System Components ----

(MBD) EVGA® Classified™ (x58) E760
(CPU) Intel® i7™ '980x' (OC'd) @ 4.8Ghz
(CPU) Corsair® (CPU) Cooling™ (H50)
(MEM) Corsair® (MEM) Dominator(GT)™ 12GB @ 2000Mhz
(PSU) PC)P&C™ (PSU)'T12W' @ 1200w
(CSE) Cooler Master® Stacker™ (830)

---- (3D) Graphics Sub'Sys ----

(2x) EVGA® GTX'970 (SC) - Nvidia® SLi™
(1x) EVGA® GTX'660 (Ti) - Nvidia® PhysX™

(1x) ACER® (GN) 246(HL) - Nvidia® 3DVision™
(1x) ASUS® (VG) 248(QE) - Nvidia® 3DVision™
(1x) ACER® (GN) 246(HL) - Nvidia® 3DVision™

---- Audio & System Control ----

(1x) ASUS® - Xonar™ (HDAV1.3)
(1x) VL'Sys® - MPlay202+ 'GUI' & (RF) Remote

---- Storage (HDD's) & Media (ODD's) PB & REC ----

(1x) (SSD) Samsung® - 850(PRO) '3D'Vertical™
(1x) (2TB) Seagate® - Hybrid Series™
(4x) (2TB) W.Digital® - 'Blacks'™
(2x) (ODD) LG® BluRay™ - 'Play'n'Burn'

---- Nvidia® (WHQL) Drivers (x64) In Use ----

(NV®)DR - v347.88 (WHQL) - Primary (GTA V)
(NV®)DR - v350.12 (WHQL) - Testing (Stable)
(NV®)DR - v353.06 (WHQL) - All Other Titles

#2
Posted 08/01/2014 06:59 PM   
[quote="Flugan"]Output signature tells me that o3 is SV_POSITION which should be altered if I understand this correctly. If this was less new to me I could probably show the final fix but I will need to fix it first Before that is possible. As I'm a beginner this should be good enough as a starting Point.[/quote] Just a note for other people following along- this is DX11 code, not DX9 code, so some of the names change. The basic strategies are still true for both. The main difference here is this is Shader Model 4.0 as noted by the vs_4_0 which means VertexShader 4.0. For DX9 games, we almost always use Shader Model 3.0 with vs_3_0 and ps_3_0. For this shader, Flugan is correct, the o3 is the SV_POSITION, and is the position of the vertex in the 3D space. Generally speaking we will want to modify this position, but sometimes we want to do textures instead. We also have o1, an unknown texcoord, with only x,y, which probably has something to do with the final location on the x,y monitor output. And, o2, an unknown texcoord, with x,y,z. Probably the texture for the actual crosshair. o0 is the color from the vertex shader, and it's super rare to care about it. For experimenting, comment out the o2, and see what the result is. Then put it back and comment out o1, and see the result. Then put it back and comment out o3, which should make it disappear. For example: [code]// mov o2.xyz, r0.xyzx[/code] This can give you an idea of what the pieces are used for, and which one to target. Note that there are often multiple lines that need to be commented out to completely erase an output. We don't have any experience with commenting these out in ShaderModel4, so it's not guaranteed this will work. In SM3, we could do this without trouble. In HLSL I usually set the output to zero instead of comment it out, because it generates warnings otherwise. To set to zero, you should be able to do: [code]// mov o2.xyz, r0.xyzx mov o2.xyz, l(0, 0, 0, 0)[/code] If you set o3, the SV_POSITION to zero, that should make the crosshair disappear. Which is at least a first level fix, and good for people like me who like to do my own aiming. [code]// add o3.x, r0.w, cb2[1].w dp3 r0.w, r0.xyzx, cb2[2].xyzx // add o3.y, r0.w, cb2[2].w dp3 r0.w, r0.xyzx, cb2[3].xyzx dp3 r0.x, r0.xyzx, cb2[4].xyzx // add o3.w, r0.x, cb2[4].w // add o3.z, r0.w, cb2[3].w mov o3.xyzw, l(0, 0, 0, 0)[/code] Please experiment with some of those and let us know.
Flugan said:Output signature tells me that o3 is SV_POSITION which should be altered if I understand this correctly. If this was less new to me I could probably show the final fix but I will need to fix it first Before that is possible. As I'm a beginner this should be good enough as a starting Point.

Just a note for other people following along- this is DX11 code, not DX9 code, so some of the names change. The basic strategies are still true for both.

The main difference here is this is Shader Model 4.0 as noted by the vs_4_0 which means VertexShader 4.0.

For DX9 games, we almost always use Shader Model 3.0 with vs_3_0 and ps_3_0.


For this shader, Flugan is correct, the o3 is the SV_POSITION, and is the position of the vertex in the 3D space. Generally speaking we will want to modify this position, but sometimes we want to do textures instead.

We also have o1, an unknown texcoord, with only x,y, which probably has something to do with the final location on the x,y monitor output.

And, o2, an unknown texcoord, with x,y,z. Probably the texture for the actual crosshair.
o0 is the color from the vertex shader, and it's super rare to care about it.


For experimenting, comment out the o2, and see what the result is. Then put it back and comment out o1, and see the result. Then put it back and comment out o3, which should make it disappear.

For example:

// mov o2.xyz, r0.xyzx


This can give you an idea of what the pieces are used for, and which one to target. Note that there are often multiple lines that need to be commented out to completely erase an output.


We don't have any experience with commenting these out in ShaderModel4, so it's not guaranteed this will work. In SM3, we could do this without trouble. In HLSL I usually set the output to zero instead of comment it out, because it generates warnings otherwise.

To set to zero, you should be able to do:

// mov o2.xyz, r0.xyzx
mov o2.xyz, l(0, 0, 0, 0)



If you set o3, the SV_POSITION to zero, that should make the crosshair disappear. Which is at least a first level fix, and good for people like me who like to do my own aiming.

// add o3.x, r0.w, cb2[1].w
dp3 r0.w, r0.xyzx, cb2[2].xyzx
// add o3.y, r0.w, cb2[2].w
dp3 r0.w, r0.xyzx, cb2[3].xyzx
dp3 r0.x, r0.xyzx, cb2[4].xyzx
// add o3.w, r0.x, cb2[4].w
// add o3.z, r0.w, cb2[3].w

mov o3.xyzw, l(0, 0, 0, 0)



Please experiment with some of those and let us know.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

#3
Posted 08/03/2014 06:42 AM   
Scroll To Top