OpenGl 2.0 non power of two textures working?

Hi,

whenever I use non power of two textures they seem to be corrupted as soon as I am using more than one textures (glBindTextures…). This doesn’t happen if I use power of two textures… however I think in OpenGl 2.0 this feature isn’t a extension anymore?! I have a ATI Radeon X800 and the newest driver. Am I wrong that ATI already supports OpenGl 2.0?
Strange: Assuming I am right that my Driver/Graphics Card supports 2.0: If I check ARB_non_power_… it reports false?!

Am I overseeing something?

thx
LastBoyScout

Hi,

ARB_texture_non_power_of_two is currently fully supported only on NV4x hardware. That’s why you don’t see it on your X800. But since ATI has to expose GL2.0 and NPOT textures got into the core at this version, they do allow NPOT textures with certain limitations. That is, you may create a TEXTURE_2D with npot dimensions, you may use normalized texture coordinates, but you have to obey the ARB_texture_rectangle limitations (no mipmapping, etc). Obviously these limitations will be removed once the R520 is out (which will also expose the ARB extension).

Actually, as it turned out, ATI never really supported dimension-dependent texture coordinates for rectangle textures, they were automatically normalized in the shader. One reason to never use RECT textures on ATI cards, but use NPOT 2D ones instead.

On my old ATI Radeon 9600 (with Catalyst 2.0.5079) the GL_TEXTURE_RECTANGLE_ARB extension works very well. It happily draws many bound textures at the same time.

Actually the card says it doesn’t support the “GL_ARB_texture_rectangle” extension but it does the “GL_EXT_texture_rectangle” extension, which means the same result. So it’s ok to query for the first OR the latter extension.

Whilst I’m using this extension for plain 2d OpenGL rectangles (with JOGL) and so don’t need MIN_FILTER or MAG_FILTER, there are a few restrictions, like Spasi said.
The row byte count of the NPOT texture has to be multiple of 4. In case it’s an RGBA texture you can use any texture width. In case it’s a RGB texture however the width must be a multiple of 4. If you forget this, the resulting texture looks corrupted.

Using the rectangle extension together with on-the-fly compression does work basically but is terrible slow. I’m not sure if this is ATI only, but I avoid it for NPOT textures.

Meta code…
Bind the texture
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, <texture_id>);
glTexImage2D(GL_TEXTURE_RECTANGLE_ARB, 0, , <texture_width>, <texture_hight>, 0, <RGB|RGBA>, GL_UNSIGNED_BYTE, );

Later on paint it:
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, <texture_id>);
glEnable(GL_TEXTURE_RECTANGLE_ARB);
glBegin(GL_QUADS);
glTexCoord2d(0, 0); glVertex2i(0, 0);
glTexCoord2d(1, 0); glVertex2i(<texture_width>, 0);
glTexCoord2d(1, 1); glVertex2i(<texture_height>, <texture_height>);
glTexCoord2d(0, 1); glVertex2i(0, <texture_height>);
glEnd();

Etc

[quote=“Bombadil,post:3,topic:23775”]
Yes, rectangle textures work just fine on ATIs (except the possible performance disadvantage I mentioned). But LastBoyScout wants to use npot GL_TEXTURE_2D textures.

[quote=“Bombadil,post:3,topic:23775”]
Yeah, the ARB, EXT and NV extensions define the same value for GL_TEXTURE_RECTANGLE_XXX. I think ATI doesn’t expose the ARB one because it also defines rectangle texture sampling in GLSL, which IIRC they do not support yet.

[quote=“Bombadil,post:3,topic:23775”]
Thanks, I didn’t know that.

Oh well, now I got the point. I read “NPOT texture” and thought the (NPOT) rectangle extension which I use currently…

I didn’t know NPOT textures could be used with the normal GL_TEXTURE_2D target one day (OpenGL 2.0++). So thanks for the pointer, very nice to hear.

Btw. the “possible performance disadvantage” for the rectangle extension looks to be very small according to my tests.

[quote]Yeah, the ARB, EXT and NV extensions define the same value for GL_TEXTURE_RECTANGLE_XXX. I think ATI doesn’t expose the ARB one because it also defines rectangle texture sampling in GLSL, which IIRC they do not support yet.
[/quote]
Sounds reasonable. Learned another “why”. :slight_smile:

[quote]

It applies to the rectangle extension and unfortunately is only partly explained on the ogl registry.

However I don’t know if this also applies to the new OpenGL 2.0 NPOT GL_TEXTRUE_2D target.

Sorry for the thread-hijacking. Back to normal thread business. :slight_smile:

[quote=“Bombadil,post:5,topic:23775”]
The ARB_npot extension removes the POT limitation from all the other targets too. Though I’m sure that if you try to use a npot CUBE or 3D texture with a card that doesn’t expose it (like current ATI cards), it will fail or fall back to software mode.

Hi,

thx for the clearing up.

Arg… right now I am doing 2d things so that rectangle extension might work. It’s even more comfortable sometimes because texcoords aren’t normalized. However if I have a zooming effect or something in my 2d gui thing then I can’t live with those restrictions.

First: Where can I find out about those not-quite-specification-like behaviour of some cards? Because I was spending quite some time looking for the error in my code…

Second: Since I obviously have to work with POT textures what’s the usual approach? Just work as if you could have several textures with arbitrary size and always “silently” round up to next power of two or try to pack things in one big texture? Second approach is, well, more work :wink: the fitting… the texcoords… maybe always setting the texmatrix… and so on

thx
LastBoyScout

[quote]However if I have a zooming effect or something in my 2d gui thing then I can’t live with those restrictions.
[/quote]
What’s concerning the older rectangle texture extension…

For my 2d like game the (down-) zooming with missing Mipmap isn’t a big problem, because it’s just used as an effect sometimes and not all the time (like in 3d, or maybe in your 2d GUI thing).
I set GL_TEXTURE_MIN_FILTER and GL_TEXTURE_MAG_FILTER to GL_LINEAR and it looks smart enough. (GL_LINEAR is default for the MIN_FILTER on this extension.)
Also setting GL_TEXTURE_WRAP_S and _WRAP_T to GL_CLAMP_TO_EDGE works fine so the drawing of repeated large background textures looks seamless.

In the end I save a lot of work and memory compared to pack the 2d sprites into big textures. For larger sized animated sprites, usually not all animations will be on screen at once, so the 3d card’s video RAM can be used otherwise, and so on.

Concerning the restrictions: All cards which support the
GL_TEXTURE_RECTANGLE_XXX extension have to conform to this: http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_rectangle.txt

Like Spasi said: the “ARB_texture_rectangle” is “functionally identical to EXT_texture_rectangle and NV_texture_rectangle extensions” (quoting the registry).