OpenGL 1.x easy question

Let's say I want to draw a single face of size 384 x 384 and I have texture wrap on.

I have a 128x128 texture and I want it to repeat 3 times both ways but only submit a single quad or triangle list, what texcoords do I use? I can't remember how to do this.

[If remember, I'll post own answer.... I've done this before ... I just can't remember ...]

If wrap is on, then 0..3x0..3 will tile both ways 3 times (0..1 is the full width/height of the texture).

If wrap is on, then 0..3x0..3 will tile both ways 3 times (0..1 is the full width/height of the texture).

Curve ball .... what if non-power of 2 texture and texture isn't resampled to POW2, just padded up with black?

hrm?
an npot texture just refers to the number of pixels across, its texture coords still scale the same.
if you try uploading an npot texture with drivers that don't support npot, you get a gl error and an undefined image (thus white, if using glsl it appears black instead).
if the driver supports npot then 0-1 scales exactly the same as power-of-two textures do.
they'd be useless if they didn't.

the whole point of npot textures is that the hardware supports them exactly as it would a power-of-two texture. that's what makes it an actual gl feature instead of some upload hack that would be available in extensionless gl1.1.

the whole point of npot textures is that the hardware supports them exactly as it would a power-of-two texture

I mean padded up to a power of 2. Anyway, I didn't turn my brain on. Instead I should resample and adjust the texcoords range proportionally based on the upscale factor if non-POW2 isn't available. I had a predisposed idea of how to get to point B and wasn't approaching it from the right angle (nor looking for any other angles).

[i.e. for some reason I didn't consider that padding plus wrap isn't going to really be a viable combination in any kind of "easy" solution.]

you're trying to render a 2d image using npot? and trying to support power-of-two-only devices too, without scaling?
remember to move the edge coords inwards by 0.5*size or you'll see the padding as some sort of black border.
wrapping is only important if you've got a surface that tiles. you can always implement tiling using multiple surfaces.


many older cards that don't support npot do support rect textures. those may be a viable alternative for you?

No, actually I noticed in FitzQuake that the textures look crisper in some circumstances because FitzQuake doesn't actually resize, say, player textures.

And earlier in the year, I was doing some WAD <---> external texture stuff and was trying to figure out how to deal with, say, a 48 x 24 sized texture that is perfectly legitimate texture size. I didn't want to stretch, say, a 48 x 24 texture. I wanted to tile it. And not depend on the non-power-of-two extension.

I have some funny idea about using the Quake .map format and rendering the entire brush ... but I want it to look identical. [I know pretty much how the brushes and the winding stuff works now Versus being confused as hell some months back ...]

And then do some "real time lighting" experiments and do math calculation experiments ... collision in particular. It is almost impossible to learn much of value or experiment with those inside of the Quake engine. Small scale experiments are better.

But, re: devices, yeah I want stuff to work on anything. I' have the OpenGL 1.x and OpenGL ES 1.0 gap dealt with.

  Code:

#include <OpenGLES/ES1/gl.h>            // OpenGL ES 1
#include <OpenGLES/ES1/glext.h>            // OpenGL ES 1
#define glOrtho glOrthof   <------------ *snicker*
#define glFrustum glFrustumf  <------------ *snicker x 2* 

You can't make a padded texture tile properly -- it's either use the NPOT extension, or chop up your polygon into pieces which are the same size as the texture (which is pretty painful to code).

many older cards that don't support npot do support rect textures. those may be a viable alternative for you?

Only card that sticks in my head that doesn't support rect textures is nVIDIA Riva128 which no one uses seriously anymore.

by 'older' I include mobile chipsets too, though a fair number of those support regular npot textures in some limited form if only because they're so useful for 2d rendering.

but yeah, rect textures tend to have mipmaping limitations, as does limited npot support.