In D3D9 (and by extension, XNA) there's an annoying little issue regarding pixel coordinates and texel coordinates...it's described in full here.  If you want the short version, it's basically this: your vertex coordinates need to be offset by half a pixel for a full-screen quad to line up right.  I usually apply the offset in the shader so that I can just keep quad vertex buffer for a ll RenderTarget sizes, like this:

void PostProcessVS (    in float3 in_vPositionOS        : POSITION,
                        in float2 in_vTexCoord            : TEXCOORD0,                    
                        out float4 out_vPositionCS        : POSITION,
                        out float2 out_vTexCoord        : TEXCOORD0
                   )
{
    out_vPositionCS.x = in_vPositionOS.x - (1.0f / g_vDestinationDimensions.x);
    out_vPositionCS.y = in_vPositionOS.y + (1.0f / g_vDestinationDimensions.y);
    out_vPositionCS.z = in_vPositionOS.z;
    out_vPositionCS.w = 1.0f;
    out_vTexCoord = in_vTexCoord;
}   

But of course you could apply the offset directly in your vertex coordinates, if you wish.  Just remember that you'll need to change the offset depending on the size of the RenderTarget you're rendering to.

In addition to the half pixel offset, you should be aware that your texture coordinates will never go all the way up to 1 at the right or bottom of your image. Polygon filling is exclusive of the right and bottom edges, not inclusive (if it was inclusive, connected meshes of multiple triangles would not join up contiguously).

For instance if you drew a 4x1 texture onto a 4x1 sprite positioned with the top left at -0.5,-0.5, the four pixels rendered will be:

   0,0 - texcoord 0
   1,0 - texcoord 0.25
   2,0 - texcoord 0.5
   3,0 - texcoord 0.75

Hello to you both,

Despite the above about half pixel centres, there was a big discussion about this on the DX mailing list and the output wisdom from that was that it works better if you apply 0.35 instead of 0.5 as your pixel offset. Nobody really explained why this should be, but I can verify it worked for me when doing similar tasks to yours. Maybe give it a try?

The 0.35 value is there to compensate for various buggy drivers and non-conforming implementations, and is generally only to be used when you use POINT filtering, for 1:1 texture:screen application (GUIs and the like).
When doing filtering, you should use the 0.5 texel offset, and if the user is using a bad driver, it will look slightly off, but that's OK.

Hi there, Jon.

I was just floating ideas as he still clearly has a problem.

I take your point about the 0.35 not being intended as a universal salve, but ime that's exactly what it has become. I had occasional problems with 0.5 across the board of usages, but since that discussion I've used 0.35 across the board and have never seen a problem since in anything. Which is good :)

It's important to understand that the 0.35 thing only works if you are using point sampling.

If you want exact equality of texture coordinates with a specific value that you are going to test in the shader (like in this example where he is explicitly testing for texcoords being exactly zero) then any variation in the rasterization behavior will make this test fail. It's only going to work if your code exactly matches what the driver and hardware is doing, which means using an exact 0.5 offset (as that is what the spec says and what most cards provide most of the time), and just living with the fact that this code will fail on buggy hardware/drivers that do something slightly different, or on implementations that have unusually poor numeric precision.

The 0.35 thing works with point sampling, because in that case you are rounding the result to the nearest integer, so the goal is no longer to come up with an exactly right value, just a value that is close enough to right that it will round in the right direction in spite of a wide range of implementation variability. 0.35 happens to do that pretty well for the particular set of hardware and driver bugs that exist today. But if you turn off point sampling, which disables the rounding, it makes no sense to use this at all since you will end up with unwanted filtering on every sample.

To the OP: it's not generally a good idea to rely on exact equality of results like this in graphics programming, because such things are very fragile in the presence of filtering, antialiasing, poor numeric precision, etc. It's usually better to formulate things in terms of continuous equations that will react gracefully when scaled, rather than testing specific values for exact equality.

Nod on the point sampling, though I do have a feedback routine that uses bilinear that's never given a *perfect* sphere of outward munge, though with 0.35 it worked better than other things I tried to fix it, so I guess I've relied on it ever since. This despite the slight shift in alignment in the vertex positions that's also been discussed to death on the mailing list. I guess stuff like this is why this topic never quite dies.

And O/T I see you worked about 3 miles from me at Climax, Shawn. I'm sure our paths have crossed at some point. I just checked your blog and saw you list the Oric in your rap sheet. LOL, not many of us old-timers about!   ping, zap, etc.

Heh, Oric was awesome!

Forget all this XACT rubbish, all you need is the four standard sound effect play methods: zap(), ping(), shoot(), and explode().  No matter what game you're making, those four should be enough for everyone, right?

I'll settle for that if you don't inflict that bizarror bit/pixel arrangement on me as well. That thing was truly "challenged" :)

Hi again everyone,

just to update this thread a little, using the information provided by MJP I have managed to offset the original vertex grid to get the texcoords to include the [0,1] bounds in the interpolated values (checked in PIX).

Shawn Hargreaves:

To the OP: it's not generally a good idea to rely on exact equality of results like this in graphics programming, because such things are very fragile in the presence of filtering, antialiasing, poor numeric precision, etc. It's usually better to formulate things in terms of continuous equations that will react gracefully when scaled, rather than testing specific values for exact equality.

Thanks again with your advice here Shawn and I understand and agree with you, so I will continue to look for alternatives to my current 'fix', although the the output in the game doesn't depend on total equality of results.  Until I find another solution, I'll try and keep with implementation.

For others who may want to try this, I just applied a small offset of 1 extra pixel to the width and height of the pre-transformed vertex positions:



Thanks for you help,
-John