Sign in to follow this  
mrmrcoleman

Implementing an animated sprite class...

Recommended Posts

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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

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