Why is the first sprite on top?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Why is the first sprite on top?

Post by DRW »

When the NES renders sprites, how come that the first sprites in memory are always on top of later sprites if they overlap?
Shouldn't it be the other way around?

If two sprites overlap each other, the one that is processed latest should be on top of the earlier one because its graphics are drawn over the earlier sprite.

How does the NES manage to draw, for example, sprite 5 below sprite 0, even though sprite 0 was the first that was processed?
Doesn't that mean that the NES has to keep track of every pixel and set a flag whether a specific pixel was already filled with a non-transparent color by an earlier sprite?
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Why is the first sprite on top?

Post by rainwarrior »

For each pixel, the PPU goes through its list of things to draw and it stops once the pixel colour is decided.

Sprites aren't really "drawn over" each other, this isn't like a framebuffer where each thing is an operation that writes to a pixel memory. It fetches the background colour first, then goes through the sprites. The first one with an opaque pixel is what it goes with, and then if the sprite has the "background" bit set it throws it away and keeps the background instead (if opaque). The rest don't matter, they aren't "drawn underneath", they're just ignored. (Though this is all kind of just a semantic difference anyway, but the ability for "background" sprites to mask foreground ones at least demonstrates that it's not simply an ordered layering.)

As far as whether a low number should have priority over a high number, that's kind of arbitrary anyway? It's probably just as easy to make a machine that "counts down" as one that "counts up". It doesn't really matter which, but it had to be one way or the other.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Why is the first sprite on top?

Post by FrankenGraphics »

It's almost a bit sad (not really) it is wired that way, because if lowest priority was drawn, you could more easily layer sprites for more than 3 colours, and then when overflow happens, just not render the topmost sprite, resulting in lower colour count (but still look like something). Try that as-is and you get transparency holes in your multicoloured metasprite during overflow. But i suppose it makes sense to "hide" lower priority sprites behind high priority ones in all other cases except this one.
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Why is the first sprite on top?

Post by Quietust »

Internally, the PPU uses a priority encoder to select which sprite to render for each pixel, and it happens to prefer them in ascending order (i.e. lowest index first).

If you're curious, you can look at the actual logic in Visual 2C02 - the logic for sprite 0 is around node 10708, and the others are to the left.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Why is the first sprite on top?

Post by Bregalad »

FrankenGraphics wrote:It's almost a bit sad (not really) it is wired that way, because if lowest priority was drawn, you could more easily layer sprites for more than 3 colours, and then when overflow happens, just not render the topmost sprite, resulting in lower colour count (but still look like something). Try that as-is and you get transparency holes in your multicoloured metasprite during overflow. But i suppose it makes sense to "hide" lower priority sprites behind high priority ones in all other cases except this one.
In NES' case, dropping higher priority sprites when more than 8 are present on the scanline would end up disastrous as sprite zero would be frequently dropped, making sprite zero hit - one of the only way to sync to the PPU without a mapper - unreliable.

Ignoring that issue I cannot think how dropping higher priority sprites would be an advantage or how it would enable you to have better graphics or whatever. It's mostly the same - sprites get dropped when there's more than 8.
Last edited by Bregalad on Mon Oct 23, 2017 1:27 am, edited 1 time in total.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Why is the first sprite on top?

Post by rainwarrior »

FrankenGraphics meant that if the draw order/layering was separate and reversed from the per-scanline priority, you could layer things with a "fallback".

Like, you could do a 3-colour base sprite, and then layer a "highlight" sprite of 3 more colours on top of it. The base layer would have highest priority for being visible on the scanline, so if the top layer drops out you'd still have a "complete" looking sprite just without the highlights. (e.g. mega man could have a blue face fallback underneath his regular face)

Instead with the way things are we have to cut holes in the base layer for the highlights to show through from "underneath", so when those drop out you get the transparent hole showing the background underneath.


Though, to be honest, we only have 8 tiles and any dropout at all is going to be a noticeable visual error in any case. A hole isn't really much worse than dropping out a layer like that, and since it's so often just a few scanlines rather than a whole tile anyway, it's almost always going to look ragged either way.

I actually think the side effect of the way it is that lets you use a "background" sprite to mask a foreground one is more useful than that hypothetical reverse layering would be.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Why is the first sprite on top?

Post by FrankenGraphics »

Yeah, it's probably for the better in almost all ways.

A way to get around it in games that do offer constantly layered sprites for a more colourful metasprite on, say, the protagonist, where the presentation cannot be guaranteed to be cancelproof, could be to offer an on/off setting in case the player doesn't like it. Have a good solid player character in 3 colurs. Then either add the highligts or come up with a wholly newly coloured 2-layer character. People using the AVS will not see any cancelling/flicker in its 16 sprites per scanline mode. Those who experience cancelling/flicker may choose whether to opt for the more basic but stable version or the advanced but sometimes/often breaking one.
Post Reply