Since the amount of hardware sprites required to build a meta sprite may change depending on the sprite of the animation, should I keep the maximum amount of hardware sprites the object can use reserved for it to prevent parts of it disappearing if something else spawns?
For example, in Metroid, Waver's sprite requires 4 hardware sprites most of the time. However the last animation sprite could fit in 2 hardware sprites and would free 2 hardware sprites for something else. But when the Waver's animation returns to use 4 hardware sprites, parts of it would probably disappear if something else has occupied the 2 hardware sprites it freed when changing to the sprite that only uses 2 hardware sprites.
So, should I keep the sprites reserved for the object or free them for something else? Also, if I render "blank" sprite on screen, would it affect to the 8 sprites per scanline limit since it's completely transparent?
Any other ideas or suggestions regarding this matter are very welcome.
A question about sprites
Moderator: Moderators
A question about sprites
UP SIDE DOWN A B A B B A B A Hidari migi
L R L R STOP & DASH & UP & TALK Ijou nashi
L R L R STOP & DASH & UP & TALK Ijou nashi
Re: A question about sprites
Most games completely rewrite the OAM every frame, instead of allocating specific OAM positions for each object. If you randomize the order in which the objects are drawn every frame, you'll get some flickering when 64 hardware sprites aren't enough but no object will disappear completely for several frames. You can certainly create a priority system, where some objects are processed first and never get left out.
My current approach is to randomize the order in which I process (and, consequently, draw) the objects, and I implement 2 sprite priorities: high priority sprites are drawn from index 0 and up, while low priority ones are drawn from index 63 down. High priority sprites are allowed to overwrite low priority ones if the both end up meeting in the middle. high priority sprites should be kept to a minimum, otherwise they could easily make low priority sprites permanently invisible. I use this only for very specific cases, such explosions that must be in front of another object or things like that.
My current approach is to randomize the order in which I process (and, consequently, draw) the objects, and I implement 2 sprite priorities: high priority sprites are drawn from index 0 and up, while low priority ones are drawn from index 63 down. High priority sprites are allowed to overwrite low priority ones if the both end up meeting in the middle. high priority sprites should be kept to a minimum, otherwise they could easily make low priority sprites permanently invisible. I use this only for very specific cases, such explosions that must be in front of another object or things like that.
- rainwarrior
- Posts: 8759
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: A question about sprites
That won't keep it from disappearing, and will make disappearance of other sprites more likely.Tsutarja wrote:should I keep the maximum amount of hardware sprites the object can use reserved for it to prevent parts of it disappearing if something else spawns?
To keep something from disappearing just make sure it is drawn first (i.e. appears earlier in the sprite list).
Re: A question about sprites
Okay thanks.tokumaru wrote:Most games completely rewrite the OAM every frame, instead of allocating specific OAM positions for each object. If you randomize the order in which the objects are drawn every frame, you'll get some flickering when 64 hardware sprites aren't enough but no object will disappear completely for several frames. You can certainly create a priority system, where some objects are processed first and never get left out.
My current approach is to randomize the order in which I process (and, consequently, draw) the objects, and I implement 2 sprite priorities: high priority sprites are drawn from index 0 and up, while low priority ones are drawn from index 63 down. High priority sprites are allowed to overwrite low priority ones if the both end up meeting in the middle. high priority sprites should be kept to a minimum, otherwise they could easily make low priority sprites permanently invisible. I use this only for very specific cases, such explosions that must be in front of another object or things like that.
One more question: How long does it take to copy the OAM from the given address when using OAMDMA ($4014)?
UP SIDE DOWN A B A B B A B A Hidari migi
L R L R STOP & DASH & UP & TALK Ijou nashi
L R L R STOP & DASH & UP & TALK Ijou nashi
Re: A question about sprites
OAM DMA always takes exactly 513 or 514 cycles. (Unless it collides with a DPCM DMA, in which case that steals an extra 2 cycles per byte in needs to read)
Re: A question about sprites
Might be obvious, but it doesn't hurt to say: this doesn't include the write to $2003 and the write to $4014, which have to be taken in consideration when you're planning how to use yourlidnariq wrote:OAM DMA always takes exactly 513 or 514 cycles.
VBlank time.