A question about sprites

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
A question about sprites
by on (#137937)
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.
Re: A question about sprites
by on (#137938)
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.
Re: A question about sprites
by on (#137944)
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?

That won't keep it from disappearing, and will make disappearance of other sprites more likely.

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
by on (#138036)
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.


Okay thanks.
One more question: How long does it take to copy the OAM from the given address when using OAMDMA ($4014)?
Re: A question about sprites
by on (#138037)
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
by on (#138045)
lidnariq wrote:
OAM DMA always takes exactly 513 or 514 cycles.

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 your
VBlank time.