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.

Beginners > max sprites != max frames...right?

#19610 - CyberSlag5k - Thu Apr 22, 2004 9:35 pm

I know you can only have 128 sprites in OAM, but you can have more than 128 frames total for sprite animation, right? Like right now I only have one sprite but it has 4 frames of animation. I can still create 127 more sprites if I wanted to, correct?
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...

#19614 - alek - Thu Apr 22, 2004 9:47 pm

Yes, I think the 128 sprite limit applies for how many sprites you can have on one scanline at the same time

#19618 - poslundc - Thu Apr 22, 2004 10:09 pm

The rule is up to 128 sprites displayed on the screen in a single frame. What you do with those 128 sprites from frame to frame is up to you. The GBA has no innate concept of sprite frames.

(As was mentioned, the technical limit is 128 per scanline, but this is only if you want to get into unnecessarily complicated stuff.)

Dan.

#19629 - zazery - Fri Apr 23, 2004 12:10 am

CyberSlag5k wrote:
I know you can only have 128 sprites in OAM, but you can have more than 128 frames total for sprite animation, right? Like right now I only have one sprite but it has 4 frames of animation. I can still create 127 more sprites if I wanted to, correct?


If your using 4 OAM entries for your sprites you might want to consider updating just one entry for each frame of the animation. I would suggest using DMA to transfer it fast. What everyone else said is true too, I just wanted to point out that you can animate a sprite using one OAM entry. If you know this.. well then ignore my post.

#19637 - CyberSlag5k - Fri Apr 23, 2004 1:16 am

Quote:

If your using 4 OAM entries for your sprites you might want to consider updating just one entry for each frame of the animation. I would suggest using DMA to transfer it fast.


So instead of having those 4 frames loaded into OAM all the time (no matter which is currently activated), I just reload that OAM entry every time I switch frames using the DMA?
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...


Last edited by CyberSlag5k on Fri Apr 23, 2004 1:45 am; edited 2 times in total

#19638 - poslundc - Fri Apr 23, 2004 1:41 am

That is the simplest way to do it. That way you don't need to change an OAM entry's x and y coordinate, or almost any of its other settings. You just change it to point to the correct tile in VRAM for the current animation frame.

Dan.

#19640 - CyberSlag5k - Fri Apr 23, 2004 1:47 am

[quiote]
That is the simplest way to do it. That way you don't need to change an OAM entry's x and y coordinate, or almost any of its other settings. You just change it to point to the correct tile in VRAM for the current animation frame.

[/quote]

Compelling. I'll give it a shot after I familiarize myself with the DMA.

Thanks.
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...

#19645 - tepples - Fri Apr 23, 2004 2:56 am

Remember that there are THREE memory areas involved in animating a sprite:
  • VRAM, which contains sprite cel data, that is, the actual pictures that make up a sprite animation;
  • OAM, which contains coordinates, pointers into VRAM, and other information related to each sprite; and
  • EWRAM and ROM, used as a source of data copied into VRAM.
Some poorly written tutorials confuse VRAM and OAM. (FAQ time?)

Sprite cel VRAM has 1,024 entries, each 8x8 pixels in size at 16 colors. There are 128 entries in OAM, each for one sprite, which limits the number of sprites on screen without horizontal blank trickery to 128.

The two main ways of animating a sprite are
  • loading all cels beforehand and changing the sprite's pointer into VRAM each frame, or
  • associating one block of VRAM with each sprite and continuously overwriting that cel.
Choose which to use by evaluating your design's size/speed tradeoff, especially if you're compressing sprite cels.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#19647 - poslundc - Fri Apr 23, 2004 3:00 am

I wouldn't bother with DMA until you get the basics of sprite animation working. DMA is a useful tool but it is in no way necessary to animate a sprite.

And by the way, if you want to quote posts I suggest using the quote button the upper-right-hand corner of the message you are quoting.

Dan.

#19779 - sgeos - Sun Apr 25, 2004 3:38 pm

tepples wrote:
Some poorly written tutorials confuse VRAM and OAM. (FAQ time?)


I vote "kill them". I'll admit that my vote is biased- I'm looking to pick up some new undead minions.

-Brendan

#22306 - Marill - Thu Jun 17, 2004 11:06 am

tepples wrote:

The two main ways of animating a sprite are
  • loading all cels beforehand and changing the sprite's pointer into VRAM each frame, or
  • associating one block of VRAM with each sprite and continuously overwriting that cel.
Choose which to use by evaluating your design's size/speed tradeoff, especially if you're compressing sprite cels.


I am inclined to use the second method that is

"associating one block of VRAM with each sprite and continuously overwriting that cel"

Because I have a few sprites with more than 6 frames of animation, so if I were to lead all of them into the VRAM, I'll run out of space fast.

For overwriting the block of VRAM, what is the best method to do it? Use DMA?

thanks in advance for any replies!

#22308 - sgeos - Thu Jun 17, 2004 11:39 am

Marill wrote:
For overwriting the block of VRAM, what is the best method to do it? Use DMA?


Thats what I'd use.

-Brendan