[Ohrrpgce] better palette options

Jeremy Bursey zippywings at hotmail.com
Wed Oct 6 23:27:31 PDT 2010


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?
 
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 
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.
 
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.
 
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. "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 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20101007/e3f60e78/attachment-0002.htm>


More information about the Ohrrpgce mailing list