I feel like
@StapleButter and
@DiscostewSM touched on why SNES 3D implementation isn't worthwhile and is very difficult.
View attachment 26747
Might as well make a big post covering all the oddities of SNES rendering, and why trying to apply 3D to it would be far more trouble than it's worth (try to ask how many people even use the 3DS stereoscopy).
So on the paper, the SNES gives you a maximum of 4 layers to work with (amount determined by which BG mode you use), and 128 sprites.
but then it should be easy to make all that 3D
... nope. There are a fair number of oddities that come into play.
1. Per-tile priority
On the SNES, individual tiles in layers can be given a different priority order.
For example, SMW uses this for midpoint/goal posts, to make it look like Mario is going through them. Applying 3D to that would completely ruin the effect.
This is also valid for many games, since they weren't designed to be rendered in a 3D fashion. They often use dirty tricks to achieve certain effects.
2. Color math
There are those nice graphes showing how layer/sprite priority works on the SNES. But there's another thing thrown in the mix: color math (basically add/sub blending).
How does this work? The PPU basically renders two separate screens (mainscreen and subscreen), each with its own set of layers. The two screens are then fused together, and how it happens is different depending on which layers the mainscreen pixels come from (basically you can choose to exclude color math from certain layers, in that case the plain mainscreen is rendered with no color math).
There are a variety of effects you can achieve with this mechanism, and quite a few of the possibilities would break 3D rendering.
3. Windows
This feature allows you to exclude layers from certain screen areas. It is also linked to color math: windows are applied on individual screens, before color math is done. But that's not all, windows can also control where color math happens.
4. Mid-frame PPU configuration changes
To push the limits of the PPU, many games change its configuration while the frame is being drawn. Possible uses include:
* changing BG positions midframe to simulate more layers (SMW does this with the topscreen HUD)
* or changing where the BG layers get their graphics from
* changing priority order is also a possibility if the game uses BG mode 1
* changing the BG mode midframe (mainly used to draw mode 7 sections. SMW uses this in boss fights)
* changing the mode 7 parameters (perspective effects are achieved by changing those at every scanline)
5. oh and quirky sprite ordering
Sprites have two priorities defined: sprite/sprite and sprite/BG. The PPU sorts sprites based solely on their sprite/sprite priority. The topmost sprite pixels are then merged with the rest according to their corresponding sprite/BG priority.
As a result of this method, "bad" sprite priorities can result in interesting effects.
Let's say you have two sprites, A and B, and a BG layer.
A appears in front of B. However, A is set to appear behind the BG layer, and B is set to appear in front of it. What happens if A and B overlap?
The PPU chooses the topmost sprite pixels, which in the case of the overlap, come from A. A is set to appear behind the BG, so... A obscures B all while still being hidden by the BG. Yep.
SMAS SMB3 uses this extensively (powerups coming out of blocks, venus firetraps, etc).
Long story short, SNES rendering isn't as simple as it may look, and it's nearly impossible to add 3D to it and have it look nice everywhere.
