Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have a custom application that deals with many Bitmaps tiles that are 256x256 images (png,jpg). I'm currently using the View 2d canvas and bring in all images as RGB_565. Although I'm generally happy with the applications performance, I have features I'd like to add that will require even more map tiles (Bitmaps). I've been thinking about using opengl ES 2.0 but am fairly new to it.

  • Would opengl Textures be more memory efficient than keeping Bitmaps around? I assume you can load a Bitmap into a Texture and then dispose of the Bitmap

  • Is it an acceptable practice in opengl to dynamically load many different Textures at runtime?

  • Do you need to cache Textures or does the GPU handle that for you?

share|improve this question
add comment

1 Answer 1

up vote 6 down vote accepted
  • Would opengl Textures be more memory efficient than keeping Bitmaps around? I assume you can load a Bitmap into a Texture and then dispose of the Bitmap

Maybe they are and maybe they're not. The one thing that OpenGL would give you is the ability to use compressed texture formats (usually one of the DXTn formats). If you don't care about an alpha channel (or if 1 bit alpha is enough) this can get you one-eighth of the storage requirements; if you do it can be one-quarter. Whether or not this is a win compared to your current PNG/JPG approach depends a lot on whether you're keeping uncompressed variants of your image file in memory too.

There is dependency on your driver supporting compressed textures too; if it doesn't it's game over. There's also a (slight, but depends on the texture) quality tradeoff involved here.

Brief summary here: http://developer.motorola.com/docstools/library/understanding-texture-compression/

  • Is it an acceptable practice in opengl to dynamically load many different Textures at runtime?

That can be slow and it's one of the tradeoffs of using a 3D API for this. On the one hand you get to store textures in high-performance local video memory; on the other hand it can take a little time to get them there. Generally what you'd do (in this case - if storage wasn't a problem you'd just load everything up-front) is create a small handful of textures at the required size (256x256 in your case) then use glTexSubImage2D (or glCompressedTexSubImage2D for compressed textures) to update the data; that way the only hit you incur is disk I/O and bandwidth; otherwise OpenGL will be throwing away the old texture and completely re-specifying a new one each time.

With compression available respecifying a texture can be as little as 5 lines of code - fopen, fread, fclose, glBindTexture and glCompressedTexSubImage2D.

Of course you would also store the source textures on disk in the native compressed format so that they can be uploaded directly instead of having to go through any intermediate conversion steps (that will also be a huge saving in terms of performance on your current PNG/JPG usage, which would require the image files to be decompressed and converted to 5-6-5 first).

  • Do you need to cache Textures or does the GPU handle that for you?

The GPU will do that for you. Just create a texture object using glGenTextures to give it a unique name, then glBindTexture that name in order to use it, and the GPU will manage everything else.

So - compressed textures, update existing textures rather than respecify, and you should see some improvements in both memory usage and performance.

share|improve this answer
    
Your answer seems to be focused on desktop OpenGL. The question was about Android, which features OpenGL ES. So no DXT compression (unless it's an NVIDIA GPU). –  Nicol Bolas Feb 29 '12 at 3:33
    
True that; I was just using DXT as an example because it's the best known, but other compressed formats are available. It all depends on whether the tradeoffs involved are acceptale to the OP. –  Jimmy Shelter Feb 29 '12 at 3:36
    
Thanks you so much! When you say "create a small handful of textures at the required size" do you mean, essentially create a pool of Texture and reuse them by swapping out the bits of other images? –  dbryson Feb 29 '12 at 3:50
    
Yup, the pool of textures approach would work. –  Jimmy Shelter Feb 29 '12 at 11:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.