Texture sizes

Hello,

at the moment I am writing a 2D engine in OpenGL, and I implemented animation. The frames are put together in one bitmap next to each other, and to animate them, I just load the bitmap and change the texture-coords. This works fine.

But I tried to load a bitmap with the size 192x32. but my graphics card only loads 64x64, 128x128 etc. (even 192x192 doesnt get loaded). Thats a real problem. Of course I could load the bitmap and fill the bitmap up that it has the size 256x256, but then, i would also need to change the frame positions inside the bitmap. And if I resize the bitmap, I'll also have problems with collison-detection because its based on the size of the frame.

Did you have similar problems? How did you solve that issue?

Thank you for any hints.

[memfr0b]

That is a general limitation of OpenGL textures. Texture width and height have to be 2^n+2(border) pixel (though n doesn't have to be the same for width and height).

You can get around this limitation if you have an OpenGL implementation that supports the GL_ARB_texture_non_power_of_two extension, or the GL_ARB_texture_rectangle extension in which case you don't use GL_TEXTURE_2D but GL_TEXTURE_RECTANGLE_ARB.

Just put the texture in a bigger texture in your case 256 and you can use the additional space for other stuff

cheers
Boim

[Omaha]

I think the simplest solution would be something I think you alluded to in your original post and someone here mentioned and that is padding the 192x32 image to be 256x32, which would be the next easily-accesible texture size.

If your present image loading scheme depends on images using the entire "texture sheet" then yes, you're going to have to make modifications to your program, but short of redrawing the image to fit into a power of 2 exactly, there's really no way around making changes at this point, methinks.

I see...

I think the best way would be really to size the picture up and only use a part of the texture for animation. Thank you, I'll give it a try. I hope I'll get it running

Ok, sorry for double posting, but I really got a problem. I filled the texture up now to get a loadable size, so the bitmaps size is now 256x32. With the following code, the animation gets displayed:

glBegin(GL_QUADS);
glTexCoord2f(((1.0f/handle->framesx)*
       (frame+1)),1.0f);
glVertex2d(hsx,-hsy);
glTexCoord2f(((1.0f/handle->framesx)*  
       (frame)),1.0f);
glVertex2d(-hsx,-hsy);
glTexCoord2f(((1.0f/handle->framesx)*  
       (frame)),0.0f);
glVertex2d(-hsx,hsy);
glTexCoord2f(((1.0f/handle->framesx)*
       (frame+1)),0.0f);
glVertex2d(hsx,hsy);
glEnd();

The code for glTexCoord2f is pretty simple. I take the whole width of the bitmap (1.0f), divide it through the number of frames (framesx) and multiply it with the frame I want to display.

But now, I only want to use a width of 192 pixels of the 256 pixels inside the texture for my animation. Therefore I changed the glTexCoord2f code as follows:

 
glBegin(GL_QUADS);
glTexCoord2f(((handle->borderfac/handle->framesx)*(frame+1)),1.0f);
glVertex2d(hsx,-hsy);
glTexCoord2f(((handle->borderfac/handle->framesx)*(frame)),1.0f);
glVertex2d(-hsx,-hsy);
glTexCoord2f(((handle->borderfac/handle->framesx)*(frame)),0.0f);
glVertex2d(-hsx,hsy);
glTexCoord2f(((handle->borderfac/handle->framesx)*(frame+1)),0.0f);
glVertex2d(hsx,hsy);
glEnd();

The only thing that changed is glTexCoord2f. It doesn't divide 1.0f now, it divides the floatvalue borderfac, which holds the value (192/256=0.75f).
But now my texture isn't displayed anymore. Maybe I make a mistake in thinking but normaly, my code should be right?

Can somebody help me?
I'm pretty confused

Thank you

[Omaha]

Do you have backface culling enabled? You're drawing your quad with the vertices in clockwise order, and the default for the front face is counterclockwise. If you are culling backfaces, you can either just set the default winding to clockwise or flip up your vertex calls. If not...

Hmm.

Are you sure borderfac is a float? Also, do you initialize it with the statement:

borderfac=192/256;

If so, the value is going to be zero, so that could definitely cause trouble. All you need to do is fix this by either explicitly casting one of them (192 or 256) to a float, or implictly doing it by tacking a decimal point at the end.

Originally posted by Omaha:
...or implictly doing it by tacking a decimal point at the end.

Ahhh that was exactly my mistake
Thank you very much, it was a really stupid mistake I did.

Thank you! Now everything works very fine...