Im making a gl 2d game but because very few graphics card support non^2 textures, I have some ideas but not sure if they will work A I could just pad the texture and have a inner size value in the texture file, simple but wastes a bit of memory, lot for bigger textures B I could just make a texture whatever size and resize it in game, the only problem is at the edges I get a black outline because it makes a semitransparent edge where 0 and 255 Alpha mix and I cant find a blending mode that’s fast and dose more than adding values together, also isnt always exact so i might not want to use it for images that need to fit togeter C I could have each texture split into 32*32 tiles and have them loaded and tiled together in game, it seems the most efficient except will the constant texture binding kill the gpu any input or if anyones knowes the relative time cost of gl state changes it will be apperciated

i wish i knew what txture binding speed was relative to, i find it hard to belive it takes way more proccessing power to change texture selections than to apply compex floating point transformations it,

as for DevIL, the 2^x is hardware related so it must use some work around too

Since you are doing a 2D game, you probably don't need mipmapping. Look at the ARB_texture_rectangle extension.

RECT textures allow non-power of two support on a wide variety of hardware. RECT textures have their own set of problems (no mipmapping, limited clamping support, etc), but in the case of a 2D app, those probably will not bite you.

Hey,

As far as I know, the most efficient solution to this problem is to make square textures [that are large, probably 512x512 or even 1024x1024] which contain all the stuff that you're planning on rendering, and then rendering the subsections that you're needing.

On a lot of graphics cards, texture changes are really slow [comparatively] [almost irrespective to size, unless you need to load the actual data onto graphics memory] methinks, so 2-3 1024x1024 texture changes should be faster than 20 32x32 texture changes [though I haven't actually tested this, someone care to confirm/debunk?], though I know that packing 4 256x256 textures onto a 512x512 texture was faster in my case.

Just some food for thought, I'd go with A, but put multiple textures onto the image. I also have tried the straight A, and at most you're going to waste just under 3/4 of the texture, but you'd have to be pretty foolish to make all of your assets 65x65 or 129x65, so the practical wastage [particularly if you design your assets around powers of two unless otherwise impossible] is much less than that - probably in the vicinity of ~10% when I was working with that stuff...

--CJM

yes, swapping texture is one of the slowest operations/state changes that a GPU can perform (topped only by switching shaders), as such keeping the number of texture binds as low as you can is the best plan in any situation.