Sign in to follow this  
GenuineXP

Frame Animation in OpenGL/2D

Recommended Posts

GenuineXP    262
Hello. I've asked this question before, but I wanted to get some opinions again to help me make a decision. I'm doing 2D rendering with OpenGL and I'm still working on sprites. The problem I'm having is with how frames of an animation are stored. At the moment, when a Sprite object loads an image, that image is loaded as one large OpenGL texture. To produce the animation, the texture is mapped to a quad with the proper texture coords for each corresponding frame. This seems to work, but the big problem with it is compatibility. I'm also wondering if there are other problems I'm not noticing. I've had no problems using my system so far, but it has a GeForce 6600 GT which is a modern enough graphics card. I'd like my engine to be able to support older hardware. I tried it on a very old laptop (an IBM ThinkPad with a Pentium II processor clocked at 366 MHz) and did have problems. For once thing, the power-of-two texture size was an issue, which I expected. The other problem was the maximum size of textures; it was far too small for sprite sheets with many frames. The other method I've considered is loading each individual frame of a sprite sheet into an OpenGL texture. This would mean each animated sprite would result in many, smaller textures. This seems as if it'd allow for more compatiblity; all one would need to do for maximum compatiblity is design a sheet whose frame width and height are the same and a power of two! I wanted to implement both methods and use an enumeration to tell a Sprite object how it should handle this problem, but I started getting some very clunky code. I think I want to go one way or the other at this point. If I do still go for both, rather than allowing such a setting per Sprite object, I'd make the setting per Renderer object (the object that actually draws stuff)... or a global setting for the entire engine! What do you think? What should I do with this problem? Any input is greatly appreciated, as usual. :-) Thanks in advance!

Share this post


Link to post
Share on other sites
Red Ghost    368
Hi,
On old configurations, do you have enough disk space ?
I would then suggest you to have different sprite sheets according to the configuration resolution.
Let's say you have a walk animation in twelve frames: it is suitables for current machines because of high texture size and processor speed (you can have a finer update of your sprite so that you use all twelve frames when displaying your walking animation).
For older configurations you have a second sprite sheet with only four frames for the walk animation. When loading on old configuration, this sprite sheet is used.
You just have to detect the configurations at starting time and according to the configuration capability load the sprite sheet and animation definition linked to it.

If you still want to have all your twelve frames on a lower configuration, you could also divide your sprite sheet into as many smaller sprite sheets as you want: if you have a left walking animation and a left running animation on the same sprite sheet, you can separate into a walk animation sprite sheet and a run animation sprite sheet. Be aware though that the total number of textures loaded are limited by the graphics card memory available.

I personnaly prefer the first solution:
- I have one sprite sheet per character and per configuration resolution: I find it easier to maintain.
- I find it easier to test: the animation drawing functions do not change. I only pass a different set of parameters to it when loading a sprite sheet.

In my own implementation I define a sprite object with the number of different animations. Each animation object linked to the sprite defines the number of frames of that animation and Frame timing resolution.
When animating, the animation function reads up the frame timing resolution and compares with the time elapsed since the last call: it does then not matter that I have a twelve frame or a four frame animation since the animation functions will update according to the data stored in each animation object.
If you use such an architecture, all you need is evolve your sprite definition to store the different animations according to resolution, something like:


typedef struct SpriteDef {
int width, height;
int anchorx, anchory;
char LowResAnimationName[128]; //name and path of animation Def file
char HighResAnimationName[128];//name and path of animation Def file
}

typedef struct AnimationDesc {
char Name[32]; // name of animation
char SpriteSheetName[128]; //name and path of sprite sheet texture
int nbFrames;
int FPS; //Frame resolution timing aka Frames Per Second
float *texx1, *texy1, *texx2, *texy2;
}

typedef struct AnimationDef {
int nbAnimations;
AnimationDesc* Animations;
}




Hope that helps.
Ghostly yours,
Red.

Share this post


Link to post
Share on other sites
Red Ghost    368
I just thought of something. Do you store many directions in your sprite sheet ?
I mean do you store left and right walking animations ?

If so, you could reduce the size of your sprite sheet by removing any symetrical animations: e.g. you keep the left walk animation and remove the right walk one. The right walk animation can be duplicated by reversing texture coordinates on the quad.

Ghostly yours,
Red.

Share this post


Link to post
Share on other sites
smurfkiller    103
Storing tiles in one texture is always better, there is no exeptions, same thing on old as on new hardware. To be able be compatible with old hardware you just have to scale down your textures. There is nothing else to do actualy. Alot of modern games uses lo and hi resolution versions of same texture to be able to use higher resolution textures on hiend gfx cards.

Share this post


Link to post
Share on other sites
GenuineXP    262
Thanks for the replies.

OK, so I should just stick to loading one large texture? I guess providing "auxiliary" sprite sheets is the best way to go; provide some more compatible resources instead of modifying the engine.

I thought loading tons of smaller textures might cause problems. :-)

@ Red Ghost: At the moment, I'm just testing some sprite sheets I threw together. Because I'm using OpenGL and my Sprite objects make transforming an image pretty easy, I'd only include frames for one direction of an animation and flip it in real time. (It isn't implemented yet, but my Sprite objects include HFlip() and VFlip() methods.)

Any more comments are very welcome. Thanks again.

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