Opinions??

inline void EnableTexUnits(bool primary, unsigned int tex0, bool prept, bool preps,
bool secondary, unsigned int tex1, bool srept, bool sreps)
{
if (primary)
{
glActiveTextureARB(GL_TEXTURE0_ARB);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, tex0);
prept?glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_REPEAT):glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_CLAMP_TO_EDGE);
preps?glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_REPEAT):glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_CLAMP_TO_EDGE);
}
else
{
glActiveTextureARB(GL_TEXTURE0_ARB);
glDisable(GL_TEXTURE_2D);
}

if (secondary)
{
glActiveTextureARB(GL_TEXTURE1_ARB);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, tex1);
srept?glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_REPEAT):glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_CLAMP_TO_EDGE);
sreps?glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_REPEAT):glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_CLAMP_TO_EDGE);
}
else
{
glActiveTextureARB(GL_TEXTURE1_ARB);
glDisable(GL_TEXTURE_2D);
}
}

Ok, you asked for it.

It sucks. Too specialized and active texture after the function returned depends on input parameters.

  • Query the number of texture units somewhere during initialization. Be prepared to handle more than two. You might limit the count, if you’re never using more than two textures ever.
  • GL_TEXTUREi == GL_TEXTURE0 + i; means use a simple for-loop.
  • Encode the enabled textures, prept, preps, in bitfields instead of separate booleans.
  • Use a vector for the texture IDs.

Cool ,
There’s no problem about specializing as I’m not using any of these calls elsewhere & I’m not going to use more than 2 tex units. Yes, the bitfiels will do OK. About loop, I was shocked when VTune told me that loop like for(a,b,c){a[i]=b[i]} should be unrolled 3 times, isn’t this the case? And finaly, what about inlining?

I find it better to have a class that will do that and some other useful stuff like keep track of what texture is being loaded now not to rebind same texture.

I’d say inlining is not needed. Trying to benchmark myself whether it’s faster to use inlined function or say not inlined class method I couldn’t see any difference in speed between both (compiled on VC6.0).

VTune is right.
A loop doing
for (i = 0; i < 3; i++) a[i] = b[i];
is slower than
a[0] = b[0]; a[1] = b[1]; a[2] = b[2];
because of the different addressing modes which will may be used in the assembler output.
The latter form uses a simple absolute address which the compiler knows beforehand, but the loop uses a computed address (base + offset).
Good optimizers don’t have a problem with the above for-loop.

I don’t feel stronlgy about inlining in general. Use it if it gets faster, don’t if you need small executables. They’re definitely better to debug than macros.