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.

Graphics > frame rate and animation

#19903 - gbawiz - Tue Apr 27, 2004 9:17 pm

Hello,
Are there any tutorials which actually explain the purpose and use of sprite movement and animation.
Is there anything which can explain "properly" the use of moving a sprite on the screen and updating it's frames.
This subject seems to be quite a vague one wherever I look.

Thanks
GBAWIZ

#19918 - dagamer34 - Wed Apr 28, 2004 12:24 am

The easy, hacking way, is this:

You know there are ~60 frames each second (if you wait for a vsync each frame).

So, suppose you have 6 frames and want the animation to last 2 seconds.

1) You would divide the number of frames by the number of seconds (6/2 = 3) which means that every second you would display 3 frames.

2) Then you divide the number of frames each second by the number of frames you are going to display each second (60/3 = 20) and that gives you the number of GBA frames that should pass before you update to the next frame.

3) Take this number and create a counter. Increment it each frame, and if
the counter equals that number (in this case, 20), set the counter to 0 and load a new frame.

That's how I do it and it works pretty well.
_________________
Little kids and Playstation 2's don't mix. :(

#19928 - crossraleigh - Wed Apr 28, 2004 2:42 am

Some rarely mentioned articles by Diana Gruber have taught me a lot.

One idea I wondered about that you probably need not think about is of sharing entire animations between multiple sprites. Since even all of sprite RAM can be loaded in a V-blank (about 40 lines to do a 32K DMA from ROM), it makes more sense to have each sprite load its own single frame. When it's time to switch to a new frame, load it into the same spot as before.

See also http://www.pineight.com/gba/managing-sprite-vram.txt.

#19963 - Gopher - Thu Apr 29, 2004 12:05 am

crossraleigh wrote:

Since even all of sprite RAM can be loaded in a V-blank (about 40 lines to do a 32K DMA from ROM), it makes more sense to have each sprite load its own single frame. When it's time to switch to a new frame, load it into the same spot as before.


This is true as long as there are less objects on-screen using this sprite than there are frames of animation for it.
_________________
"Only two things are infinite: the universe, and human stupidity. The first is debatable." -Albert Einstein

#20001 - crossraleigh - Thu Apr 29, 2004 6:32 pm

Well, in memory usage, yes, it is less efficient to give each sprite it's own frame when there are more sprites than there are frames of animation. Nevertheless, some sort of reference counting must be implemented for sprites to share cel data (at least if the data is dynamically allocated), which is a pain, especially since 32K for 16bit graphics should be plenty.

So, if you can fit all your animations for a level in 32K, go for it. Do it before the level loads and the animations will be guaranteed to be there. If, however you need to allocate and delete cel data (like in most games), go with a single sprite to single frame match up.