Sign in to follow this  
Kaze

2d gl image !=2^x

Recommended Posts

Kaze    948
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

Share this post


Link to post
Share on other sites
LilBudyWizer    491
You could pack multiple textures into a single texture. Just as an example pack all the graphic elements for your user interface into a single image. That can end up being a bunch of small odd shaped images that are all used in one pass. It's easier to work on the interface as a whole loading one file and then you don't have to switch texture while drawing it.

Share this post


Link to post
Share on other sites
Kaze    948
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

Share this post


Link to post
Share on other sites
OrangyTang    1298
Quote:
Original post by Kaze
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,

A texture switch means that some or all of the current pipeline may have to be flushed before it can take effect, and it may or may not involve moving the texture data across from main RAM into vRam. Vertex transforms on the other hand are great for paralisation and pipelining so a relativly speaking much faster.

I'd go with option D - create big(ish) textures (say, 256x256) and pack multiple smaller sprites within them.

Share this post


Link to post
Share on other sites
RichardS    298
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.

Share this post


Link to post
Share on other sites
CJM    454
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this