Allow putting sprite objects behind background

Most basic use would be Mario 3's white boxes, but I've seen also this used to great effect in the game Crystalis where it simulates player being able to go behind certain things, like tree tops or high ledges.

You could make monsters game objects that are not checked "monster", no speed, no acceleration, no actions... And if no bounding box set, I think the player can go behind or in front...
I think Joe made a video showing that, somewhere.

Just play Crystalis. Shit that game is doing can't be possibly done using just sprites.

I'm pretty sure the trick that Crystalis used is selective hiding of parts of the sprite.
If not that, then some other specific-to-Crystalis trickery.
It's important to remember that every game back in the days of the NES basically had its own custom engine programmed for it, so there are some things you see in games of the day that won't be possible without some seriously heavy ASM6 work in NESMaker, though you've probably heard that already.

But is it really behind the background?


Every sprite has a bit you can set that essentially draws them with the background color that appears below them. The caveat(and also the strength) is that they'll only appear "behind" pixels that aren't the universal background color. (The one shared color between all four background palettes.)

The last rule makes it somewhere difficult to use effectively. For example in Crystalis:

The grass has to be a solid color. If it were textured like the area the arrow points too, the texture would appear "above" the sprite as well.

Solstice does something way harder to get its sprites behind the background. It edits the sprite tiles themselves at runtime so that any pixel of the character that is meant to be behind the background is made a transparent pixel. (It has to put back the opaque pixels when the sprite comes out from under the background.)

So in Solstice the solid color rule does not apply. (But you should absolutely not expect this behavior to be done for you in a generic way, it is very hard for many reasons.)

Anyway, it's not very hard to set the bit for the first method, but what might be hard in a NES Maker context is allowing the user to define the areas where one wants this happen. (It's extra data to store in the level format/extra UI at the very least.)

Kasumi said:

But is it really behind the background?

Every sprite has a bit you can set that essentially draws them with the background color that appears below them. The caveat(and also the strength) is that they'll only appear "behind" pixels that aren't the universal background color. (The one shared color between all four background palettes.)

The last rule makes it somewhere difficult to use effectively. For example in Crystalis:

The grass has to be a solid color. If it were textured like the area the arrow points too, the texture would appear "above" the sprite as well.

Solstice does something way harder to get its sprites behind the background. It edits the sprite tiles themselves at runtime so that any pixel of the character that is meant to be behind the background is made a transparent pixel. (It has to put back the opaque pixels when the sprite comes out from under the background.)

So in Solstice the solid color rule does not apply. (But you should absolutely not expect this behavior to be done for you in a generic way, it is very hard for many reasons.)

Anyway, it's not very hard to set the bit for the first method, but what might be hard in a NES Maker context is allowing the user to define the areas where one wants this happen. (It's extra data to store in the level format/extra UI at the very least.)

Click to expand...

I've always wondered how games like Solstice, Battletoads, and SMB3 did that trick.

I am aware of the bit thing, but as you've said, without an ability to define areas in NM where you want it to happen it's pretty much useless and hard to do without major engine overhaul.

Kasumi,
That is a really interesting bit of information, thank you!