What is the best way to handle non power of two images?

Quote:

Original post by Lazy Foo I'm currently rebuilding my 2D graphics engine from the ground up. From what I understand there are 3 ways to do this: 1) Pad the image with pixels so it's dimensions are 2^n and just cut off the excess pixels when rendering. 2) Mip mapping. 3) Using the extension. The current method I use is padding the image with pixels. Is this generally considered the best method?

in my experience the extension is usually more trouble than its worth,

padding works well if you make a wrapper class for textures that keeps track of how much is padding and how much isn't

for a 2d game im working on i just make n^2 textures and resize them, i don't know how efficient it is but since im trying to make it resolution independent everything will get resized anyway

im not really a expert on this so i might not be the best one to ask though

Quote:

Original post by Kaze in my experience the extension is usually more trouble than its worth,

In fact, if there is one really easy and straightforward extension, then it would be the non-power-of-two (NPOT) one :)

It doesn't actually define anything at all. It's more or less a capability flag. If it's there (and it is on pretty much all current hardware), then it means that the hardware can handle NPOT textures in a completely transparent way. In other words, the power of two restriction is lifted. Just plug in any resolution you want into eg. glTexImage2D (up to the maximum supported size, of course), and it will work just as if it was a power of two texture !

Just one caveat: ATI has decided to not expose the extension eventhough it is supported. Just plug in NPOT resolutions on any more or less recent ATI card, and it will work fine, even if the extension isn't there. Whomever on the ATI dev team was responsible for this idiotic decision should be... oh well *sigh*.

Oh, and don't use one of the texture_rectangle extensions ! They're obsolete and a general pain in the ass.

just one last thing, im sorry if i don't understand how your trying to use it but how would mip mapping help, from what i understand it creates pre shrunk copys of the texture at (n-1)^2, (n-2)^2 and so on, so if you solve this problem by resizing you should never have to resize it more than one level, ex a 128 texture would mip 64, 32 ,16 ,8, 4 and 2 but you should never have to draw a greater than 64 texture as less or equal to32

Quote:

Original post by Yann L Quote: Original post by Kaze in my experience the extension is usually more trouble than its worth, In fact, if there is one really easy and straightforward extension, then it would be the non-power-of-two (NPOT) one :)

So all I have to do is get glee/glew to get the extension, and then call GL_ARB_texture_non_power_of_two()?

I had (still have ) a lot of problem with the extension 'GL_ARB_texture_non_power_of_two' when I used it on ATIs. Though the spec claims that NPOT textures are handled pretty much same as POT textures, I couldn't use some of the addressing modes. Also, mipmapping was not working.

For more on that go through the following

more info

Quote:

Original post by KumGame07 I had (still have ) a lot of problem with the extension 'GL_ARB_texture_non_power_of_two' when I used it on ATIs. Though the spec claims that NPOT textures are handled pretty much same as POT textures, I couldn't use some of the addressing modes. Also, mipmapping was not working.

That's right, many graphics cards don't support WRAP and MIRROR addressing modes and mipmaps with NPOT textures. It's hard to implement it efficiently in hardware. If the extension GL_ARB_texture_non_power_of_two is not listed in the extension string, it's possible that the card supports it, but only partially.

Quote:

Original post by Yann L Just one caveat: ATI has decided to not expose the extension eventhough it is supported. Just plug in NPOT resolutions on any more or less recent ATI card, and it will work fine, even if the extension isn't there. Whomever on the ATI dev team was responsible for this idiotic decision should be... oh well *sigh*.

Maybe becuase they expose it through the core API instead, so there's no reason to expose it as an extension also.

Got the feeling NVIDIA, at least long time ago, only exposed actual extensions that was usable, but not extensions that triggered, say, a software rasterization fallback even though the actual functionality was supported via the required set in the core. Maybe ATI is doing the same thing. After all, if they support OpenGL 2.0 or above, then that's enough for the user to know NPOT is supported.

Quote:

Original post by Lazy Foo So all I have to do is get glee/glew to get the extension, and then call GL_ARB_texture_non_power_of_two()?

All you have to do is make sure "GL_ARB_texture_non_power_of_two" is a substring in the string returned by glGetString(GL_EXTENSIONS) or that the OpenGL version is 2.0 or above (glee or glew should be able to help you with this at least). If it is, then you call glTexImage with the proper size, format, and image pointer, just like any other texture.