I know from reading the docs, wiki etc.. that there is an 8 sprite per scanline limit. If you hit that $2002 bit 5 is set.
According to the wiki, only the first 8 sprites per scanline are used.
My understanding is that if you exceed the 8 sprites, a slowdown occurs, and often there is a flicker, since only the 8 with the highest priority (in terms of their order in the sprite ram) are drawn.
My question is:
Is the slowdown/flicker based on the number of sprites, or the number of pixels drawn? Meaning, will the slowdown disappear if the sprite is behind the background, or another sprite.
It seems like managing these sprites can get complicated. Is there a preferred technique I should be using, or is this all part of the "engine" writing process?
Al
Question about Sprites and the 8 per scanline "law"
Moderator: Moderators
Slow down has nothing to do directly with the 8 sprites limits. Game slows down when too much objects are active on screen because the CPU can't complete the frame in time. When too much objects are active chances happens that they are on the same scanlines and that result in glitchy sprites.Is the slowdown/flicker based on the number of sprites, or the number of pixels drawn? Meaning, will the slowdown disappear if the sprite is behind the background, or another sprite.
Useless, lumbering half-wits don't scare us.
Flickering sprites is the game dealing with the 8 per line limit. It is giving different sprites a turn being drawn. If your game doesn't do anything, then the 8 highest priority sprites are drawn and the rest are just invisible/not drawn.
I would agree dealing with how you handle sprites in your game engine is a big task at first.
I would agree dealing with how you handle sprites in your game engine is a big task at first.
Re: Question about Sprites and the 8 per scanline "law&
As it's been said, slowdowns and sprites are completely unrelated. It just happens that the flickering is more easily noticed by us humans when the game does it at a slower rate. So, because the CPU is busy handling so many active objects at a time, the game slows down, and since there are many active objects, chances are some of them will share a couple of scanlines, breaking the 8-sprite limit.albailey wrote:Is the slowdown/flicker based on the number of sprites, or the number of pixels drawn?
No.Meaning, will the slowdown disappear if the sprite is behind the background, or another sprite.
The usual solution is to not render the sprites sequentially when you write them to OAM memory. Rendering them in a seemingly random order will result in flickering when the 8-sprite limit is reached.It seems like managing these sprites can get complicated. Is there a preferred technique I should be using, or is this all part of the "engine" writing process?
There are many ways to accomplish this... you can write them linearly and then shuffle them around, you can start at a "random" slot and advance an odd number (such as 17) of slots after writing each one, you can process the objects in random order instead of rendering sprites that way...
The flickering is the least complicated thing to handle when rendering sprites. It only gets really complicated when you want to cycle their priorities but at the same time you want to have control over the priority of SOME sprites (such as an explosion that MUST be in front of an object).
In my game, I fill the OAM linearly, but the objects can specify at what end of it they'll be, so that objects at the high priority end will always be on top of the others (which means I have 2 "virtual sprite layers", although high priority sprites shouldn't be abused, or the lower ones won't have a chance). Also, the objects are processed in random order, so that they constantly switch priorities. This system appears to work well, although I haven't experimented that much with objects in my game yet.