Jump to content
  • entries
  • comments
  • views

Going mad over texture addressing

Sign in to follow this  


Right, I've had it with bloody look-up textures.

I've been staring at debug output for hours this evening (yes, I know its Friday night [headshake]) and its not making any more sense.

I seemed to get a good lead on texel addressing though. They moved the texel 'centre' with D3D10, but I thought that should really match up fine with my CPU-generated look-up texture.

Then I hit on some obscure fringe cases where it was wrapping around and pulling in completely incorrect values. Clamping appears to have eliminated those, but the overall result is still not sufficiently good for my liking.

My first task tomorrow is going to be to rewrite my look-up texture code to use render-to-texture instead. I can easily rewrite my shader(s) so that the exact same code is used in the non-lookup versus the lookup paths, and if that still generates different results then I think I might actually scream [smile]
Sign in to follow this  


Recommended Comments

Yes, render to texture has always given me good results for replacing pixel shader functions. Even so, it shouldn't be too difficult to actually generate the textures on the CPU - I've not delved into the details on DX10 texturing, but a texture is a texture, right?

Good luck!

Share this comment

Link to comment
There are two other tricks you can use to debug your lookup tables, but maybe you've already tried them:

- change the resolution of your lookup table to something incredibly big (4096) or incredibly small (16), and check how the incorrect results you get get affected. If this is indeed a texture adressing problem, going to larger resolutions should make the problem become less noticeable, as 0.5/16 is much bigger than 0.5/4096.

- set the filtering to closest/none (no filtering) and check that you now get the correct (but blocky) results..

Share this comment

Link to comment
They didn't change the "texel center", that's a common misconception.
The texel center is still at its expected position (first texel at half interval from coordinate 0) else mipmapping wouldn't work as well, etc.

What they did is change is the pixel center (in screen coordinates). If you're rendering without any form of supersampling, or centroid deviation, then your pixel center will be at a half integer value (it was at an integer value in d3d9).

That way if you have a 1:1 mapping, you don't have to do some extra math to match pixel center and texel center. (you still need to do the extra math for anything more complicated than a 1:1 mapping obviously, like a look-up table with interpolation for example).


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!