Thanks for all the responses.  Here's some more info, in digest form:

- The target platform is D3D9.  I'm creating the textures with D3DXCreateTextureFromFileInMemoryEx and passing in default to the mip count so the driver will create all the mips for me.  I guess I could try passing 1 in and see if it changes any behavior by not generating any mips.  Thanks for bringing that up.  The graphics card I'm testing this with is my Quadro FX580, with Maya certified drivers... I would expect it not to pull shenanigans with LOD bias, but then, I might be wrong.  I'm definitely not setting LOD bias anywhere explicitly.  I suppose I could also supply the texture with mips manually and see what I see.

- @Colin: I did read that previously, which is why I attempted a half-pixel offset with the projection and/or view matrices.  This did not seem to have the desired effect of correcting a solid gray to black and white.  I was a bit surprised at that.  No value I could put in there seemed to do more than 25% correction, at best, which leads me to believe it's a texture issue.

- @Matthew: My ortho projection is simply -0.5 to 0.5, and the view has an offset of 0.5 so that the 'model' deals with 0..1 as the range.  So, no, the aspect ratio really doesn't come into it.  Thus, it would just stretch anything I render to fit the screen, regardless of the resolution.  Why do you ask?

I guess the real question I had was, how is the best way to correct for pixel/texel mismatches?  Do most people adjust the view matrix or the projection matrix, or do you modify the vertices on the quads you generate, or do you trick it with texture matrix modifications or generate the UVs differently?  Lots of options.  The easiest seemed to me to be the view matrix, but when it didn't work, I started looking for other things that could affect the calculation, but didn't find any culprits.

Thanks guys,

On 8/7/2010 4:56 PM, Marco Salvi wrote:
Hi Jason,

Does your texture come with a full mipmap chain? If that's the case it would be better to see what happens without mipmaps and just point filtering.

On which platform are you working? 

Some drivers with low quality settings may set by default a positive LOD bias. Are you (inadvertently?) modifying the textures LOD bias at all?


On Sat, Aug 7, 2010 at 2:20 PM, Jason Hughes <> wrote:
I've been trying to resolve an issue where full screen textures being
drawn through the 3D system appear blurry.  I feel like I'm probably not
considering something.  Any ideas would be welcome!

- I'm using an orthographic projection matrix along Z, a view matrix
that is pretty much identity except for some negations on various axes
to correct for LH/RH differences in the engine.
- The quad is mapped to the full screen both for vertex positions and
UVs (0,0,1) to (1,1,1), since the ortho matrix is 0..1, not in screen
- The texture has the exactly the same number of pixels in both
directions as the back buffer.
- Back buffer and window match resolution exactly.
- Resolution is 1024x600 (but problem exists in other resolutions)
- Texture sampling is bilinear or anisotropic (shouldn't matter).  Both
show the problem.  Sometimes my 2D stuff needs to cleanly scale, so I
can't force point sampling globally.  Texture matrix is disabled.

Steps I've taken to debug:
- I made a simple texture with regions that are alternating white and
black columns and rows that are 1, 2, and 4 pixels wide, so I could see
what was happening with texture sampling.  The result is an even gray in
the 1-pixel wide areas, but can be made brighter and darker depending on
the offset I put into the matrices.  Half-pixel adjustment didn't fix
it.  I never get white or black lines.
- I checked to make sure that the test image wasn't being munged by the
texture processing tools and it's perfectly clean (no GIGO).

I can understand not getting perfect rasterization vertically due to the
height being a non-power-of-two, but I expected columns to be cleanly
mapped.  What else should I be looking for?

Most appreciated,

Jason Hughes
Steel Penny Games
Austin, TX

This email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
GDAlgorithms-list mailing list

------------------------------------------------------------------------------ This email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge
_______________________________________________ GDAlgorithms-list mailing list Archives: