Brian Paul wrote:
Ian Romanick wrote:
Let me elaborate on that a bit. Texture data with a format of GL_DUDV_ATI should have a type of GL_BYTE. All of the signed types, like GL_BYTE, have a range of [-1,1]. In all existing cases, texture data has a range of [0,1]. When Mesa gets a texture of GL_BYTE, it modifies each value by (x+128)*2 to convert it to a GL_UNSIGNED_BYTE.
Each texture has a function to fetch raw, unsigned color data from the texture. We'd either have to add a new function to fetch raw, signed DSDT data or do some sort of trickery. The GL_ATI_envmap_bumpmap says that fetch color data from a DSDT texture give {0,0,0,1}. Since I didn't see an obvious, architecturally clean way to do it, and I already had (have!) a lot of other stuff on my plate, I left off there.
One of these days I'm going to add support for signed/floating point texture formats. They'd be pretty handy in conjuction with fragment programs.
I'll probably wind up adding new texel Fetch functions that return 4 GLfloats.
Fetching DSDT texels as floats would probably be good since you need to apply a floating point rotation matrix to the fetched texel.
How does that sound, Ian?
That would do the trick. I guess the default internal type for DSDT textures would be GLfloat instead of GLchan?
The internal type could be anything. I'm just saying that the Fetch function would return floating point data.
That doesn't solve the whole problem for DSDT textures (or depth textures?), though. If a DSDT texture is bound to a texture unit, the idea is that the texture environment will be set up to have the "output" of that texture unit modify the texture coordinates for some other unit. However, it is still possible to use that texture unit in the regular (color) blending environment. In that case, the color is supposed to be {0,0,0,1}, not {DS, DT, 0, 1} or some such.
Sure, adding signed float texture support doesn't solve the whole problem, but I think it's a good first step.
I guess if the float-point fetch function is only used for depth, DSDT, and fragment programs it should be okay. The various other (primarilly SGI) extension that add either signed or floating point textures to the "classic" fragment pipeline probably aren't too interesting anymore.
I think we're on the same page.
-Brian
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
