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.

Coding > Effective Sprite Animation

#8739 - Snoobab - Fri Jul 18, 2003 9:11 pm

Hi Guys,

I've got a bit of a problem with sprite animation.

In a game I'm busy with I want to playback a explosion animation when a missile hits a enemy. I know of two ways which this can be done, firstly I could load all the animation frames into OAM memory via DMA(which uses a lot of precious OAM memory) and then just change the attritute2 of the sprite to point to the next frame in OAM memory. Or I could just overwrite the animation frame-by-frame(via DMA) which would mean I only have to set aside enough OAM memory for one frame of the animation. Here's my problem: Both methods work but the first method uses a lot of memory (animation frames are 32x32x256 sprites!) and when I use the second method there is a pretty big slowdown while the frame's are being copied/played back via DMA.

Have any of u run into a problem like this before?

Lastly, what is the best way to make a background continually scroll? Here my function is which does it for me:

Code:

void bg_auto_scroll(void)
{
   static u16 BGScroll = 0;
   
   WaitForVSync();

   REG_BG0HOFS = 100;
   REG_BG0VOFS = BGScroll;

   BGScroll --;

}



can it be improved upon?

Hope u can help,

Thanks.

- Ed.[/code]

#8747 - XeroxBoy - Sat Jul 19, 2003 1:37 am

Code:


u8 BGScroll=0; // Declare this as global or at the beginning of your main game loop or whatever.

// At the end of your game loop:

BGScroll--;
REG_BG0VOFS = BGScroll;



Nice and simple (though, likely too fast. You might want to have another variable count your frames and then only update the scroll every few frames).

As for the animation issue, I think DMAing it in would be the best way. So long as you don't have too many frames, it shouldn't be too slow.

#8821 - ampz - Sun Jul 20, 2003 11:52 pm

I don't see how DMA:ing in new sprites every V-blank would cause any slowdown at all. (you actually don't want to copy new data into OAM every frame as that will make the animations too fast. Every second, third or even fouth frame is more reasonable.)

I've written a game thing where I completely filled the OAM with animated sprites, all updated with DMA. No problem whatsoever. You must be doing something wrong.

OAM is not very large, so it's not that much data to update.

#8826 - tepples - Mon Jul 21, 2003 3:58 am

ampz wrote:
I don't see how DMA:ing in new sprites every V-blank would cause any slowdown at all.

My document "Managing Sprite Cel VRAM" (available on pineight.com and in gbadev.org's tools section) says you're right, unless the sprite cels are compressed. Then you may want to cache decompressed cels in EWRAM or VRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#8851 - Ninja - Mon Jul 21, 2003 6:47 pm

I have a sprite demo laying around somewhere that illustrates 32 32x32x256 sprites on the screen. Each one is animated, and is updated every vblank via DMA. The sprites displayed just fine, and changed frames way too fast.

#8854 - Snoobab - Mon Jul 21, 2003 8:22 pm

I must definatlly be doing something wrong! I think its my DMA macros. The animation is consists of 16 frames and is 32x32x256.

Thanks for your help.