[Ohrrpgce] better palette options

[Ralph Versteegen]

On 8 October 2010 02:31, Jay Tennant <hierandel8 at crazyleafgames.com> wrote:
>> From: Jeremy Bursey <zippywings at hotmail.com>
>> Sent: Thursday, October 07, 2010 1:27 AM
>>
>> Now that I'm upgrading my game's palette a little, I've noticed how painful it
>> is to keep track of every graphical element in the game from tilesets to UI
>> color options. It seems like one little shift of the color placement can wreck
>> months, if not years of work if one's not careful.
>>
>> I know that a full 16 million color palette is a long way off, if it's ever
>> destined to become a feature at all, but how reasonable would it be to split
>> the graphical components (tilesets, sprites, backdrops, etc.) into separate
>> planes and to allow each plane to use its own palette?
>>
>> For example:
>>
>> What if maptiles had a dedicated palette that sprites, battle backdrops, etc.
>> did not interfere with?
>>
>> What if sprites could dip into their own dedicated palette and promise the
>> player a consistency of appearance, despite the changes that may happen on the
>> surface of the alien world?
>>
>> I think since we have the option to store a bunch of palettes in our game
>> files and since we can switch them on the fly using plotscript commands, why
>> not go an extra step and dedicate palettes to various graphical components in
>> custom and even allow custom to manage them in-game?
>
> Coincidentally, TMC and I have been discussing many points you've highlighted,
> including use of multiple master palettes.

Yes, we were talking about exactly this, just a couple days ago. Jay
was the conservative voice :)

> To maintain that snes feel, we
> were planning on maintaining the 256 color cap on most surfaces, though
> exposing 32bit surfaces to plotscripts, backdrops, menus. 32bit surfaces would
> allow alpha blending as well. Kind of an arbitrary cap, and it needs more
> discussion.

Not menus. I don't know why you keep mentioning them! Maybe you're
thinking of the boxes behind them?

> This is part of the plan to move the graphics work into the backend for
> hardware accelerated drawing, higher resolutions, alpha blending, and pixel
> buffer effects.
>
>> We've already been given the ability to split maps into multiple layers, so
>> would it be possible to extend this idea into the area where custom
>> handles palette displays?
>>
>> I figure, each component can stick to its current limitations (maptiles and
>> screens with 256 color palettes and sprites with 16 colors (though, 16 from a
>> dedicated sprite palette that may canvas 256)), so it's not like we would need
>
> Apparently it is possible to run 256 color sprites, but the code needs to be
> rewritten from efficiently using video pages (dos days). Instead of attacking
> it now, I'm waiting until we've worked out an interface for the backends.

Clarification: the sprite editors need to be rewritten, and the
graphics file formats need to be replaced. Everything else has already
been done, slowly, over the span of many years.

> I personally plan on attacking this after I've finished working out joystick
> support for the directx backend.
>
>> to display 257 colors or more from a single component at once. But I think it
>> would be great if we could maintain the integrity of our character walkabouts
>> from the chosen palette, even though the map itself may boast an all new
>> flashy palette that the sprite cannot adjust to without its skin turning red
>> and its hair blue. It would also be nice to maintain our UI display colors,
>> textbox designs, etc., should we choose to maximize our tileset palettes by
>> adding a new color to the top left row (colors 1-16) instead of sticking
>> ourselves with repeated colors, like the ones we have in the default palette.
>> With the ability to store thousands of custom palettes in each game, it would
>> seem silly not to allow a position to use them effectively.

The engine is internally limited to 256 colours and a single palette
throughout. The graphics backends are the only places that actually
have the ability to display more than 256 colours at once. So I'm
afraid that this would actually be a much bigger change to internals
than you imagine. But I don't think it would actually be a huge task
because abstractions are already partially in place. And it's a change
we want to make anyway, soon, because it'll allow many other new
features.

>> And on the note of multiple palettes, would it be reasonable to add the
>> ability to load palettes automatically, instead of relying on a plotscript?
>> For example, when the player enters a new map or a battle screen, the music
>> can change. If we're being picky, we could also claim that the graphics
>> change. Would it be reasonable to add a bitset to all relevant gaming areas
>> that loads either the "default" palette or a custom palette? Again, this would
>> only be helpful if sprites, slices, textboxes, UI colors, and so forth could
>> be assigned their own palettes so that graphics don't end up clashing with one
>> another. But if any of this is possible, it would certainly upgrade the OHR's
>> graphic ability to a stellar level.

Well as you say it's pointless to add this now, and it would be
pointless to not add it if different graphics could use different
master palettes.

>> This may have already been discussed at some point, but I'd like to bring it
>> up again in case the ideas for it had hit a standstill. It's bothered me for a
>> long time how uncooperative a single palette can be, especially when one
>> considers how many colors are represented in the real world. It also
>> frustrates me to know that all those extra palettes sitting in my game's
>> storage are there really only to tease me.

I'm sorry about this. Adding multiple master palettes was a really
bizarre decision of mine: it achieves very little, and adds a lot of
confusion and feelings of despair.

>> "Come play with us," they say, and
>> yet I can do no such thing because that would mean changing the lead hero's
>> ethnicity from Caucasion to Frog. I think splitting the palette display into
>> sections and giving Custom the ability to assign specific palettes to specific
>> graphic components would really improve a game's overall presentation without
>> having to rewrite the entire color code into a massive 16 million color
>> display.
>>
>> Please consider this if it's at all possible to do such a thing. I'm posting here instead
>> of bugzilla since discussions about improvements seem more active here.
>>
>> Thanks.
>>
>> --Jeremy
>