Sign in to follow this  

animations

This topic is 3829 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

How do you folks store your animation assets? If you had say an orc...would you put everything in 1 image file... idle se ne sw nw ... attack se ne sw nw ... or do you split it all up... thanks!

Share this post


Link to post
Share on other sites
I would also say a sprite sheet is better for one character. Just the thought of having 100's of image files for one character is daunting, not recommended. [grin]

To avoid waste of space it can be a good idea to keep it at only one character per image file though, since that character often have the same size in the different poses. So there's not much space wasted between the pose rectangles in the image, compared to if a larger object/character would be put beside it in the same sprite sheet.

I would also recommend having a separate file of text (to start with) that specifies the different frames in the animation poses, because it makes it a lot easier to add additional new poses in the image at a later stage.

That's because if you specify the animation rectangle coordinates externally in a text file you won't have to for example move all the frames after the "idle" ones if you were to extend the "idle" frames. So you could simply add the new "idle" frame at the end instead. That's what I've experienced at least.

Share this post


Link to post
Share on other sites
I'd recommend doing an approach that allows multiple sprite sheets per character, with multiple sprites per sheet. With large characters and lots of detailed animations, you can quickly run out of room on a single sheet, so being able to have multiple sheets is a good thing.

Share this post


Link to post
Share on other sites
i put this in my lighting thread but it really goes here...I think i have a sufficent system...it allows for everything you guys have suggested so i think im in the clear....thanks!

ive split all animations up so that the largest sheet size is 1024x1024 but can be smaller or larger

the editor that i wrote has an animation editor which creates animation sets and allows you to specify an image per animation in the set.

it allows you to specify frame width/height..indexing position into the texture and the interval between frames. This all saves out to a file and is used by the object creator which just points to an animation file.

I think ill just keep the images small.

I chose the same row column method EDI did. The editor will allow me to go all the way down to 1 row per texture but the entire animation..say "north walk" has to be in the same image so im looking at a long strip instead of a large sheet.

Share this post


Link to post
Share on other sites
i like to keep my sprite files organized in the following manner
each column is a frame of an action from any direction
each row represents an action
as mentioned in the OP

so
[attack-dir N] [attack-dir E] [attack-dir S] [attack-dir W]
[walk-dir N] [walk-dir E] [walk-dir S] [walk-dir W]
[run-dir N] [run-dir E] [run-dir S] [run-dir W]

etc
then have enums representing the rows
so enum {ATTACK, WALK, RUN}
then reference your animation like

tommySprite[ATTACK, 1];
tommySprite[ATTACK, 2];

of course my sprite has a timer of some sort to limit the frame advancement rate

this being the most simple implimentation
if you have a really detailed game
i would consider doing an array of file pointers for each action in every direction
then load that into the array of surfaces representing the character
that way you dont have to store all the images all the time...
this would only be needed for large sprites though

Share this post


Link to post
Share on other sites
our systems are very similar...

the only difference is that i or my enums together...

i have an action and a direction which are ored together to produce a hash key which is then retrieved sooo

key = ATTACK|EAST;
frame = GetCurrentFrame(key, TimeSinceLastFrame);

Share this post


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