Talk:Plan for 256 color sprites

Moogle1: Is anyone clamoring for this feature? The grumpy gamer in me says it's not desirable, and if it was good enough for the SNES, then by golly, it's good enough for us

Bob the Hamster: Well, I want it pretty badly myself-- but no, nobody else has been beating down my inbox for it. Of course, I could implement and automatic real-time color-counter so you grumpy grandpa's could avoid accadentally using 17 colors in one sprite ;)

Myroc: I've wanted 256 color sprites ever since i began using the OHRRPGCE. Big thanks if you introduce it!

256 colour palettes

NeoTA: I've been working on a similar problem, and a subset of the approach I worked out for GPixMint might work well here.

1. Allow the user to define 'Gradients' -- sets of palette indices that are related, usually in a 'dark->light scale of colors' way.

2. Make 256-color palettes by choosing a set of gradients (ie. first comes this gradient, then this one, then..).

This approach allows quick and easy recoloring (if you can select from only the gradients of same length instead of all of them, when editing 256col palettes), at the cost of a relative profusion of gradients.

The Mad Cacti: I'd really like to see this feature too - 16 colours doesn't seem like a very justifiable limitation. I'd also like to change the bitdepth for fonts to 16 or 256 colours, because everything else does bitmapped fonts, but I want to preserve adjustable font colour.

Palettes could keep track of the number of used colours (appearing to be variable length) to keep things tidier. Defaulting to 16 or even 1 colour instead of 256.

Perhaps also the palette identical to the master palette could be treated specially somehow, to hide the layer of indirection and work like just the maptile editor.

There doesn't really seem to be any space to spare in the sprite editor. Perhaps only 16 or 32 colours could be shown at a time, and when you select a different palette colour or mouse over, the full palette is briefly displayed (covering the thumbnail?)

I like Neo's idea, it solves large palettes and palette shifting. So, you're saying that gradients would be created separately, palette-independent? I have trouble seeing how the UI would work though. Would it be just like a normal palette, with the gradients concatenated? It appeals to me to display the palette as a set of distinct gradients, as columns or rows. Hmm, perhaps there could be two rows of 16 colours replacing the current single row of colours: the top row shows one colour from each gradient (or even a tiny preview of the gradient) or independent colour, and could scroll left and right if there were more than 16 as above, the second row showing the colours in the selected gradient. A preview of the whole palette could appear on mouseover or selecting a different gradient, but this time as 1 column per gradient.

NeoTA: You would not be obligated to concatenate, however, remember that not all gradients would be of same length. FWIW, my original idea IIRC was something like : master palette > gradients > sprite palette (where X > Y indicates a 'Y uses items from X' relationship, and a notion of master palette as an unlimited size, but practically limited to ~64-1024 colors, collection of colors in no particular order.)

UI is something I'm working on for GPixMint. In the meantime, let me suggest:

• Show only the current gradient, provide keys to move to next/prev gradient. moving off the end of a gradient should also switch to the next/prev gradient as appropriate.
• Show additional gradients (say, the nearest 3 gradients on each side) upon mouseover -- allow the user to click to select an exact color in an exact gradient. Click+drag to navigate through palette.

Lastly, it's probably pretty important to have named gradients in such a scheme, even if they only have 8char max names.

NeoTA: A further advantage you can squeeze from my scheme is, if you partially sort the gradients in a palette by length, so that all the 2-length gradients are grouped together, all of the 3-length, ... This would mean that any two palettes using the same number of each length of gradients could be used interchangeably. To be clear, the partial sort preserves the relationship of all the N-length gradients -- that is, if the unsorted input includes gradient B of length 4 as the next 4-length gradient after gradient A of length 4, B will immediately follow A in the sorted output.

Tranlucency

Kizul 18:10, 13 December 2008 (UTC): Personally, I'd rather have either more font colors (4, 8, 16, 256 — I'd personally prefer the first or third, though), or TRANSPARENCY for sprites and layers 1 and 2 — obviously layer 0 wouldn't have any, unless you could specify a color for it to blend to…

In my opinion, transparency would make 90% of all games made with the OHR quite a lot more awesome (at least to LOOK at), especially if the OHR's transparency had all the same functions as the Super Nintendo's.

Admittedly, though, having 256-color sprites would be nice for some things, like huge enemies, and heroes — not being able to use many colors on them is a tad annoying at times, so it would be cool to have the ability to use more colors on them.

My 2¢.

Mike C.: By Transparency, do you mean translucency (since, that's a whole different beast)? Translucency is difficult to achieve in 256 colour mode. Most implementations limit you to 50% translucency, and have a big lookup table (256x256 elements) to make it fast. However, it would have the potential to look ugly.

Also, as for Layer 0, the implied colour behind Layer 0 is black. And, if it ever happens, you would be able to specify a parallax background (in the form of a full-screen image).

Kizul: Okay, my bad, I did mean Translucency. Would it be very hard to make it to where the OHR uses 16-bit (or 32-bit) color, though? On the subject of 256-color translucency, SNES translucency didn't seem to look so bad, even though its main palette was just 256 colors — maybe you could do something similar to what the Super NES does. Or I dunno, maybe have the translucent objects use 'color emphasis' or something; have CUSTOM/GAME add the colors of pixel 0,0 of Sprite X (dividing each RGB value by 2, assuming its opacity is set to 50%) to the colors of pixel that Sprite X's pixel 0,0 overlaps (again, dividing each RGB value by 2, with the assumption that the opacity of the sprite/tile above it is set to 50%), repeating for all the pixels in the sprite, after which make CUSTOM/GAME show Sprite X with the half-and-half colors.

Coupling this with an ability to set the opacity of a sprite/tile to 100%, 75%, 50% or 25% (possibly also 12.5%, but that might be a little much), you could do translucency pretty easily — would be nice with being able to adjust the 'brightness' of the translucency, though, for lights and such.

However, I'm getting really far off-topic from what this talk page is for, so I'll just hush now. :)

The Mad Cacti: I looked into what the SNES does. The SNES can output 15-bit (5 bits per component) colour values to screen, and has a 256 colour palette made up of these colours. When sprites are drawn with transparency, the palette colours are mixed to produce a 15-bit result.

Transparency using a 256 colour palette is simply going to look awful without an especially arranged palette which covers the whole colour space evenly (or maybe something else really clever).

The OHR does have a true colour mode. However, the only difference is that after the screen has been drawn at 8-bit depth, it is converted to truecolour before being sent to the graphics library. To add transparency, we would have to rewrite quite a lot of the allmodex backend to use a higher bitdepth right from the beginning. Which wouldn't have been so hard if we had just wrapped SDL_Surfaces or a fbgfx replacement instead.

I dunno, it might be possible in the future, but I'm not going to aim towards it.

Kizul: Yikes — I see. Okay, well — it was just a thought. It'll be awesome when the OHR does have translucency, though. :D

Back on topic: I like the idea of 256-color sprites with the little color-counter thing — couple that with showing what colors you'd used when you mouse over it, and it'd be pretty cool. :)