gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Several questions on making animated sprites

#155002 - Polaris - Wed Apr 23, 2008 9:35 pm

Recently I have been trying to make animated sprites and fortunately it wasn't much different from what I have originally envisioned. But still, I have several doubts about the whole thing.

First are the actual animation methods. I figured out two different ways of doing it.

The first one was loading all the tiles for any given sprite, and then changing the tileIdx property of the SpriteEntry asociated with them to achieve the animation.
The second method is very similar but instead of loading all the tiles at once, I just load the needed ones for each frame. So I end up doing a dmaCopy each time a frame goes by.

I'm assuming the first method is faster since it doesn't require to constantly make dmaCopy, but it also takes a lot more space in memory. Is the faster speed worth it? Or the difference is negligible?

With that out of the way I still don't know how should I use grit properly to convert my sprite sheets.

In the small test i'm currently doing, I figured out I needed to place all the frames of my animation making a column rather than a row in my .png file, so that grit would tile it properly for any of the two previous methods to work.

Which commads should I use so that I can have grit tile the image properly, regardless of how I choose to draw the frames in my image file.

Lastly there is the issue of having a game entity use different animations from the same sprite sheet.

So I thought about it for a moment and after some research I figured I needed two things in order to make this. First I should know where each individual animation starts and where it finishes(in the sprite sheet) and second, a state machine so that I can manage more easiely the transitions between each animation.

The state machine part sounds great. What doesn't sound so great is having to look at the sprite sheets and taking note of the numbers of the frames each animation starts and ends with.

I'm pretty sure it's going to work. Each state would take care of setting the current beginFrame and endFrame and then with those two crucial numbers I could set up a very crud Animation Manager to handle the animation code for every sprite.

Still there is a voice in the back of my head, it's mumbling, I want to shut it, but I can't. It's saying "Hardcoding........".

What would be a better aproach to get different animations out of a single sprite sheet?

#155007 - SevenString - Wed Apr 23, 2008 10:06 pm

Read in your sprite sheet (or a simplified version) from a fat text file or other similar mechanism at runtime, and parse it into your sprite animation data structure.

So your text file might say something like:

WALK_N 0 9
WALK_NW 10 19
WALK_W 20 29
...
...
...
ATTACK_N 80 89



and so on.

Read and parse through the lines of the animation sheet to load the various slots of your sprite structure with the proper frame values.

You could even get fancy and have a generic list structure in your sprite that allows you to add named animation types dynamically. Then you aren't hardcoding ANYTHING, and each character (or other) sprite type can have its own unique set of animations.

Going this route would allow you to expand or change your animation sets without having to change any of your animation management code.
_________________
"Artificial Intelligence is no match for natural stupidity."

#155009 - tepples - Wed Apr 23, 2008 10:10 pm

Polaris wrote:
The first one was loading all the tiles for any given sprite, and then changing the tileIdx property of the SpriteEntry asociated with them to achieve the animation.
The second method is very similar but instead of loading all the tiles at once, I just load the needed ones for each frame. So I end up doing a dmaCopy each time a frame goes by.

I'm assuming the first method is faster since it doesn't require to constantly make dmaCopy, but it also takes a lot more space in memory. Is the faster speed worth it? Or the difference is negligible?

Lots of games use the second method, including Battletoads on the NES and Sonic and Kirby on the GBA. Back in the early days of the GBA scene, I wrote a white paper about the second method. It still applies on the DS in 2D mode. But if you're using the 3D hardware to draw 2D sprites, the DS has a much smaller window of time to upload the textures.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#155031 - Polaris - Thu Apr 24, 2008 2:16 am

Thanks for the input guys.

SevenString: That is what I feared. I have used parsers in the past, and more or less understand what their purpose is. But I really don't have a clue as to how I should write one. I guess I should start searching on that.

tepples: I believe that anything that was used for BattleToads for the NES is proof enough that it should be used once more!

If by this line anyone is still reading, remember that the second question hasn't been answered :P

#155045 - M3d10n - Thu Apr 24, 2008 12:15 pm

You can safely use DMA for loading the animation frames on demand. Just make sure to do some double buffering to avoid having the sprite being drawn to the screen mid-copy: have the sprite alternate display one frame while you copy the next one to a different address, then change the ID to display that and copy the next frame to the previous address.