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 ...]
OpenGL 1.x easy question
OpenGL 1.x easy question
The night is young. How else can I annoy the world before sunsrise?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..

Re: OpenGL 1.x easy question
If wrap is on, then 0..3x0..3 will tile both ways 3 times (0..1 is the full width/height of the texture).
Leave others their otherness.
http://quakeforge.net/
http://quakeforge.net/
Re: OpenGL 1.x easy question
Curve ball .... what if non-power of 2 texture and texture isn't resampled to POW2, just padded up with black?taniwha wrote:If wrap is on, then 0..3x0..3 will tile both ways 3 times (0..1 is the full width/height of the texture).
The night is young. How else can I annoy the world before sunsrise?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..

Re: OpenGL 1.x easy question
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.
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.
Re: OpenGL 1.x easy question
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).Spike wrote:the whole point of npot textures is that the hardware supports them exactly as it would a power-of-two texture
[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.]
The night is young. How else can I annoy the world before sunsrise?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..

Re: OpenGL 1.x easy question
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?
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?
Re: OpenGL 1.x easy question
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.
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

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: Select all
#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*
The night is young. How else can I annoy the world before sunsrise?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..

Re: OpenGL 1.x easy question
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).
Re: OpenGL 1.x easy question
Only card that sticks in my head that doesn't support rect textures is nVIDIA Riva128 which no one uses seriously anymore.Spike wrote:many older cards that don't support npot do support rect textures. those may be a viable alternative for you?
i should not be here
Re: OpenGL 1.x easy question
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.
but yeah, rect textures tend to have mipmaping limitations, as does limited npot support.