Texture Coordinates not in floating point

I want to texture a polygon with glTexCoords2s. I can texture polygons correctly if I use glTexCoords2f. Since 4 bytes for a simple texel coordinate is a bit memory consuming, I thought I would use glTexCoords2s. I thought this would mean I could use the full range of 0..$7fff to mean 0.0 to 1.0. Unfortunately, 0 means 0 and 1 means 1.0 When I supply anything except these two, I get either a texture tiling or texture clamped, depending on how I set the parameters. I tried setting up a texture matrix of
1/65536 0 0 0
0 1/65536 0 0
0 0 1 0
0 0 0 1
to generate coords between 0 and 1, but that did nothing.

I'm sure this is a relatively easy thing, but I am at a loss. My OpenGL documentation does nothing but use floating point texel coordinates.

Which brings me to ask, what exactly is the texture matrix used for?

[paolom]

Just to be clever, remember that usually compilers align data structures on 32-bit boundaries, or maybe more. Surely they do not default to pack shorts in a structure.
If you really wanna use shorts, take into account that:
- you must pack data structures
- the alignment issues will make for worse performance with memory access and caching
- OpenGL drivers will always internally convert that to floating point

So really, there are more CONs then PROs.

---
As for texture matrices, I read a very effective article: they can be used for texture projection, or for lightmaps application.

[This message has been edited by paolom (edited 02-17-2000).]

The drivers convert to floating point anyways? This I didn't know, but then again I guess I shouldn't be surprised. So if I use shorts and then convert it to float myself, I'm not really losing anything, am I?

[mike j]

using the texture matrix provides some cool
effects.. with the texture matrix you can
get textures to move across the surface of
a polygon

[paolom]

Goof: you (and your app) are just losing... time

[MikeC]

paolom - you're almost certainly right about short-to-float conversion being slower, but it's just possible that the shorts will be faster (e.g. if you're hopping around the texcoord array, and the whole thing will fit in cache as shorts but not as floats). As usual, you don't know until you do some profiling.

About struct alignment - compilers generally align each member on the SMALLER of the member's size and the default struct packing (usually 32 bits).

An example layout and probable packing:
(assume 2-byte short, 4-byte int and float)

struct s
{
short a; // offset 0
short b; // offset 2
byte c; // offset 4
float d; // offset 8
byte e; // offset 12
byte f; // offset 13
};

Note that the order in which you declare members can make a difference to the struct size.

[paolom]

Uh! Sorry guys... I really was wrong about struct members alignment.
Thanks MikeC