Skip to content

Guide: Basics of SNES Graphics Conversion

You are here:
Estimated reading time: 4 min

Guide: Basics of SNES Graphics Conversion

This seems to be a trivial topic. I mean what could be difficult? This “inferior” game console must have some simple internal graphic format, converter should be a breeze, right? Wrong.

First of all, here is a quick primer how SNES stores graphics:

The SNES PPU has a tile-based format. It does not support bitmaps but since the typical resolution is 32×28 tiles and the tile id is stored on a 10 bit number, it is more possible to fill up the whole screen with unique tiles. That’s 1024 tiles at max and a screen requires 896 tiles.

The PPU has 16 palettes, each of them has 16 colors. Color 0 is special in all entries, it is used as transparent if BG-s overlap. 

The tiles are fetched from a tile map, either 32×32, 32×64, 64×32 or 64×64 size. It is represented by 16 bits:

vhopppcc cccccccc

Where c is the tile id bits, ppp are the palette id bits, o is priority and v,h is used for flipping.

The tiles are represented by bitplanes. You may remember bitplanes from the Amiga days where planar graphics was used.

A pixel is established by 2,4 or 8 bitplanes which resulting byte points to a palette color within a palette entry. The palette is fetched from the palette bits of the tile map entry.

Except in Mode 3 (256 color, 8bpp, 8 bitplanes) mode only the first 8 palettes can be used, the rest is for the sprites. In 256 color mode it’s all in one. Good luck finding palettes for your sprites if there are no free slots.

As a consequence, the number of colors are limited per tile since each tile can have its own palette entry. Of course in 4 color mode it’s only the first 4 colors of an entry, in 16 color mode it’s all the colors and in 256 color mode it’s fetched sequentially from palette entry 0 color 0.

Right, even the primer is a bit long. Now let’s assume we want to convert a picture for Mode 1, 4bpp, 16 colors per tile.. The artist painstakingly counted the colors on the whole picture and it is below 128. Next he made sure each tile has 16 colors at most. Let’s see what a converter would do:

First of all, let’s count the colors. Let’s say it’s 121 RGB entries which is good.

Next let’s collect the colors per tile. It will be 64 entries since it’s 8×8 pixels for each tile.

Then let’s find only the unique colors. If they’re less or 16 then we’re good to go.

Now we have to shift our paradigm from pixels to bitplanes. Each pixel will be converted to a series of bits on 2,4 or 8 bitplanes. This is the first problem: a tile is only identical to another tile of the bitplanes match: it is not enough if the colors match.

Let’s assume for a moment we don’t care about redundant tiles. We go for 896. Now we have 896 unique palettes for each tile. We can have only 8!

Let’s also assume some of them are identical. Most likely only a few will be since the order we found the colors in will be different. Note that we’re still in RGB land but if we’re a bit clever, we already indexed them so we have 121 indices and not 121 RGB values to work with.

Ok, so some palettes are equal. Some has the same colors. 

  • Should we go and compare all palettes with all other palettes? 
  • Which palette should be our “base”? The one with most colors? All of them will have 16. 
  • Which is the most dominant? Can we tell? We could count the occurrence for each. 

What about sorting each palette by color? That would definitely help to spot the unique ones.

Color sorting is a whole science on its own. Hey that can’t be that bad, after all it is 8x16x3 bytes in the arrays of [8][16][3]. Let that sink in for a moment. This is what we’re aiming for, not what we have! 

After googling how color sorting works let’s decide on a naive approach, after all we only need it to be consistent within this picture. Let’s also go to BGR15 from here to lessen the combinations. If we’re lucky we sorted them. Now let’s find the ones that match. Note we have 896 palettes to go through. Are we below 8? Good! How big the chance is for that? ….not that great. The more variety the tiles have, the more non-unique palettes would be made. This is where current converters stop. It is already a great effort to get here and in most of the cases, like level graphics it’s already enough.

Color-sorting would make sure the tiles with identical palette would be truly identical (as far as palettes go, note we haven’t converted them to actual bitplanes but that’s not the part of this challenge). 

If most tiles have the same color set, we will be just simply lucky. Good for us, we may go with converting the original image color data to bitplanes, referring to the sorted and unique palettes we found. The end? 

Let’s say we did run out of the 8 palettes we can have. What now? One approach would be find the palettes which are subset of others. Let’s think about it for a moment. There are possibly more than 8 palettes. One or more can be a subset of one or more. Each of them has 16 colors. Let’s say 15 since we saved color 0. 

Simple comparing wouldn’t do. Also colors which are subset of others may be in any order. Also which palette(s) should be checked for subsets? All, with all (with all the color combinations).

Also palettes you find to be subsets could be candidates for other palettes supersets. You could end up in a worse situation or just finding a few to dispose.

It’s not so easy to convert graphics of this “inferior” platform after all, right?

What can we do then? How those games were even developed we love so much? 

The answer is simple: they didn’t convert a thing. They drew it while they were in full control of the palette. Even more so that they re-used some of the entries for sprites while at it.

Most likely they had a custom paint tool for that – or possibly done it straight on the SNES. Developer kits were really weird back in the day, had the most unimaginable features. Why would painting be different? The SNES had a mouse too.

Was this article helpful?
Dislike 0
Views: 11
Back To Top