It is currently Sat Nov 25, 2017 2:43 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Sun Oct 22, 2017 8:11 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1474
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?

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 8:30 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5843
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 11:52 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1024
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 2:27 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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.


Top
 Profile  
 
PostPosted: Sun Oct 22, 2017 11:42 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7274
Location: Chexbres, VD, Switzerland
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.

Top
 Profile  
 
PostPosted: Mon Oct 23, 2017 12:55 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5843
Location: Canada
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.


Top
 Profile  
 
PostPosted: Mon Oct 23, 2017 2:40 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1024
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group