Implementing an animated sprite class...

Started by
4 comments, last by Staffan E 18 years, 10 months ago
Hello... I have been using AVI's with alpha channels for some fire effects in my GUI. Unfortunately I have just implemented a new paging system to take resources in and out of memory in the background on worker threads and I have run into problems. Because DirectShow does not load the entire AVI into memory it means that the HD is constantly in use, when the worker threads start loading things off the hard disk I start getting jumpy performance. Therefore I thought it might be a good idea to make an animated sprite class which could load a texture containing all the frames of the fire animation into memory and render them in turn without having to access the hard disk. I have a couple of questions before I start though... The animations in question are 64 frames long and each frame is 100x215x32. I had planned to arrange the the frames in an 8x8 grid in the texture file giving me a 800x1720x32 texture, or 44032 kbytes (44mb). And now for a couple of questions. 1. Does anybody think this is a crazy stupid idea? And if so do you have any better ideas? 2. Does anybody know of any way of automating the process of aligning 64 frames into a big texture so that I don't have to spend 4 hours in front of Photoshop. Thanks in advance. Mark Coleman
Advertisement
I don't think it's a crazy idea, I'm working on a sprite animation class myself. I've been thinking over my head though so I'm having troubles starting off the animation class, I'm thinking about layering it like this.

AnimationSequence
>Frame[x]
>>u1,v1
>>u2,v2
>>x, y

Nothing too complex, but in general I don't really know how to approach this.
I think the idea is sound, and fairly common. The problem I see is with that texture. First, you should probably aim for powers of 2. Secondly, that thing is massive! 44 megs for a single sprite animation!? That just seems crazy to me. I would either lower the res, or cut out a good number of the animation frames.

Matt Hughson
__________________________________[ Website ] [ Résumé ] [ [email=contact[at]matthughson[dot]com]Contact[/email] ][ Have I been Helpful? Hook me up! ]
As far as I know, the average video card dislike textures above 2048x2048 if they even can handle that big textures. And your texture would be that size (or perhaps 1024x2048). Even if you don't make it power of 2 it will be loaded as that by DX.

Skip some frames or shrink it. I assume this sprite isn't the only element of your GUI. If you use several GUI elements of that size you won't have any resource capacity left for anything else.
Hack my projects! Oh Yeah! Use an SVN client to check them out.BlockStacker
Quote:Original post by PumpkinPieman
AnimationSequence
>Frame[x]
>>u1,v1
>>u2,v2
>>x, y

Nothing too complex, but in general I don't really know how to approach this.


I think you have the right idea, but that animation sequence part is a little confusing.

It's ussually easier to work with sprite strips that are in one long row. So with that in mind, say we had a run animation. The whole sprite is 512 pixels by 32 pixels. We also know that their are 4 frames of animation. Now, we need to calculate the size of our quad (assuming it's being drawn in pixel coordinates).

To do that we simply divide: 512 (image width) / 4 (number of frames) = 128

We don't need to do the height since it's always 32 pixels high. So our quad will be 128x32. Next we calculate the UV coordinate offset.

To get that we divide again: 128 / 512 = 0.25

So now we know how to draw each frame of the animation:

Frame 1) U1 = 0.0, V1 = 0, U2 = .25, V2 = 1
Frame 2) U1 = .25, V1 = 0, U2 = .50, V2 = 1
Frame 3) U1 = .50, V1 = 0, U2 = .75, V2 = 1
Frame 4) U1 = .75, V1 = 0, U2 = 1.0, V2 = 1

Hope that helps. Let me know if you have any questions!

Matt Hughson
__________________________________[ Website ] [ Résumé ] [ [email=contact[at]matthughson[dot]com]Contact[/email] ][ Have I been Helpful? Hook me up! ]
Quote:Original post by matthughson
It's ussually easier to work with sprite strips that are in one long row.

Another benefit of having as few rows as possible in a texture is that the total chache size is minimized. Be careful though of creating textures that are very wide since their rows are linear in memory and can be hard to allocate for if the memory is very fragmented.
Hack my projects! Oh Yeah! Use an SVN client to check them out.BlockStacker

This topic is closed to new replies.

Advertisement