Keith Whitwell wrote:
Roland Scheidegger wrote:
Keith Whitwell wrote:
Unfortunately it's not. Mesa will initialize the correct
default wrap and filter mode when glBindTexture is called with
the rectangle_nv target and the texture object already exists
(that is, glGenTextures has been called previously). It's
really a pity that textures with rectangle_nv targets have
different default wrap/filter modes, but there is no guarantee
that the correct filter mode will be set later - the default
value needs to be correct. That said, it would be sufficient to
only call r200SetTexWrap and r200SetTexFilter in
r200BindTexture, not the other two functions, and it would only
be needed if the target is rectangle_nv (and only if the target
wasn't known when the object was created, but the driver
doesn't know this at this point).
In this case, I think Mesa should be calling the driver callbacks
instead of just silently changing the values in the texture
object.
Keith
You mean something like this attached patch here? Or is it a
problem that TexParameter is called on a (yet) unbound texture
object (it is guaranteed the object exists though).
I don't think that should be a problem with the current drivers,
though perhaps it could be in some unspecified future one. I'm happy
with this approach for now though.
Of course for the r200 driver, the three calls to set the wrap mode
are kinda redundant... (patch is completely untested, well it
compiles).
I think WrapR is redundant for rectangular textures on all hardware?
I really have no idea, I'm just following Mesa's lead ;-). Feel free to
drop it...
Index: texobj.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/main/texobj.c,v retrieving
revision 1.81 diff -u -r1.81 texobj.c --- texobj.c 27 Jan 2004
16:34:46 -0000 1.81 +++ texobj.c 28 Jan 2004 18:03:40 -0000
@@ -818,6 +818,12 @@ newTexObj->WrapT = GL_CLAMP_TO_EDGE;
newTexObj->WrapR = GL_CLAMP_TO_EDGE; newTexObj->MinFilter =
GL_LINEAR; + if (ctx->Driver.TexParameter) { +
(*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE ); +
(*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE ); +
(*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE ); +
(*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_MIN_FILTER, GL_LINEAR ); + } } } else {
Hmm, except that the final parameter is a float * :
static void i830TexParameter( GLcontext *ctx, GLenum target, struct
gl_texture_object *tObj, GLenum pname, const GLfloat *params )
so it will be a bit nastier. I'm suprised the compiler didn't
complain about this actually.
my bad. It *did* complain, I just didn't check carefully enough about
warnings :-(.
This patch should be better hopefully.
Or would it be better to declare that as fparam[4], since in other cases
the array has up to 4 values?
Roland
btw and hopefully this time I'll send it to the right list, argh.
Index: texobj.c
===================================================================
RCS file: /cvs/mesa/Mesa/src/mesa/main/texobj.c,v
retrieving revision 1.81
diff -u -r1.81 texobj.c
--- texobj.c 27 Jan 2004 16:34:46 -0000 1.81
+++ texobj.c 28 Jan 2004 23:27:11 -0000
@@ -818,6 +818,15 @@
newTexObj->WrapT = GL_CLAMP_TO_EDGE;
newTexObj->WrapR = GL_CLAMP_TO_EDGE;
newTexObj->MinFilter = GL_LINEAR;
+ if (ctx->Driver.TexParameter) {
+ GLfloat fparam[1];
+ fparam[0] = (GLfloat) GL_CLAMP_TO_EDGE;
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_S, fparam );
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_T, fparam );
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_WRAP_R, fparam );
+ fparam[0] = (GLfloat) GL_LINEAR;
+ (*ctx->Driver.TexParameter)( ctx, target, newTexObj,
GL_TEXTURE_MIN_FILTER, fparam );
+ }
}
}
else {
