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?
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.
[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.
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
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
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:
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:
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.
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