RE-RE-UPDATED! I once again updated the document below based on all your feedback and corrections, please re-read and let me know if anything's incorrect or misleading.

Hi everyone. I'm a long time pro pixel artist (and also SNES fan) and I'm working on rounding up concise and clear (artist friendly) info to help pixel artists who want to make authentic moc-ups and game art for the SNES. I'm also doing this for all the other popular classic consoles, but getting thorough and easy to understand info that artists can use in modern pixel art programs to make sure they are not using too many colors, tiles, sprites, blending modes, etc. is proving hardest of all for the SNES.

I want to create as clear and concise a document as possible (for artists) where every sentence offers definitive guidance for exactly what rules and limits to follow, without drowning, confusing or intimidating artists with lots of technical jargon.

The final document will eventually be a web page, with attached images, animations, examples, and links to communities like this, and also special thanks to anyone who helped improve or confirm or clarify any of the information. This information will also be distributed with the industry standard pixel art program, so It's my hope this will encourage and entice many of today's best pixel artist to fall in love with developing art and games for the SNES.

Here's (below) what I have so far, along with some all caps notes where I'm definitely missing information. Can anyone who's interested please suggest edits, additions and provide the critical missing info?

One question I'd love answered is, if I'm using a pixel art program which supports 256 color indexes, which color indexes should I use for background tiles, for sprites, etc, and especially for the mode 7 translucent color effects, is there a setting for layers in programs like Photoshop which perfectly or near perfectly simulates the effect, such as additive, subtractive, screen, multiply etc?

_____________________________________________________________________

Super Nintendo/Super Famicom

Graphical summary

Important: The SNES stretched its 256 pixel wide screen image horizontally, resulting in pixels which were wider than they are tall (not perfect squares). As almost all monitors these days use pixels which are very close to perfect squares, your artwork and the entire width of the screen will be wider running on the actual hardware or an emulator which compensates for this pixel aspect ratio difference. You can temporarily stretch your image from 256 pixels wide to 298 pixels wide to preview how your art will look once its showing on an actual SNES.

Standard game resolution: Most games were 256x224 in Japan, the US, and Canada. Other regions such as Europe, Africa and south America used PAL as opposed NTSC television standard and had a slightly increased vertical resolution (239 pixels instead of 224), but at the cost of games running 10 fps slower and the screen having a subtle but noticeable non-stop flicker due to a 50 FPS refresh rate instead of 60 FPS. The PAL versions of most popular games did not put use to the extra resolution so often just had a larger black bar at the bottom of the screen, nor did they compensate for the 10 FPS slow-down so the games actually ran noticeably slower. For these reasons, most emulators and re-releases of classic SNES games use the NTSC versions of the games. Higher resolutions up to 512x448 (512x478 for PAL) were possible but since higher resolutions caused “interlace flicker”, and/or had increased limitations on layers and colors (due to memory bandwidth constraints); the higher resolutions were used for less movement and animation-intensive games, in-game menus, text, and high resolution images.

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 8 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 7.

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 16 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 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). Also, if more than 34 8x8 tiles of sprite image are on a scan line, some sprite tiles will not be drawn.

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 16x168x8 and 32x328x8 and 64x6416x16 and 32x3216x16 and 64x6432x32 and 64x6416x32 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.

Not just specific sprites, but entire layers (screens and sub-screens) can be be set to blend modes, and this can be used to get around the limitation of only sprites with specific palettes being translucent. There are too many possible combinations to cover here, but the following web page explains it thoroughly: https://wiki.superfamicom.org/snes/show/TransparencyThe four modes are:

The four blending modes are:

1) Additive: This ads the color value of the sprite to the color value of the pixels in the Background layer which the sprite is overlapping. 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 the sprite is overlapping 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 the sprite is overlapping. This effect is perfect for ghosts, light smoke, colored gas, or any other time you want something to look 50 percent translucent.

4) Subtract then divide by 2: This creates very dark colors and is not used very often.

Each background in mode 0-6 can use 1,024 tiles, but 64 KIB is not enough video memory for, say, all three layers to have distinct tiles. The background in mode 7 can use 256 tiles.

Sprites can be flipped in either direction (horizontal or vertical) or both, as can background tiles in all modes except 7. But I imagine that vertical flipping was used less often because it's easier to preserve perspective and lighting with horizontal flipping than with vertical flipping.

The official sprite sizes are 8x8, 16x16, 32x32, or 64x64 pixels, yielding six combinations of the three.

Up to 512 tiles (16 KiB) of sprite data can be used at once. This is the second most common complaint against the Super NES by fans of the Sega Genesis, after the slower CPU.

Thanks so much for taking the time to help fill in these blanks. I'm sure lots of artists will really appreciate it, and hopefully, some excited artists will come this way as an eventual result of the finished document.

Here are a couple more questions:

1) Can any sprite be scaled or rotated regardless of overall mode, or must the game be in mode seven specifically for any scaling or rotating of background or sprite elements?

2) So, are you saying typically all three layers would share from the same 1,024 tiles and would just be using different palettes for those tiles? If so, do you know which color indexes should be used for each layer?

3) Are you saying in mode 7, tiles can not be flipped horizontally or vertically?

4) I think I read in mode 7, tiles are 256 color, is this right?

Thanks again, very much!

tepples wrote:

Each background in mode 0-6 can use 1,024 tiles, but 64 KIB is not enough video memory for, say, all three layers to have distinct tiles. The background in mode 7 can use 256 tiles.

Sprites can be flipped in either direction (horizontal or vertical) or both, as can background tiles in all modes except 7. But I imagine that vertical flipping was used less often because it's easier to preserve perspective and lighting with horizontal flipping than with vertical flipping.

The official sprite sizes are 8x8, 16x16, 32x32, or 64x64 pixels, yielding six combinations of the three.

Up to 512 tiles (16 KiB) of sprite data can be used at once. This is the second most common complaint against the Super NES by fans of the Sega Genesis, after the slower CPU.

Oh, and to repeat an important question. Does anyone know what math is used to compute the mode 7 translucent overlays? I need to know so we can figure out how artists can simulate this effect in art programs like Photoshop etc.

A blended pixel can contain contributions from only two layers at once: the "sub" layer and the "main" layer. The later enable registers control which layers are eligible for use as the "sub" layer or "main" layer and whether this applies inside or outside windows.

The blend modes can be combined with pseudo-hires, which fills the left half of each pixel with the unblended sub layer and displays the blending result only in the right half. With the low bandwidth of a composite video signal, the half-pixels end up blurring together, and use of S-Video or RGB component video was uncommon during the Super NES's lifetime.* For example, pseudo-hires in Average mode changes the main layer's opacity from 1/2 to 1/4:

The SNES provides a wealth of many different ways of doing the backgrounds, which could be a problem for accurately summarizing what's possible. But in none of them is a layer incapable of scrolling or explicitly reserved for a "window"...

Certainly the video mode that looks most like the SMD/Genesis provides for two 4bpp layers plus a 2bpp layer.

The SNES provides a wealth of many different ways of doing the backgrounds, which could be a problem for accurately summarizing what's possible. But in none of them is a layer incapable of scrolling or explicitly reserved for a "window"...

Certainly the video mode that looks most like the SMD/Genesis provides for two 4bpp layers plus a 2bpp layer.

Sprites can be put between any pair of background layers.

Thanks for the info, for this 3 layer mode, If I understand correctly, 2 of the layers are 16 color (15 plus clear) and 1 layer is 4 color (3 plus clear). This means all tiles on those layers would all have to use the same 15 colors, right, and 3 colors for the 3 color layer? In other words, each tile can't have its own 16 color palette on those 4bp layers, right?

I think the non scrolling "window layer" thing is something I forgot to delect when I was changing a Megadrive document to make the SNES one. I'll be sure to remove that, thanks.

Each 8x8 pixel map entry in a 2bpp or 4bpp background is 16 bits. Three of these 16 bits form a bitfield for which part of the palette shall be used for those 16 bits, which can have a value of 0 to 7.

For 2bpp backgrounds in modes 1, 3, and 5, as well as the first background in mode 0, 0 means colors 1-3, 1 means colors 5-7, 2 means colors 9-11, ..., and 7 means colors 29-31. Mode 0 is special in that each of the four background layers gets its own set of eight sets of 3 colors.

Each entry in OAM also has 3 bits for palette selection. These always correspond to 129-143, 145-159, 161-175, ..., and 241-255.

Thanks for the help, tepples. I'm hoping to completely avoid words like bitfield and generally use much more plain English. IU'm not sure I understand what you posted and that lack of confidence is exactly what I'm trying to eliminate for myself and other artists.

Towards those ends, do I understand correctly that you've verified my assumption that in mode 1: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?

Thanks again, very much for helping to clarify all this

tepples wrote:

CGRAM is 256 entries.

Each 8x8 pixel map entry in a 2bpp or 4bpp background is 16 bits. Three of these 16 bits form a bitfield for which part of the palette shall be used for those 16 bits, which can have a value of 0 to 7.

For 2bpp backgrounds in modes 1, 3, and 5, as well as the first background in mode 0, 0 means colors 1-3, 1 means colors 5-7, 2 means colors 9-11, ..., and 7 means colors 29-31. Mode 0 is special in that each of the four background layers gets its own set of eight sets of 3 colors.

Each entry in OAM also has 3 bits for palette selection. These always correspond to 129-143, 145-159, 161-175, ..., and 241-255.

So, I'd assume the only limitation it would impose is that obviously, all art would need to be twice as many pixels to be the same size, and therefore twice the data. (twice as many sprite and bg tiles would need to be used)

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?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?

Every 8x8 tile can pick one of eight palettes.

In "mode 1", which is the one with two 4bpp layers and one one 2bpp layer, the two 4bpp layers select from the same library of 15×8=120 colors. Meanwhile, the 2bpp layer selects palettes from a subset of the first two 4bpp palettes.

I want to create as clear and concise a document as possible (for artists) where every sentence offers definitive guidance for exactly what rules and limits to follow, without drowning, confusing or intimidating artists with lots of technical jargon.

That's going to be difficult (the limitations may not be clear until one actually tries to build a ROM that displays the scene in mind), but it should be possible to come close.

Bitbeam wrote:

if I'm using a pixel art program which supports 256 color indexes, which color indexes should I use for background tiles, for sprites, etc, and especially for the mode 7 translucent color effects

BG tiles can be fetched and displayed in 8 different ways (BG Mode 0-7, see register 2105). Each mode defines how many BG layers can be used, what their bit depth is, the order in which BGs and sprites are interleaved, and if there's Offset-Per-Tile mode available (not really relevant for your purposes).

The info for each BG tile is stored in a tilemap. There are 3 bits ("ppp") per tile to specify the range of the global palette that can be actually indexed with the actual tile data. For example, the tiles of a 4-color BG can use colors 0..3 when ppp=000, colors 4..7 when ppp=001, 8..11 when ppp=010 and so on. For 256-color BGs these bits are useless for this purpose, but a game can enable "Direct Color" mode to mix the graphics data in another (hard to use) way.

Many video parameters can be changed during the TV's horizontal retrace! So you could have BG Mode 3 for the first 100 lines and BG Mode 1 for the rest of the screen. Super Mario Kart for example switches to Mode 7 after displaying a 2D landscape.

Bitbeam wrote:

Higher resolutions up to 512x448 were possible

512x478 in PAL mode, though lines at the top and bottom are cut off when displaying that mode on a NTSC TV.

Bitbeam wrote:

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

And Direct Color mode.

There's also a separate "screen brightness" register that can influence the colors.

Bitbeam wrote:

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.). Each scrolling layer is made of 8x8 pixel tiles. Each tile can be 16 colors, using one of any of the 4 available 16 color palettes.

Mode 1 can optionally display BG3 on top of everything else; most games used that for the HUD. There are 2 "windows" (i.e. two pairs of x-coordinates); depending on the screen settings these windows can define pixels with special treatment, e.g. where color math is disabled, or even where no color at all is displayed. Many games changed these coordinates per line to create level transition effects, e.g. Super Mario World's shrinking circle.

Bitbeam wrote:

Unlike 8 bit consoles, there is not a fixed number of unique tiles that can be used, as you can store tile images in any part of available vram.

There's a fixed number of bits reserved per BG/sprite tile to select the starting tile from VRAM: 10 bits (1024) for BGs and 8 bits (256) for sprites. Mode 7 can have only 256 8bpp tiles due to its memory layout.

Bitbeam wrote:

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

See register 2101.

Bitbeam wrote:

Can any sprite be scaled or rotated regardless of overall mode, or must the game be in mode seven specifically for any scaling or rotating of background or sprite elements?

The hardware can only flip/mirror sprites. Scaled and/or rotated sprites have to be stored in ROM (Super Mario Kart), calculated on-the-fly (Yoshi's Island iirc), or simulated with Mode 7.

Bitbeam wrote:

So, are you saying typically all three layers would share from the same 1,024 tiles and would just be using different palettes for those tiles?

The tilemap and "character" (tile data) address can be selected for all sprites, and for each BG separately.

Bitbeam wrote:

I think I read in mode 7, tiles are 256 color, is this right?

Yes, unless EXTBG is enabled.

Bitbeam wrote:

Does anyone know what math is used to compute the mode 7 translucent overlays?

Same as any other mode.

There is one set of registers that controls the "Main Screen" settings. You can for example enable BGs for this screen, and they render pretty much as expected. You can also specify that BG1/BG2/BG3/BG4/sprite and/or backdrop pixels on the Main Screen should participate in "Color Math". This means that a second set of registers specifies a "Sub Screen" that is normally invisible, but when a pixel on the Main Screen has color math enabled, the Sub Screen pixel's colors (or a fixed color) can be added to or subtracted from the Main Screen pixel's colors, clamping the result and optionally halving the result. This is usually how transparencies are achieved.

This means that the SNES renders 512 pixels per line, 256 with the Main Screen registers and 256 with the Sub Screen registers. Normally games use the 256 "dots" per line mode, and select Color Math when appropriate. They can also switch to 512 pixels per line mode, in which the pixels of the two screens are displayed next to each other (Sub=left and Main=right). Color Math can still be enabled, but the result is probably not useable...

You want plain English. Are you willing to accept a simplified set of constraints that is similar to that of the Super NES in the most common modes (1 and 7), or do you want an exact description of every constraint in every background mode, such as what happens if you try to share tile memory between a 16 color (4bpp) plane and a 4 color (2bpp) plane or try to share map memory between two planes?

Bitbeam wrote:

1) All tiles for any given 4bpp layer WILL be displayed with the same single 16 color palette?

No. There is one background color, and there are eight sets of 15 colors. Layers 1 and 2 share the same set of eight palettes. A single layer can use all of the palettes, with palettes assigned to 8x8 pixel areas of each layer.

Quote:

2) The 4 color (three plus transparent) layer will use only those three colors to draw all tiles?

The 4-color layer in mode 1, commonly used, can use sets of 3 colors from first two 15-color palettes. Each 8x8 pixel area of the layer chooses which palette is used.

Quote:

3) All three layers would be made from tiles in the same tile-set image of up to 1,024 tiles images?

The third layer, commonly associated with the HUD, usually uses a completely separate set of tiles because the data format for 2-bit-per-pixel (3 colors plus transparency) differs from that for 4-bit-per-pixel (15 colors plus transparency) tiles. You can probably count on there being enough video memory for 256 to 512 unique 2bpp tiles for layer 3, after subtracting those used by layers 1 and 2 and the sprites.

Quote:

So, I'd assume the only limitation it would impose is that obviously, all art would need to be twice as many pixels to be the same size, and therefore twice the data. (twice as many sprite and bg tiles would need to be used)

Sprites are not hires in the sense of mode 5. Or if they are (interlaced sprites bit turned on), they are not horizontally hires.

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

Of the 256 colors, the first 128 are typically used for backgrounds, and the 128 are used for sprites. For 4bpp layers, the 128 colors are divided into 8 palettes of 16 colors. For 2bpp layers, they typically use the first 32 colors, divided into 8 palettes of 4 colors. In Mode 0, each layer gets it's own set of 32 colors.

Quote:

There's a fixed number of bits reserved per BG/sprite tile to select the starting tile from VRAM: 10 bits (1024) for BGs and 8 bits (256) for sprites. Mode 7 can have only 256 8bpp tiles due to its memory layout.

I added some important details to this list. A big limitation with 512x448 mode is that it's only available on Mode 5 and Mode 6, both of which have less colors and layers compared to 256x224 modes. You can do Mode 5 and Mode 6 in 512x224. Although you can't have 512 pixels wide resolution of sprites, you can have interlaced sprites, but they take up more memory.

Who is online

Users browsing this forum: Yahoo [Bot] and 8 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum