SNES Sprite Restrictions?

[PypeBros]

You might want to think of the graphic unit of a SNES as a processor of its own that reads sprite and tiles description and has limitted resources to render them. Especially, it renders them "line by line" (yes, these are the scanlines) and will only be able to deal with a fixed number of objects on each line due to its internal limited resources.

So you will have both a maximum number of objects in memory, and a maximum object per scan line.
Similarly, the encoding on tiles and sprite -- which depend on the graphic mode you're using -- constraint how many colors per sprite you might have, but in addition, despite a possibly high number of palette you might have, there is only 256 possible colors per horizontal line, so if you put too many sprites on the same line that all use different colors, you might get into trouble. Some might not display, or display with the wrong color.
You might thus have 256 colors per line, but only 16 colors per 8x8 pixels tile, etc.

But the "per scan line" stuff also means that you might have *more* objects on screen than what the memory can hold, if you reprogram them on the fly (think of shoot'm'up bullets, for instance).

[straypixels]

Okay, I'm starting to get a better handle on it now.

Minor point of confusion, though... according to wikipedia, this:


is a 15-bit palette. It looks almost right, but then if you check the RGB values of some of the colors, they're not multiples of 8. Why is that? Is the palette just off, or am I not understanding something?

[ptoing]

Should be right. The index goes from 0-255, not 256. So they go off at some point.

[Akira]

right sorry, all my values should be -1 (so 7,7,7 - 15,15,15 etc). But even so there seems to be colours that shouldn't be there. The palette is likely off. its a pretty small png file, probably has been compressed.

[straypixels]

Thanks Akira, that's what I was thinking.

It's been about three years since I was on pixelation last I'm glad to see that you guys are still just as awesome and helpful

[Ai]

Everyone's got it almost-right so far.

The main thing you all missed is that the 'whitepoint' of snes is not 255,255,255. This is because CRT-based TV's don't like colors 'hotter'
than a certain amount.

If your RGB values are in the range 0..1, then this is how to convert snes ->sRGB:

sRGB = snes / 31.9393939393

(keep in mind that snes values only range 0..31 (== 32 levels))

OTOH, here is how to convert sRGB 0..1 to snes:

snes = round(sRGB.clip (0, 31./31.9393939393) * 31.9393939393)

The maximum result in 0...255 sRGB space attainable with these equations is 248.
When you check this against ZSNES  screenshots, it proves correct.
( http://www.nintendocity.com/screenshots/snes_screenshots/terranigma_screenshots.shtml )


In fact, it's easy to type hex SNES colors, because it only requires you to think of one thing:
You can type any digit in the first place, and only one of 0,8 in the second place. (so 303058 is okay; 333058 is not okay)


Thanks guys, this helped me notice and fix an off-by-one bug in my code; I used to divide and multiply by 32 rather than 31.9393...
(whereas 31.9393.... matches ZSNES behaviour exactly)

(and a corresponding bug in genesis support.)

right sorry, all my values should be -1 (so 7,7,7 - 15,15,15 etc). But even so there seems to be colours that shouldn't be there. The palette is likely off. its a pretty small png file, probably has been compressed.

PNG compression has nothing to do with losing data, okay?
That PNG is for PC 15bpp rgb hicolor, which, as illustrated above, is sufficiently different from snes that the PNG is almost uniformly wrong.
(the PNG is only slightly inaccurate according to my calculations; substituting intensities : 24 -> 25, 57->58, 198 -> 197, 231 ->230
would fix it. )

Rather than subtracting 1 from your values, you needed to use 255/31.9393939393 as your base factor,
which equals approximately 7.9838709677419359

According to my calculations, this is the appropriate set of values for PC 15bpp rgb hicolor:
 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

Or in hex:
00 08 10 19 21 29 31 3a 42 4a 52 5a 63 6b 73 7b 84 8c 94 9c a5 ad b5 bd c5 ce d6 de e6 ef f7 ff

One last thing: Nobody has yet mentioned that 16 colors / sprite is typical. I didn't know the '256 colors/scanline' limitation. 16c sprites make sense in light of this, though; easy way to avoid running out of colors.
In fact,  in FF3/FF6, all the characters' palette colors are chosen from a master palette of.. I guess 64.. could be anywhere between that and 32..
colors, presumably for similar reasons.