PDA

View Full Version : Question about 2d animation in a packed image with OpenGL


HalfLucifer
10-19-2006, 06:05 AM
I noticed that many 2d games packed sprite animation frames into one big image file which is none-power-of-two dimension.
However, using glBindTexture() on a NPOT texture would kill performance immediately.

I figure out two different methods might work: (I utilize DevIL to load images)

Method 1:
1) Load the NPOT image.
2) Use ilCopyPixel() to copy each region of animation frame to individual buffers.
3) Construct a sprite/quad and bind a blank POT texture(32x32, 64x64, etc) on it.
4) Use glTexSubImage2D() to replace the blank texture totally with animation frame buffers as needed.

Method 2:
1) Load the NPOT image then bind it to a larger POT texture.
e.g. 500x1000 sized image => 512x1024 sized texture
2) Bind the POT texture with sprite.
3) Modify the texture coordinates of sprite as needed.

I've implement the first method, however, it require many tedious steps to do,
and I get into troubles when I try to mirror/flip the texture.

Is second method a better implementation?
Are there other methods more efficient/effective to do?
Texture matrix? Image scaling? Blitting? Or NPOT extension?

zoombapup
10-19-2006, 06:37 AM
We mostly just padded textures up to next POT.

zoombapup
10-19-2006, 06:38 AM
Oh and we re-packed textures together and did some optimisation attempts at optimal packing (given that texture state changes werent as big an issue as they are these days).

HalfLucifer
10-23-2006, 11:27 PM
Thanks for reply.
It seems I had over-complicated thought on my mind.
Now I'm satisfied with the result of the second method. :)

GolfHacker
10-24-2006, 05:14 PM
Another approach is to put each animation frame in its own image. There are pros and cons to this approach. Cons: lots more files in your install directory, and you have to load a lot of smaller images instead of one big image to get all your frames into memory. Pros: less wasted pixels in memory (especially on lower-end graphics cards where video RAM is at a premium), and you only have to load the frames you need.

This is the approach we used for Dirk Dashing. The game's 16-layer parallax engine is very graphics intensive, and there are also a lot of animation frames for each character. We also wanted the freedom to be able to mix and match rich texture sets on each level (so we could have both indoor and outdoor areas in a single level). Texture state changes were inexpensive on nearly every graphics card we tested, both on Windows and Linux. This approach worked fine for us, and is another alternative to consider.

Bernard François
10-25-2006, 03:46 AM
Another approach is to put each animation frame in its own image. There are pros and cons to this approach. Cons: lots more files in your install directory, and you have to load a lot of smaller images instead of one big image to get all your frames into memory. Pros: less wasted pixels in memory (especially on lower-end graphics cards where video RAM is at a premium), and you only have to load the frames you need.

While reading this, I thought of a method combining the advantages of the two methods you described here.
You could put all images in one file (so it can be read in less disk accesses), and then split them up (fast compared to the saved disk accesses) in multiple images to be used by the graphics card (requiring less video RAM).

jeb_
10-25-2006, 04:02 AM
We have made a tool that loads TGA pictures and builds 256x256 texture packages based on their sizes. We use it for all our games (for example, take a look at http://www.dawnofdaria.com ).

I've attached a screenshot of the tool.

jessechounard
10-25-2006, 02:07 PM
An idea I was playing around with (though I'm sure it's not unique) is to keep all of my images separate, and then bind them into bigger images as part of the installation.

The obvious drawbacks are a longer installation, bigger hard drive footprint, and you have to regenerate the textures if the user changes rendering devices.