[Ohrrpgce] better palette options

[Jay Tennant]

> 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. 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.

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.

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.
>  
> 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 



_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
              http://www.doteasy.com