Order matters

Setting the priority bit ensures a sprite is displayed in front of others, but the level of layering afforded by this feature isn't nearly fine-grained enough for most scenarios.

In the above screenshot, Sonic appears behind the teacup lift, and the lift's grip appears in front of the purple screw. As they rotate around the screw, Sonic and the teacup alternate between going in front of both the grip and the screw, and then behind them. But when the lift passes through the floor, it goes behind the foreground plane, meaning the priority bits on all these sprites have to be off.

So what is happening here? Well, as we previously learned, the VDP renders the sprite layer by walking down a list of sprites and drawing them one by one. The order in which sprites are added to this list turns out to be quite important, because it defines the order in which they'll be drawn: sprites higher up on the list will overlap sprites further down.

Sonic games take advantage of this by tracking an additional value for each sprite, which is confusingly also referred to as "priority" in the current disassembly. Sprites are added to the list in the order of their priority: the lower the value, the higher up the sprite will appear on the list. Sprites with the same priority are generally added in the order they were first scrolled into view.

The priority value also affects the behavior of the sprite limit. Since sprites with higher priority are higher up on the list, when the limit hits, sprites with low priority are discarded because the VDP stops walking the list before getting to them.

In the above screenshot, since rings have higher priority than spikes, having more than eight of them aligned with the twelve pairs of spikes on the floor causes the sprite limit to kick in and discard the spikes on the far right, as those were the last to be scrolled into view. The enemy on the left has lower priority than spikes, so despite having been scrolled into view before them, it too gets discarded.