Jump to content
  • Advertisement
Sign in to follow this  
GenuineXP

OpenGL Loading Textures Into Memory On Demand: Too Slow?

This topic is 4411 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello. I've been running into some trouble with my little game engine lately. I'm trying to do 2D graphics with OpenGL and supporting animation has been a bit difficult. Currently, two forms of animation are supported: Strips and Maps. Both involve loading a texture into video memory (after resizing it to be a power of 2) and specifying the proper texture coordinates for each frame of the animation. This works, but there are a few problems. (1) I'm finding it hard to add support for animated GIFs and MNGs. I've tried using 3D textures to get around this problem, but it hasn't been working well. (2) It's hard to support long animations with relatively high resolution frames because the textures become very large (2048x2048 pixels, for example). I've tried to add animation by altering one of three things: the actual texture in use, texture coordinates, and the "slice" (3D texture r cooordinate). I just recently had a thought though. Since I'm using DevIL to load images, it seems like it would be much easier to load an entire image into system memory (including frames of a GIF and MNG file!) and then load only the necessary part of that image in system memory into video memory when it's needed. This would mean that whenever a specific frame is requested, the appropriate OpenGL texture is loaded into video memory on the fly. My question is, is this a sensible design? I'm not sure this is very effecient. Is loading a texture (a call to glTexImage2D()) too expensive to perform for each frame in an animation? I think this method could give me the flexiblity I need, though it may be a bit of a memory hog. Thanks!

Share this post


Link to post
Share on other sites
Advertisement
I wouldn't recommand doing a call to glTexImage2D every time, If you can't load everything in memory, then you should look at glTexSubImage2D. It won't create a new texture, but will change an existing one instead.

If you can get away with some loss in quality, try compressing your bitmap in a format that your card can support(DXT for example). You can then use glCompressedTex(Sub)Image2D, which could provide you with an even better result.

You could also look at texture atlas for your textures so that you have less texture binding changes. Although this doesn't work all that great with animation, but it can still make better usage of memory.

If you find anything else that works for you, let us know, this subject is of interest to me right now :)

Cheers,
Shadx

Share this post


Link to post
Share on other sites
The thing to bear in mind is that your typical opengl implementation will swap textures in / out of video memory as necessary anyway (e.g. on glBindTexture or the next drawing operation after it with texturing enabled). As it has low-level info about the hardware, it may make better choices than you.

So provided you don't have too many textures for *system* memory, it should happen automatically anyway, and faster than calling glTexImage2d (although possibly not much?).

Of course you could still get severe performance issues if it's constantly swapping textures.

I suppose splitting a large image with a lot of animation into smaller strips might help as it would only need to swap in the parts needed at a given time, but there is a trade-off, as if the strips are not power-of-two high / wide, then there will be wasted space.

Mark

Share this post


Link to post
Share on other sites
Thanks for the replies. :-)

I've had some success. For one thing, I changed my implementation so that animations are always made up of a number of smaller textures. By refactoring my Texture class to introduce a new Image class, I've been able to support animation with much more ease.

I load an image (into system memory) with a new Image object, then that Image is passed to a concrete subclass of Sequence, which generates from the Image a Texture for each frame in the animation. The Sequence is then passed to a Sprite, and it all comes together.

The idea of the Image class helped immensly, as did seperating frames between textures. Images have two primary methods that Sequences use to generate Textures: SubImage() and Slice(). Both return a new Image pointer. SubImage() returns an Image which is a specified portion of it's parent. Slice() returns an Image holding data of only the specified slice index (frame in a GIF or MNG animation).

I'm only rendering one sprite in my test application, but it seems to be running just fine. The biggest problem I see with this is that swapping textures every frame may be very demanding on some systems.

Thanks again.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!