Check that the target is GL_TEXTURE_CUBE_MAP before emitting
TEXCOORDTYPE_VECTOR texture coordinates.
I'm not sure if the hardware would like CARTESIAN coordinates
with cube maps, and as I'm too lazy to find out just emit the
VECTOR coordinates for cube maps always. For other targets use
CARTESIAN or HOMOGENOUS depending on the number of texture
coordinates provided.
Fixes rendering of the "electric" background texture in chromium-bsu
main menu. We appear to be provided with three texture coordinates
there (I'm guessing due to the funky texture matrix rotation it does).
So the code would decide to use TEXCOORDTYPE_VECTOR instead of
TEXCOORDTYPE_CARTESIAN even though we're dealing with a 2D texure.
The results weren't what one might expect.
demos/cubemap still works, which hopefully indicates that this doesn't
break things.
Also tested with:
bin/glean -o -v -v -v -t +texCube --quick
bin/cubemap -auto
from piglit.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
GLuint mcs = (i830->state.Tex[i][I830_TEXREG_MCS] &
~TEXCOORDTYPE_MASK);
- switch (sz) {
- case 1:
- case 2:
- emit = EMIT_2F;
- sz = 2;
- mcs |= TEXCOORDTYPE_CARTESIAN;
- break;
- case 3:
+ if (intel->ctx.Texture.Unit[i]._Current->Target == GL_TEXTURE_CUBE_MAP) {
emit = EMIT_3F;
sz = 3;
mcs |= TEXCOORDTYPE_VECTOR;
- break;
- case 4:
- emit = EMIT_3F_XYW;
- sz = 3;
- mcs |= TEXCOORDTYPE_HOMOGENEOUS;
- break;
- default:
- continue;
- };
-
+ } else {
+ switch (sz) {
+ case 1:
+ case 2:
+ case 3:
+ emit = EMIT_2F;
+ sz = 2;
+ mcs |= TEXCOORDTYPE_CARTESIAN;
+ break;
+ case 4:
+ emit = EMIT_3F_XYW;
+ sz = 3;
+ mcs |= TEXCOORDTYPE_HOMOGENEOUS;
+ break;
+ default:
+ continue;
+ }
+ }
EMIT_ATTR(_TNL_ATTRIB_TEX0 + i, emit, 0);
v2 |= VRTX_TEX_SET_FMT(count, SZ_TO_HW(sz));