The VG Resource

Pages: 1 2

Common knowledge dictates that the SNES (Super Nintendo Entertainment System) and GBA (Game Boy Advance) used 16-bit graphics, right? Well, unfortunately, common knowledge, in this case, would be mistaken--the SNES and GBA actually, in fact, worked in the 15-bit color range.

A friend of mine, SomeGuyNamedDavid (he doesn't have an account on this website), gave me the complete list of values for 15-bit colors. They are as follows:

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, and 255.

These are the possible SNES and GBA color values for Red, for Green, and for Blue. Take any three of the numbers above (even if the three numbers you choose are all the same number, or even if two of the three numbers you choose are the same number) to make a composite RGB (short for Red, Green, Blue) color value that falls under the 15-bit color range.

Another friend of mine, DragonDePlatino (you all may be familiar with him), gave me the nitty-gritty details of the sprite limitations for the SNES and the GBA:

DragonDePlatino Wrote:SNES restrictions:
256x224 resolution
15-bit color
16 colors per sprite
If background has 1 layer, 16 colors a 16x16 tile.
If background has several layers, 4 colors a 16x16 tile

GBA restrictions:
240x160 resolution
15-bit color

I would like to add that another SNES restriction is 4 layers per background maximum. One of those 4 colors on that layer's 16x16 tile can be transparency if not the bottom layer.

One final note regarding SNES sprite limitations: when counting the number of colors per sprite or background layer, you must keep in mind that the number of colors includes transparency as one of the colors. So unless your sprite is a square with no transparent parts; you can only have 15 non-transparent colors per sprite or 3 non-transparent colors per 16x16 background tile (if the background has more than one layer). In the case of backgrounds, the bottom layer will never have transparent parts, so it will be 4 colors per 16x16 tile of the bottom layer if you're using multiple layers, or 16 colors per 16x16 tile if you're using only a single layer.

Other than that, everything else about spriting in SNES style or GBA style follows the norms of spriting as explained in the Spriting Dictionary thread.

Stickied.

One thing that always bothered me is that the RGB values aren't perfect multiples of 8. Why? That makes it a lot cleaner to look at for one, lol. That's what I personally do for my colors in RGB.

Another thing to note is, the whole background and sprite layer limitations things; it's really not necessary to pull off the 16-bit aesthetic. Same with NES or GBC styles; just following the four colors per sprite/tile rule (with one transparent where necessary) gets you the 8-bit style. Following the other arbitrary limitations doesn't add anything of value to the style. And animation doesn't need any limitations at all; you can have an 8-bit style with smooth animations, as seen with many true 8-bit titles. Just take your time and polish everything to the maximum under the color limitations per sprite/tile only, and you'll be fine.

This isn't strictly true.

Quote:256x224 resolution

This is nitpicky, but... Mostly yeah. The games released in the PAL region were 256 x 240. Compare the Super Mario World US and Europe versions' title screens:
[Image: tuNRqAV.png]

The SNES also supports "Pseudo High resolution mode" and "High resolution mode" which effectively doubles the resolution either horizontally, or in total. Kirby's Dream Land 3 uses Pseudo High Resolution mode, and it's evident in the foreground trees:
[Image: rh2NA3e.png]

RPM Racing is to my knowledge the only game that uses the "True" High Resolution mode this extensively, and it looks pretty cool indeed. Mind you, this looks like an early Windows game but it is still running on a real SNES.
[Image: 0bJPVs7.png]

the game is shit though

Quote:15-bit color

SNES 4bpp graphics are indeed "15-bit", but in the ROM, they're 16-bit with the first bit ignored, so that's five bits for blue, five for green, five for red.
0BBBBBGG GGGRRRRR. This is the most straightforward guide. There are eight 16-color palettes available to sprites.

Quote:16 colors per sprite

16 colors per 8x8 or 16x16 sprite, yeah. These can be "stacked" à la Mega Man (NES) too, though. The SNES can handle only 128 sprites onscreen at once.

Quote:If background has 1 layer, 16 colors a 16x16 tile.
If background has several layers, 4 colors a 16x16 tile

Kinda I guess. The SNES operates on graphic Modes. Most of us are only familiar with the fabled Mode 7, but our friend wiiqwertyuiop from SMWcentral explains the whole mess pretty well:

wiiqwertyuiop Wrote:Well I'll start with mode 7, since its the most talked about one and most overrated one.

Mode 7 - Allows you to stretch, move, and rotate a image on layer 1. Note that you ONLY get layer 1 and the sprite layer in this mode, unless you mess around with the EXTBG in mode 7. This layer also has 256 colors.

Mode 6 and 5 - In Mode 5, you have one 16-color BG and one 4-color BG, and in Mode 6, you have only one 16-color BG, and its has offset-per-tile functionality. They also both activate true hires by default.

Mode 4 - In Mode 4, you have one 256-color BG and one 4-color BG. This too has offset-per-tile functionality.

Mode 3 - In Mode 3, you have one 256-color BG and one 16-color BG. I also believe you can do some fancy things with the direct color mode.

Mode 2 - In Mode 2, you have 2 BGs of 16 colors each. In this mode, the 'tile data' for BG3 actually encodes a (possible) replacement HOffset and/or VOffset value for each tile of BG1 and/or BG2.

Mode 1 - Nothing special about Mode 1, its the one your used to.

Mode 0 - In Mode 0, you have 4 BGs of 4 colors each.

Most of this stuff is from regs.txt

Maybe I'm missing something but that's all that comes to mind right now.

(04-05-2016, 02:29 PM)Koh Wrote: [ -> ]One thing that always bothered me is that the RGB values aren't perfect multiples of 8. Why? That makes it a lot cleaner to look at for one, lol. That's what I personally do for my colors in RGB.

Agreed! And the worst part is, 15-bit color isn't even the messiest. You know those old Namco arcade games like Pac-Man, Dig Dug and Mappy? I actually did some research recently into their restrictions. Apparently, they supported 8-bit color with 3 red, 3 green and 2 blue bits for a total of 256 colors. And since arcade monitors were slightly different from modern ones, these colors can only be vaguely approximated. The result is this list of valid colors. Eugh!

Code:
Color    000        001        010        011        100        101        110        111

Red    0        33        71        104        151        184        222        255

Green    0        33        71        104        151        184        222        255

Blue    0        71        151        222

source

(04-05-2016, 03:33 PM)Raccoon Sam Wrote: [ -> ]This isn't strictly true.

Thanks for elaborating! Like old PCs, the SNES had tons of modes it could display graphics in. When Midday-Mew initially asked me about SNES restrictions, I typed up a big explanation like yours. However, since he wasn't developing for the console and only emulating the restrictions for a fangame, I gave him a condensed list. Yours is a lot more inclusive so thanks for typing that up. I remember hearing somewhere that some RPGs used high resolution mode rather well for the menus, but I can't find any screenshots for the life of me. Sad

(04-05-2016, 06:10 PM)DragonDePlatino Wrote: [ -> ]I remember hearing somewhere that some RPGs used high resolution mode rather well for the menus, but I can't find any screenshots for the life of me.

I'm confident I read an article by Byuu long ago where he demonstrated some Japanese RPG that used the true high resolution mode for some Menus but I can't find it either. I know for certain though that Mario's Super Picross and Secret of Mana used the pseudo high resolution mode for some text things, as evident in this image:
[Image: ckk2U.png]

Also, can I get a source on the "complete list of values for 15-bit colors"?

(04-06-2016, 12:31 AM)Raccoon Sam Wrote: [ -> ]Also, can I get a source on the "complete list of values for 15-bit colors"?

Midday called on me to answer this one. It's just the values you get when you convert 5-bit values to 8-bit values.

15-bit RGB allocates 5 bits to each color component, so each component can be given integer values from 0 to 31.
Whereas, of course, today's standard is 24-bit RGB, where each color component gets 8 bits, which encompass integer values from 0 to 255.
Converting back and forth is just a matter of some brief math.

Converting 5-bit values to 8-bit values
[Image: xWAjVwN.png]

Converting 8-bit values to 5-bit values
[Image: ba2tR3h.png]

Or, applied more generally:
Converting a-bit values to b-bit values
[Image: NqS5uFU.png]

Is there a quick way to make a paint.net palette file with those rgb values?

Like so: http://m.uploadedit.com/ba3s/14758521497.txt

If you're planning on converting a screenshot to the SNES palette, it's going to make very little difference. Unless you're working with very smooth gradients, the conversion will be unnoticeable. With that being said, here's a python script that'll handle the conversion for you:

Code:
from PIL import Image

import sys

import os

filename = None

picture = None

while True:

    try:

        filename = input("Enter a filename: ")

        picture = Image.open(filename)

    except FileNotFoundError:

        print("File ", filename, " not found!", sep='\"')

        continue

    break

width, height = picture.size

pic = picture.load()

for x in range(width):

    for y in range(height):

        color = pic[x,y]

        tempcolor = [x - (x % 8) for x in color] # Where the magic happens

        tempcolor[3] = 255 # Alpha is always 255

        newcolor = tuple(tempcolor)

        pic[x,y] = newcolor

filename = os.path.splitext(filename)[0] + "_converted.png"

picture.save(filename)

print("Saved converted image to", filename)

EDIT:
Just spent half an hour trying to bake this into an .exe but Python is a stubborn beast. If you can't run python scripts then SOL. ¯\_(ツ)_/¯

Not to bump an old thread, but I think the title of this is misleading. GBC is 16-bit, if I recall correctly. GBA is 32-bit.

(02-12-2017, 01:51 PM)Speed-X Wrote: [ -> ]Not to bump an old thread, but I think the title of this is misleading. GBC is 16-bit, if I recall correctly. GBA is 32-bit.

The GBC is 8-bit, same as the original Game Boy. Just because it has more colors doesn't mean it has more processing power.

And GBA, while it indeed has 32-bit processing, it's 16-bit in terms of colors.

So SomeGuyNamedDavid and I found a quick way to convert the colors of your images and sprite sheets that you're working on to 15-bit color values.

Just use the Posterize filter set to 32 levels (when you run the Posterize filter, it'll ask for a number and the number you want to put in is 32).

In GIMP, you'll need to use the Posterize filter on each and every layer that contains your sprites (don't use it on your sprite sheet's background layer, though).

In Photoshop, I believe it is even faster, as you can have a Posterize Adjustment Layer at the top of the layer stack that makes all layers below it appear as 15-bit colors--just make sure that the background layer doesn't get converted too. You can put all of the layers containing sprites (that you want converted) into a single Layer Group and then put the Posterize Adjustment Layer inside the Layer Group at the top of the Layer Group's layer stack. Then you want to change the Layer Group's "Blending Mode" from "Pass Through" to "Normal".

I'm not sure how you would do it quickly in other image-editing programs, though. However, GIMP is free (if you get GIMP, make sure you're downloading it from gimp.org so as to, well, reduce the chances of being scammed as well as to reduce the risk of getting a virus or some other form of malware), so there's that if you find you can't do it in your image-editing program of choice.

Unfortunately, while the Posterize filter makes it easy to convert the colors, just because you run the Posterize filter on your sprites doesn't mean that the sprites will necessarily work on a SNES. There's still the other limitations you'd have to work with (the other limitations are mentioned and explained in previous posts in this thread).

Hope this helps!

Hi, I'm new to the GBA and it's hardware, and I'm trying to make a PC game as accurate to the GBA hardware, but I can't find the anything to tell me the sprite limits and such, can someone help me out with this?

(10-15-2016, 03:52 AM)ommadawnyawn Wrote: [ -> ]Like so: http://m.uploadedit.com/ba3s/14758521497.txt

This Link is Down

May I add this interesting fact about sprite limitations for the (Super Nintendo Entertainment System) & Gameboy Advance?

Sprites used in every SNES game can have no more than 256 pixels (Excluding the empty space on the sprite box) on each frame of the character sprite. And I think GBA game sprites can handle slightly more or less pixels on each frame of the character sprite. Not sure

Pages: 1 2

Midday-Mew

Garamonde

Koh

Raccoon Sam

DragonDePlatino

Raccoon Sam

SomeGuyNamedDavid

ommadawnyawn

DragonDePlatino

Speed-X

Cooper

Midday-Mew

PotaJoe

Depressed Mario

Shin FireyPaperMario