nesdev.com

In Mode 1, which seems to be what is most commonly used, you get the 2bpp BG3 layer.
According to the Background Priority Chart here it can either go on top of both BG1 and BG2 or underneath them.

In Yoshi's Island there are tons of places where BG3 is in between BG1 and BG2 which is not listed in that Priority chart. At first I thought, well, that has the SFX2 chip, maybe they got some extra shit in there for better BG prios.

But in stage 1-2 of Hagane, which to my knowledge has no extra chips, the BG3 is also in between BG1 and BG2.

Is there some mistake in that documentation, or am I missing something?

I'd really need precise explanations of where to find this in both titles to verify. I'm not aware of what you describe.

Here's a different depiction of the rendering order/background priorities (and flags), including where OBJ fits in.

Here's a previous instance where "BG3 in the middle" was discussed: viewtopic.php?p=175293#p175293

This is Hagane Stage 1-2


The purple liquid and the shadowing effect is done with BG3. The main bg is BG2 I think and then BG1 in the front.

Stage 1-3 of Yoshi's Island is the most extreme situation I have seen so far. Where BG3 is behind, everything, in the middle and in front of everything at the same time at different Y offsets.

Check this video to see it in action. The clouds, foreground bushes and green mid layer with the purple palmtrees are BG3
https://youtu.be/XMf3IM3sgTg?t=20m46s

Probably done as described in the thread lidnariq linked to.

Yeah, some interesting stuff.

I find the SNES graphics limitations really attractive, speaking as an artist. And would love to work on a proper SNES project at some point. No time for that right now though, since I am already working on a Wonderswan Color project in my freetime.

Not as a programmer!

Haha, yeah, I have heard that the SNES is pretty finicky to program, esp if you want fast action kinda stuff.

But the amount of palettes and such is very nice and I like optimising palettes to get the most out of them, etc.

At least I figured out a way to balance VRAM when there are a lot of animated sprites onscreen. The only downside is it makes it harder to have individual sprite movement within an object like a grappling hook, or a shaking chandelier.

Are you doing the linked list method thing that I'm doing to? Yeah, I'm really not too sure what to do about that, other than make the grappling hook or whatever its own object.

Progress for me has been slow, mainly due to laziness. I'm trying to get the "next tile" functionality of metasprites to work after I went back to 16x16 and 32x32. After that, I have to make the animation engine, but that shouldn't be near as finicky as the vram engine. That is probably the single hardest thing to make I can think of.

Oh yeah, swapping colors per scanline for sprites is going to be difficult to. I've had the sorting part made, but I could never see if it worked (outside of the SNES not crashing) because I never had made the code that actually changed the colors. I'll feel much better when I get all of this crap done and I can actually get to things that relate more to game logic instead of messing with video hardware.

Thank goodness the game I'm working on doesn't require a general solution. I get to hardcode everything...

...including a bunch of 4bpp graphics that need to have more than 15 colours while using a minimum of overdraw and no more than one DMA channel, and may require me to either kill my eyes/neck scheduling the HDMA manually or rent time on a quantum computer (or improve my Matlab algorithm, which I currently outperform quite handily)...

Wait, what?

I mean better results, not faster. Matlab's slow, but it's not that slow.

I originally designed the algorithm for full-screen 8bpp graphics with all 8 HDMA channels targeting CGRAM, which is a scenario well beyond what I'm willing to inflict on myself. When I gave it a smaller, tighter problem (a medium-sized graphic targeting 4bpp with one HDMA channel) it was unable to handle an acceptable-looking number of colours, and when I fed it my manually optimized version, it failed to reproduce the HDMA schedule I had devised.

Sorry but this is absolutely impossible. The only way this is possible is using clipping effects with windows clipping or translucency effects (i.e. colour math).

Wouldn't those two methods you mentioned mean it's possible?