HLSL Non-Normalized tex coords in pixel shader Hi guys I am having a rather odd pixel shader problem. I have attempted to implement a simple horizontal hatch brush pattern using the y dimension of a 2D quad, where it alternates colors every 4 pixels. It works in my C# test app, but not in my C++ project. Here is my shader code: struct PS_INPUT { float4 p : SV_POSITION; float2 t : TEXCOORD0; float2 tc : TEXCOORD1; }; float4 PS_FILL(PS_INPUT input) : SV_Target { if (fclip != 0) { float clip = ClipTex.SampleLevel(Sample, input.tc, 0); if (clip == 0.0f) discard; } if (brushtype.x == 1) return color1; else { if (brushtype.y == 100) { if (fmod(input.t.y, 8) <= 4.0f)//Fault is here return color1; else return color2; } else return color2; } } When the quad is passed to the pixel shader, I put actual normalized texture coordinates in the tc member of PS_INPUT, which are used for sampling a mask texture for clip regions. The t member however, gets the actual dimensions of the quad in pixels. So for the top left quad t would be 0,0, while the bottom right quad would have width, height in t. Below is a screenshot where you can see the C# app's output. As you can see, the alternating color pattern is clearly working in the brown half of the attitude indicator display. Here is my C++ program's output: Now I must stress that the 2 programs are using functionally identical code, as well as completely identical shader code. I also ran the VS2017 graphics debugger on my program to check the values going into PS_INPUT::t in my geometry shader, and I saw the expected pixel dimensions. But when I check the pixel shader, it tells me that input.t.y's debug info has been optimized away, even though I explicitly disabled optimization and enabled shader debugging during shader compilation. So I tried storing input.t.y into a local variable, which consistently showed a value of 0.5 no matter which pixel I selected for debugging. So for some reason DX11 is either normalizing my TEXCOORD inputs, or it is not linearly interpolating in the area between the vertex positions of the quad. Any ideas? https://ift.tt/eA8V8J

Hi guys I am having a rather odd pixel shader problem. I have attempted to implement a simple horizontal hatch brush pattern using the y dimension of a 2D quad, where it alternates colors every 4 pixels. It works in my C# test app, but not in my C++ project. Here is my shader code: struct PS_INPUT { float4 p : SV_POSITION; float2 t : TEXCOORD0; float2 tc : TEXCOORD1; }; float4 PS_FILL(PS_INPUT input) : SV_Target { if (fclip != 0) { float clip = ClipTex.SampleLevel(Sample, input.tc, 0); if (clip == 0.0f) discard; } if (brushtype.x == 1) return color1; else { if (brushtype.y == 100) { if (fmod(input.t.y, 8) <= 4.0f)//Fault is here return color1; else return color2; } else return color2; } } When the quad is passed to the pixel shader, I put actual normalized texture coordinates in the tc member of PS_INPUT, which are used for sampling a mask texture for clip regions. The t member however, gets the actual dimensions of the quad in pixels. So for the top left quad t would be 0,0, while the bottom right quad would have width, height in t. Below is a screenshot where you can see the C# app's output. As you can see, the alternating color pattern is clearly working in the brown half of the attitude indicator display. Here is my C++ program's output: Now I must stress that the 2 programs are using functionally identical code, as well as completely identical shader code. I also ran the VS2017 graphics debugger on my program to check the values going into PS_INPUT::t in my geometry shader, and I saw the expected pixel dimensions. But when I check the pixel shader, it tells me that input.t.y's debug info has been optimized away, even though I explicitly disabled optimization and enabled shader debugging during shader compilation. So I tried storing input.t.y into a local variable, which consistently showed a value of 0.5 no matter which pixel I selected for debugging. So for some reason DX11 is either normalizing my TEXCOORD inputs, or it is not linearly interpolating in the area between the vertex positions of the quad. Any ideas?

from GameDev.net http://bit.ly/30iJyz8