This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

NES sprite vs. background priorities

NES sprite vs. background priorities
by on (#146092)
In this post, Espozo wrote:
... You know, just looking at the game, how the heck is the character partially behind and in front of the background like that? Behind them, there's more than one color, so it can't be something with color 0. (Watch the character walk behind spikes.)

Solstice software renders the characters to CHR-RAM, taking into account occlusion. Open the PPU viewer in FCEUX to see it in action.

It's also double-buffering the sprites, and running the game at 30hz, effectively, probably to make enough time for the CHR writes. When there's two monsters onscreen they seem to update one at a time, alternating (i.e. they're both running at 15hz, staggered). I'm not sure if it uses the black at the top/bottom of the screen for extra write time too.

This is all just a very simple AMROM mapper, by the way. You don't necessarily need fancy hardware like the MMC5 to pull of some pretty impressive rendering tricks.
Re: NES sprite vs. background priorities
by on (#146093)
Espozo wrote:
You know, just looking at the game, how the heck is the character partially behind and in front of the background like that? Behind them, there's more than one color, so it can't be something with color 0.

rainwarrior explained how Solstice actually does it, but there's another option if you can afford the sprites. The PPU resolves layer priorities in a quirky way: It first resolves any conflicts there might be between sprite pixels before solving conflicts between the winning sprite pixel and the background pixel. This means that if you place a mask sprite with higher priority (i.e. lower index) than the sprite you want to mask, but force the mask to be drawn behind the background (using the sprite priority bit), you can bring the background forward and effectively mask the sprite. Here's my attempt to illustrate the process:

Attachment:
kirby-masking.gif
kirby-masking.gif [ 10.99 KiB | Viewed 1728 times ]

What happens here is this: the green sprite has a lower index than Kirby, so it wins the fight between sprites. Then, when the PPU proceeds to draw the winning sprite, it detects that its priority bit says it must be behind the background, so instead of the sprite, the background gets drawn, masking Kirby.

This technique wasn't used very often, because the masks would quickly help reach the 8-sprites-per-scanline limit,. Off the top of my head, I can only remember Nightshade using this trick. Right at the beginning of the game, there are some columns in the foreground, and this technique is used to have Nightshade walk behind them.

Solstice probably didn't do it this way because many objects can be moved around freely in that game, so the masks are constantly changing.
Re: NES sprite vs. background priorities
by on (#146094)
I'm familiar with the effect, I just didn't think solstice would do that because of many parts of the background can overlap sprites. This is a bit random, but I first saw this effect was on the SNES on the entrance to Swanky's Sideshow in DKC3. (Look at the ropes to the tent.)
Re: NES sprite vs. background priorities
by on (#146152)
Isometric games have to deal with obscuring / overlaying objects sorted by depth as a matter of course. It's what makes or breaks this type of game. You can check out the unreleased Airball (on the NES even, if you wish), or Solstice II / Equinox on the SNES. The creators of Equinox had to wrestle constantly with sprite limits in each room of their labyrinths... Interview here: http://www.chrismcovell.com/secret/sp_Solstice2int.html