What does HLSL's tex2D return at (0,0)?

I'm trying to understand the mapping of texels to pixels, especially in the context of pixel shaders. I already found out the following:

• When I define a standard quad with vertices at integer positions (texture coordinates ranging from 0 to 1), a pixel shader for the upper left pixel will be called with texture coordinates (0,0)

• When I subtract 0.5 from the vertices' coordinates (as it's recommended when drawing sprites), the pixel shader for the upper left pixel will be called with texture coordinates (1/(2*quadWidth), 1/(2*quadHeight))

My question is about the behaviour of the tex2D function in HLSL:

I would have assumed that it just returns the color of the upper left pixel of the texture when called with texture coordinates of (0,0). But obviously this is not the case, since the second of the above-mentioned variants actually leads to the desired 1:1 mapping.

So is it correct that tex2D returns the original pixel values of a texture when given the following texture coordinates?

• Note if you use a clamp address mode tex2D @ (0,0) will be the same as tex2D @(0+0.5PX,0+0.5PX) – bobobobo Aug 30 '13 at 1:43
• @bobobobo: OK, but I guess this special case is only true for (0,0) because there are no adjacent pixels to the left/above for interpolation. So tex2D @ (1,1) will not be the same as tex2D @ (1+0.5PX,1+0.5PX), right? Otherwise the clamp mode would be a much easier way to draw sprites with 1:1 pixel mapping than subtracting 0.5 from every vertex. – ph4nt0m Aug 30 '13 at 8:04

This applies to bilinear filtering, clamp-to-edge, etc. So if you call tex2D at (0, 0), or any other position that corresponds to an integer number of texels, with bilinear filtering you'll get a blend of four adjacent texels. If called at a position corresponding to an integer-plus-half number of texels, you'll get one texel exactly.