Please help consolidate all info for pixel artists for SNES

[93143]

Number of color indexes available: 256, but many more on-screen colors were possible via color arithmetic for transparency effects.

It's also possible to use HDMA (automatic speed writes from a table, timed to happen during HBlank) to change colours between scanlines. In fact, HDMA can write to anything on the B bus, but writing to the VRAM port does nothing (unless the screen is blanked) and writing to object attribute memory just overwrites the size and high X bit of a set of four sprites that includes the last one accessed by the PPU (yes, there was actually a game that did this).

Technically there are 257 colour values stored by the PPU - the 256 colours in CGRAM, of which colour #0 is used for the main screen backdrop, plus the subscreen backdrop colour which is stored separately and normally only used for colour math (the whole idea of the subscreen is that it gets blended with the main screen with colour math). HDMA was often used to change one or the other of the backdrop colours for sky gradients and such, but you can write to any entry in CGRAM by using an HDMA channel in Mode 3 or 7 (no relation*) to write the desired index to CGADD (twice, because there are no 3-byte DMA patterns) followed by the actual colour word to CGDATA. There are 8 DMA channels, so you can change up to 8 colours per scanline as long as you have nothing else you want to do with HDMA.

The subscreen backdrop colour is a funny one. You don't write the whole x1B5G5R5 value to it at once. You write an RGB channel value, packed together with three bits that indicate which colour channels it applies to. So you can only change the entire colour in one shot if you want grayscale. And since there are no 4-byte DMA patterns that just target one address, you need a minimum of two HDMA channels to write an arbitrary colour to COLDATA.

So... if you see an artist trying to jam a sky gradient plus clouds and stuff into a 15-colour palette, tell him about HDMA.

...

Oh, and I should mention: You can't use colour averaging with backdrop colours. It will do additive transparency for those parts of the screen.

Also, sprites cannot be mathed with other sprites. They get rendered into a single layer before being sent to the colour math circuitry.

In fact, just read this: https://wiki.superfamicom.org/snes/show/Transparency

* The usual "Mode 7" etc. is the background rendering mode, specified in BGMODE. Here I'm talking about the DMA write pattern mode specified in DMAPx, which is totally unrelated.

The SNES allows for 2 scrolling layers, 1 sprite layer, and one non scrolling “window” layer typically used for the games HUD (life bars, score etc.).

That's a weird hybrid of the SNES and the Neo Geo you've got there. (Funny story: the Neo Geo didn't have scrollable backgrounds at all. There was the fix layer, used for the HUD, and there were sprites. Which could be shrunk, but not zoomed. It just had a ridiculous amount of sprite overdraw, so you could fake multiple scrolling backgrounds with sprites without getting dropout.)

The thing called "windowing" on the SNES is unrelated to the background functionality. It allows you to specify the left and right edges of a pair of clip windows that can be used to mask off any set of background layers, and/or the sprite layer, and/or colour math, either inside or outside the windowed region. Window combination logic can be OR, AND, XOR, or XNOR. If you want more than a vertical line, HDMA is crucial (you could use an IRQ instead, but there's not much point because not only is it less efficient, but if you're using all 8 HDMA channels the CPU has a lot less time left in HBlank than it otherwise would, so it could be hard or impossible to reliably fit anything else in). Super Mario World uses windowing plus HDMA to draw the keyholes. Star Fox uses windowing plus HDMA to draw the big round glowy explosions.

Each scrolling layer is made of 8x8 pixel tiles.

Actually, you can optionally use 16x16 tiles. This gives you bigger maps, but results in coarser palette mapping.

Each tile can be 16 colors, using one of any of the 4 available 16 color palettes.

There are 8 available 15-colour palettes (not counting the zero colours, which don't get used). Each 4bpp tile can use any one of them.

Okay, background rendering modes, with description (yeah, I got kinda ninja'd, but whatever):

Mode 0: four 2bpp layers. Each tile can use one of 8 2bpp palettes, which are apparently unique to each layer (ie: each layer has an entirely separate set of 8 3-colour palettes that each tile can pick from). Nobody used this.
Mode 1: two 4bpp layers and one 2bpp layer. Each 4bpp tile can use any of the 8 4bpp palettes, which occupy the bottom half of CGRAM (the top half is for the 8 sprite palettes, and for 8bpp layers). The 2bpp layer uses colours from the bottom two 15-colour palettes. This is the most popular mode.
Mode 2: two 4bpp layers, with offset-per-tile - essentially column scrolling, whereby columns of tiles can be vertically scrolled independently. You can also relocate tiles between columns, but why would you do that? Yoshi's Island uses column scroll for lava and for when you touch Fuzzy. You can combine this with horizontal scroll changes via HDMA to produce the illusion of rotation, though the illusion will break down if you try to go too far. Star Fox uses this for its backdrop (but not for the actual polygonal layer, which was rendered with the appropriate rotation angle in software).
Mode 3: one 8bpp layer and one 4bpp layer. The 8bpp layer can access all of CGRAM - except for colour #0, but since in this case colour #0 is the actual bottom of CGRAM it gets used for the main screen backdrop, which is displayed when all the layers on the main screen are transparent, so the upshot is that you can use all 256 colours. Often used for title screens.
Mode 4: one 8bpp layer and one 2bpp layer, with offset-per-tile like in Mode 2.
Mode 5: one 4bpp layer and one 2bpp layer, in high resolution (512x224 progressive or 512x448 interlaced).
Mode 6: one 4bpp layer, in high resolution, with offset-per-tile like in Modes 2 and 4.
Mode 7: one 8bpp layer, with a fixed-location 128x128-tile map and 256 tiles maximum, no flipping. This layer is subject to an affine transform as specified by the Mode 7 transform matrix and origin coordinates. By changing the transform parameters every scanline with HDMA (two channels to fully rewrite the matrix, one more if you want to change the origin), it is possible to do fancy effects such as perspective, as seen in F-Zero et al..

All 8bpp layers can be set to direct colour, wherein the 8-bit CGRAM index is instead interpreted as a B2G3R3 value, with the three palette selector bits (which are otherwise nonfunctional on 8bpp layers for obvious reasons) used as one extra bit each for R, G, and B (resulting in B3G4R4, kinda - the extra bits are from the tilemap and are thus at tile granularity rather than pixel). Except that since the tilemap in Mode 7 is 8-bit with no palette selection (or priority, or flipping), those extra bits are only available in Modes 3 and 4. AFAIK nobody ever used direct-colour mode.

Also, Mode 7 can be set to use two layers instead of one, but the pixel fetch is the same (so you can't do parallax or anything like that) and the only difference is that the top bit in the second layer is used as a priority bit instead of part of the colour index. This gives you pixel-perfect (well, texel-perfect) control of BG/sprite overlap. Oh, and mosaic works differently on the second layer...

Also, Mode 7 is the only hardware scaling/rotation effect available, unless you count offset-per-tile plus HDMA line scroll as rotation. You can only scale and rotate sprites in software, which is hard to do fast enough for action games (ask tepples and psycopathicteen for tips on fast sprite scaling and rotation respectively). Scaled sprites on SNES were typically just stored in ROM at multiple sizes and made to change size using ordinary sprite animation techniques.

HOW MANY TILES CAN BE USED FOR THE BACKGROUNDS?

1024 for each background in Modes 0-6. Tile pools for the different layers can be separate, overlapping, or identical, since they can be independently positioned in VRAM with 8 KB granularity.

Mode 7 can only use 256 tiles, since the tilemap is 8-bit in order to allow a very large (1024x1024 texels) map without using an inordinate amount of VRAM.

[Digression: Super Mario Kart never updates the Mode 7 tilemap during a race; this was the best way to do a 2-player mode, since the Mode 7 map is locked to a single position in VRAM and is way too big to rewrite mid-frame even with quite a large black bar across the middle (Super Mario Kart uses that black bar to update OAM so that sprites don't cross over between the Player 1 and Player 2 screens). So they simply jammed each race course into one map and set it to repeat tile #0 outside that area (your options in Mode 7 are: transparent outside the map, tile #0 outside the map, or repeat/loop the whole map. In Modes 0-6, the map just loops). Originally it was going to be a 2-player F-Zero game, but they couldn't get much of a sense of speed going in such a small area, so they made it a go-kart game, but then they decided that their go-kart racers were too samey and needed to be recognizable mascots, and the rest is history...]

Furthermore, Mode 7 uses a different tile format than the rest of the Modes, so you can't reuse tiles from Mode 7 in a different Mode in the same frame, even if there's an 8bpp layer in that Mode. You need a separate copy of the tile in the appropriate format if you want to do that. You can reuse sprite tiles as 4bpp background tiles, though, if the tile pool for the background in question overlaps one or both of the OBJ tables.

Good reference here: https://wiki.superfamicom.org/snes/show/Backgrounds

As said, you can indeed change BG modes between scanlines with HDMA or an IRQ. You can also (I'm pretty certain) change where in VRAM a background layer looks for its map and tile data - except for Mode 7, since both the map and the tile pool are fixed-position.

In canonical SNES graphics, each scanline is drawn in only one background rendering mode. Technically you can change the BG mode mid-scanline, but this results in visual glitching and is poorly understood, on top of being very CPU intensive; if you're an artist you have no business doing this. In other words, no fancy Mode 1 colour math right next to a rotating Mode 7 scene. I did this, but it ate half my CPU time and I had to fake some of the colour math with HDMA and eye strain because I needed to cover the glitching with sprites, and I'm still not sure I won't get visible dancing specks on the sprite layer once I start doing colour math in the Mode 7 area... my excuse is that I'm porting a game from a way more powerful platform and want it to look as accurate as possible, and the CPU time loss isn't as big a deal as it could be because I'm using a Super FX chip... note also that this stunt has not been tested on a 1CHIP or SNES Jr. and may very well fail...

On top of the 2 separate background layers, either of them can be individually sliced horizontally in order to add even more parts of the background scrolling at separate speeds to create the illusion or dept in scrolling games.

This is a good use for HDMA. You can change horizontal scroll quite easily with one HDMA channel per layer. In fact, you can change horizontal and vertical scroll (see Axelay) with one HDMA channel per layer.

The Mega Drive/Genesis has special features called "line scroll" and "row scroll" to help with this. The SNES doesn't need them because HDMA can do the same thing and more besides.

The SNES can have two sizes of sprites on the screen at once. WHAT SIZES ARE POSSIBLE OPTIONS?

8x8 and 16x16
8x8 and 32x32
8x8 and 64x64
16x16 and 32x32
16x16 and 64x64
32x32 and 64x64
16x32 and 32x64 (vertical flipping flips each half separately)
16x32 and 32x32 (vertical flipping flips each half separately)

Those last two were not documented by Nintendo and were probably either an unfinished feature or a side effect, like the "illegal opcodes" on the 6502.

Up to HOW MANY? tiles can be dedicated to sprites?

You can designate two 8 KB areas of VRAM for sprites. That's 256 tiles per OBJ table, for 512 total. The primary table is positioned with 16 KB granularity, and the secondary table is offset from it with 8 KB granularity. I believe the locations do wrap in VRAM, so you can put table 0 at the top of VRAM and table 1 at the bottom.

You can actually change the location of the sprite tile tables mid-screen with a write to OBSEL timed to happen in the middle of a scanline; the next line will use the new data locations (allowing you to access more than 16 KB of sprite data per frame, but not per scanline). The ideal use case here is a fixed layer of sprites that never move, as might be necessary if you wished to plaster a Super FX rendered layer over a Mode 7 backdrop, just to pick an example at random [*cough*]...

Note that mosaic (that blocky fade-out effect from Super Mario World) does not work on sprites.

1) All tiles for any given 4bpp layer WILL be displayed with the same single 16 color palette?
2) The 4 color (three plus transparent) layer will use only those three colors to draw all tiles?
3) All three layers would be made from tiles in the same tile-set image of up to 1,024 tiles images?
4) By changing a setting to 0, 1,2 etc, that's how you set which palette (color index range) each entire layer is using to draw it's tiles?

...yeah, all of those are wrong. But that should be evident by now.

The closest you got was in (4), but the "setting" in question is a three-bit value in the upper byte of every entry in the tilemap.

Anomie's register document is a relatively accurate and easy-to-read resource.

It was the basis for this, I believe: https://wiki.superfamicom.org/snes/show/Registers

I find it a massively useful resource; it has information that even the pages dedicated to a particular feature leave out.

[Bitbeam]

Thanks again very much everyone. I'm working on re-writing the document based on all your info and feedback and will post it back up tomorrow.
We're not finished, but I'm a heck of a lot closer than before your help.

I don't want to cover every possible combination, but I do want to make the most common and universally useful mode's settings, limits etc as clear and understandable as possible, then link to more in-depth resources (including this awesome community) so they can explore other options/modes as needed.

[HihiDanni]

I suppose I could be considered both a coder and an artist. Here are the observations I've made that are relevant to artists based on the technical details of the PPU.

First, you need to realize that because it's a graphics processor for a retro system, it is closely timed with the display of the TV because it doesn't store entire frames; instead the picture goes straight to the TV (the big exception being SuperFX which has a framebuffer on the cart). Because of this, it spends a fixed amount of time drawing each pixel of the screen. The background modes are the PPU's way of letting you decide how those time resources are spent. Do you want more colors? A higher layer count? Any special features? Each background mode has its own tradeoffs, and in the case of the high res modes, the tradeoff is reduced color depth and a lower layer count.

Mode 1 is the most used of the background modes because it has a good balance of layers and color depth. It has BG3, which can be used as a far background or a floating HUD (or both if you're creative). Having just three colors per tile on BG3 might seem limiting and even NES-like, but since this is the SNES, you can pick your colors from a 15-bit colorspace, which is great for low contrast art (something you'd want in the far background anyway). As for a HUD, if you want more colors in some areas you can always use sprites for that (or change one of the colors partway down the screen).

Speaking of the colorspace, the 15-bit range means that each individual RGB channel can have 32 different values. When selecting colors in your graphics program, it might be a good idea to quantize your RGB values to multiples of 8 (assuming the values range from 0 to 255).

Don't forget that you need to dedicate space in VRAM to the tilemaps for each layer. The smallest tilemap size is 32x32 and takes 2kB. If you want smooth horizontal scrolling you need the tilemap to be 64 tiles wide instead. Here is an example scenario:

BG1: 64x32, 4kB
BG2: 64x64, 8kB
BG3: 32x64, 4kB
For this configuration, the tilemaps need 16kB of VRAM.

Since the tilemap sizes and the memory regions for tile graphics are selectable per layer, the programmer will need to decide on a memory layout for VRAM before the artists have meaningful limits to work with.

[93143]

It may be relevant to note that VBlank DMA bandwidth limits how much information in VRAM you can change between frames. Unlike the NES, which with CHR-ROM and bankswitching could change out the entire tileset at any time, the SNES needs to send all graphics data to the PPU's memories, and VRAM and OAM can only be written during VBlank or forced blank (CGRAM is free during HBlank, but writing to it will obviously affect the appearance of anything below that point on the screen that uses the rewritten colours).

Bulk DMA is 165.5 bytes per scanline. An NTSC SNES has 262 lines per frame; a PAL SNES has 312. In other words, for a full 224-line-high display on NTSC, after you've updated OAM and CGRAM you have maybe 5 KB of bandwidth left over if your NMI code is very efficient (sending a few big chunks is better than sending a lot of little chunks, since you have to update registers in software for every transfer). For a full 239-line-high display on PAL, you've got something closer to 11 KB, because the frame is so much longer. Multi-region games are limited by NTSC bandwidth considerations.

One 4bpp tile is 32 bytes. One tilemap row or column (yes, you can set the VRAM gate to increment by the appropriate value, so you can write columns easily) is 64 bytes, or 128 bytes for Mode 7. Sprites are a bit annoying, because due to the way the data is arranged (OBJ tables are basically 16x16-tile squares, just like on the NES, which makes it easy to map out on graph paper) you can't write anything bigger than an 8x8 in one shot, so unless you're writing a string of 8x8s or can arrange to have a full 16-tile-wide chunk of sprite data to send, you have to use multiple transfers, one for each row of tiles.

If you run out of bandwidth, you can trim the screen vertically with forced blank to get more DMA time. Unlike the Mega Drive/Genesis, forced blank is always black, so you're basically letterboxing the image. Going to 192 active lines in NTSC nets you about 5 KB of extra bandwidth; ie: it nearly doubles.

...

(I just thought of this: note that since a full 8bpp tileset is 64 KB, you can never use all 1024 tiles in 8bpp mode unless you manage to make a bunch of your tiles double as map data, which is a pointlessly insane stunt in the general case.)

When selecting colors in your graphics program, it might be a good idea to quantize your RGB values to multiples of 8 (assuming the values range from 0 to 255).

Using multiples of 8 gets you the ZSNES colour bug, where the top value is 248 and everything looks dim. You want to either do X*(255/31) and round or else do a bitshifting trick that I forget but that supposedly gives ideal results:

Code: Select all

rounded: 0 8 16 25 33 41 49 58 66 74 82 90 99 107 115 123 132 140 148 156 165 173 181 189 197 206 214 222 230 239 247 255

shifted: 0 8 16 24 33 41 49 57 66 74 82 90 99 107 115 123 132 140 148 156 165 173 181 189 198 206 214 222 231 239 247 255

Or you could just use Posterize to 32 levels in GIMP; it's close enough.

Please note that pcx2snes (and possibly any program based on it) does chroma dithering in an attempt to preserve luminance. This can screw with your carefully-chosen colour values even if you quantized them beforehand. I use a custom converter tool I wrote in Matlab; it assumes the input is already properly quantized and just finds the closest 5-bit equivalent.

[creaothceann]

Only one game was 512x448 in-game: RPM Racing. Just about everything else was content with 256x224.

Some games used 512x224 for text, notably Secret of Mana 2's text boxes. (I suspect lots of Japanese games did it for rendering their fonts.)

A big limitation with 512x448 mode is that it's only available on Mode 5 and Mode 6

Can't you enable H=512 with 2133.3 and V=448 with 2133.0?

AFAIK nobody ever used direct-colour mode.

Actraiser 2's map screen and a somewhat hidden world map in SoM used it.

Using multiples of 8 gets you the ZSNES colour bug, where the top value is 248 and everything looks dim. You want to either do X*(255/31) and round or else do a bitshifting trick that I forget but that supposedly gives ideal results:

Code: Select all

rounded: 0 8 16 25 33 41 49 58 66 74 82 90 99 107 115 123 132 140 148 156 165 173 181 189 197 206 214 222 230 239 247 255

shifted: 0 8 16 24 33 41 49 57 66 74 82 90 99 107 115 123 132 140 148 156 165 173 181 189 198 206 214 222 231 239 247 255

Or you could just use Posterize to 32 levels in GIMP; it's close enough.

Just shift RGB555's bits 3 places to the left and copy the top 3 bits into the lowest 3 places. Converting back is just as easy.

Though 248 etc. is useful for editing: any color that has at least one 1 somewhere in the lowest 3 bits (e.g. #FFFFFF, #0000FF, #FF00FF) can't be a SNES color, so it can be used to e.g. indicate transparency.

[Bitbeam]

So, do I understand correctly that there's no such thing as translucent sprites overlapping solid sprites? The options are translucent sprites (only sprites using sprite palettes 4 through 7) over backgrounds or translucent background over all sprites that are beneath them?

Or is it just that you can't have a sprite with one blending effect on top of a sprite that's already using a blending effect of its own?

[HihiDanni]

I'm not familiar with the details, as this is something I still need to play with myself, but to the best of my knowledge...

On the SNES, the rendering is effectively done twice, first on the "main screen" and again on the "sub screen". The color math registers determine how these two are combined. You can enable or disable different layers on the two screens, and "sprites" are considered a single layer. If you have two sprites overlap, and the one above is affected by transparency, I believe it will "cut through" the sprite behind it.

Imagine that in your image program, you make a copy of all your layers, so you have two "versions" of your screen. This assumes that you have flattened all your sprites into a single layer first. Enable/disable the visibility of those layers as you like, then flatten the layers of each copy of the "screen" separately. Take the one that's above and give it an effect like "Add". That is more or less what's going on.

[creaothceann]

Sprites are rendered into a line buffer one scanline before they're displayed (this is why rendering is turned off for line 0). Although sprites have a priority setting, the only thing that matters for this pre-rendering is the sprite index.

While the SNES renders the current line, the line buffer is combined with the BG tiles that are loaded a few BG tiles in advance. This is where the BG mode and the sprite priorities are used.

[psycopathicteen]

A big limitation with 512x448 mode is that it's only available on Mode 5 and Mode 6

Can't you enable H=512 with 2133.3 and V=448 with 2133.0?

But then you'd need to merge 2 layers into 1, which would be even worse with colors and layers.

[Nicole]

H=512 and V=448 can be done outside of Mode 5 and 6, but with many complications, because it must be managed manually.

To have H=512, even and odd pixels have to be split into two layers, one on the subscreen and the other on the main screen.

To have V=448, even scanlines have to be shown on even frames, and odd scanlines have to be shown on odd frames, since it's interlaced (luckily 213f.7 tells you which field is currently being displayed).

[93143]

I'm sorry; I got carried away. Upthread, I posted:

As said, you can indeed change BG modes between scanlines with HDMA or an IRQ. You can also (I'm pretty certain) change where in VRAM a background layer looks for its map and tile data.

The first sentence is perfectly fine and describes a standard technique. However, while the second sentence is technically true, you should probably ignore it, for three reasons:

1) AFAIK changing BG data offsets during HBlank is still untested, and may not work (though as the parenthesis suggests, I would be very surprised if it didn't).

2) It wouldn't do much good in the most common BG modes, since 1024 tiles is a lot (enough to fill a 32x32 map without repeating tiles), and you can change scroll values between scanlines and update parts of a map independently.

3) The one BG mode in which changing data offsets mid-frame would be the most useful (256 tiles, no flipping, affine-transformed graphics so you can't multiplex a map with scroll changes alone) is also the one mode in which it definitely won't work. I have modified my earlier post to reflect this. The VRAM offsets of the Mode 7 tileset and tilemap are literally hardwired and cannot be changed short of physically modifying the console. Which (I grudge to admit) is not something HDMA is capable of...

[Nicole]

Wouldn't you typically do that when changing modes, though? If you're changing modes, you probably want different map and tile data too, so I can't imagine that not working.

[Optiroc]

There's a YouTube series that sets out to visually explain most graphical features of the SNES: RetroGameMechEX. It's far from finished at the moment of writing, but here's a timestamped link to a section explaining how palettes work.

[93143]

Wouldn't you typically do that when changing modes, though? If you're changing modes, you probably want different map and tile data too, so I can't imagine that not working.

Probably. But anomie doesn't list it as possible (the HBlank write flag in regs.txt is "?" for $2107-$210C) and I have no actual experience with switching between two modes when neither of them is Mode 7. So I, personally, shouldn't have made the claim.

Also, I had failed to mention that the Mode 7 data is immovable, which is kinda important, so a correction was in order regardless...

[Bitbeam]

Hi everyone, I've updated the document based on your feedback as best I could. Please read this new version and let me know if I've made any mistakes or if anything is worded in a misleading or confusing manner.

______________________________________________________________________________________________________________________________

Super Nintendo/Super Famicom

Graphical summary


Standard game resolution: Most games were 256x224. Higher resolutions up to 512x448 were possible but since higher resolutions caused slowdown, flicker, and/or had increased limitations on layers and colors (due to memory bandwidth constraints); the higher resolutions were used for less processor-intensive games, in-game menus, text, and high resolution images.

color range: The SNES uses 5 bits per color channel, providing a palette of 32,768 colors.

Number of color indexes available: 256, but many more on-screen colors were possible via color arithmetic for translucency effects. The three formulas for color overlay effects are additive, subtraction and average.

Background graphics color limitations:

There are 7 separate modes the SNES can use which offer very different and often complicated combinations of abilities and limitations. I'll only be covering the two most common and useful modes when the goal is multi-layered scrolling games.

MODE 1 allows for 3 scrolling layers, where 2 layers allow 15 colors (plus transparent) per tile and the third layer is three colors plus transparent per tile.
Every tile in each of the two 16 (15 and transparent) color per tile layers can pick from any of the eight 16 color palettes reserved for backgrounds, where palette 0 is color indexes 0 through 15, palette 1 is color indexes 16 through 31 and so forth.
The 4 color (3 plus transparent) per tile layer allows each of its tiles to pick from eight 4 index sub-sets of the first 2 16 color palettes... so, the first 4 color subset would be indexes 0 through 3, the second subset would be indexes 4 through 8.

MODE 3 allows for 2 layers of scrolling, where one layer is 15 colors (plus transparent) per tile and the other layer allows for each tile to use the entire range of 256 colors! (255 plus transparent) This mode is often used for title-screens. Keep in mind the cost of having each 8x8 tile being 256 color, it will eat up Vram much faster than 16 color or 4 color tiles, and a background later using 16 color tiles which can each use any of 8 total 126 color palettes means you can easily make 120 color layers at a far smaller cost, and this is before any use of the translucent color blend modes or other available very low-”cost” tricks to increase the number of on-screen colors. This is why most games use mode 1 over mode 3 for actual in-game levels. Also keep in mind, in mode 3, the second set of 128 colors (color indexes) are shared between the 256 color background layer and the sprites.

Each sprite can be set to be in front of or behind any of the the background layers.

Each scrolling layer is typically made of 8x8 pixel tiles, however you can opt to use a 16x16 tile mode instead, which would allow for level maps being twice as high and wide in pixels, but at the cost of each 16x16 tile grid section in the layer using one 16 color palette as opposed to the ability to pick a different set of 16 colors every 8 pixels across or down on the grid.

Each layer can use up to 1,024 tiles, limited by the amount of VRAM being used by all other graphical assets.

For all modes except mode 7 (not covered here) background tiles CAN be flipped horizontally or vertically OR BOTH at the same time!

On top of the separate background layers, any of them can be individually sliced horizontally in order to add even more layers of “parallax” (parts of the background scrolling at separate speeds to create the illusion or dept in scrolling games).


Sprites

Sprites: The SNES can display 32 fifteen color (plus a “clear” index for transparent pixels) sprites per scan line (row of pixels on screen).

The SNES can display 128 sprites on screen in total, but any more than 32 per scan line will result in some sprites not being displayed.

Each sprite can use any of the final eight 16 color palettes starting at color index 128 with the first color index of each 16 color palette being used for transparent pixels. Only sprites using the sprite palettes 4 through 7 (the last 64 color indexes in the 256 total color indexes) can participate in color math (translucency effects)

The SNES can use two sizes for its sprites at a time. Following are all the available sprite size option combinations:
8x8 and 16x16
8x8 and 32x32
8x8 and 64x64
16x16 and 32x32
16x16 and 64x64
32x32 and 64x64
16x32 and 32x64 (vertical flipping flips each half separately)
16x32 and 32x32 (vertical flipping flips each half separately)

The SNES lets you use a maximum of 512 8x8 pixel 16 color dedicated tiles at a time for sprites.

Sprites can be horizontally or vertically flipped or both at the same time!



Color math overlay translucency effects:


Any sprite which is using any of the sprite palettes 4 through 7 (the final 64 color indexes in the 256 color palette) can be set to a translucent blending mode. The three modes are:

1) Additive: This ads the color value of the sprite to the color value of the pixels in the Background layer under the sprite. This effect always makes color lighter. Great for mist, explosions, fire, magic, beams of light, etc.

2) Subtractive: This takes the color of the background layer under the sprite and subtracts the color of the sprite. This always produces a darker color. This is great for things like shadows, tinted glass, black smoke etc.

3) Average: This creates a 50 percent blend between the sprites colors and the colors in the background layer under the sprite. This effect is perfect for ghosts, light smoke, colored gas, or any other time you want something to look 50 percent translucent.

Not just specific sprites can be set to specific blending modes, entire background layers can be be set to blend modes. There are too many possible combinations to cover here, but the following web page explains it thoroughly: https://wiki.superfamicom.org/snes/show/Transparency


For more detailed technical references:
https://wiki.superfamicom.org/snes/show/HomePage
https://emu-docs.org/Super%20NES/General/snesdoc.html