Linkus
04-15-2007, 08:01 PM
Recently I was playing on my SNES emu, and I had taken a snapshot for palette ideas. Accidentally, I left a unnecessary layer on with transparent tiles, and the result was at least 80-120 colors for something that originally created for 64 colors.
And then the thought hit me. We need 512 color support, but not entirely, though. Why? A majority of the current palette is fixed, in which cannot be changed because those Csets are being used in the Subcreen, for a sprite, or an item. One benefit for the idea is that 8-bit color will become completely editable in all 256 colors. Also, since the Enemy Editor is well on its way, the extra Sprite Csets will be used much more, which can cause ZC to crash if there are too many Csets at the same time. Now for the limits to the users-You can only access the first original 256 colors;the second 256 color palette is reserved for he GUI, transparency(SNES-style, which doesn't refer to a similar color within the palette), and Sprite Cset overflow.
Backwards compatibility should not be affected--previous versions will only use the palette limits of the version it was created in.
The only con currently is that it will use more memory, as far as I know. There could be color transfer problems as well, but I'd doubt it.
That's all I got to say for this thought. Comments?
And then the thought hit me. We need 512 color support, but not entirely, though. Why? A majority of the current palette is fixed, in which cannot be changed because those Csets are being used in the Subcreen, for a sprite, or an item. One benefit for the idea is that 8-bit color will become completely editable in all 256 colors. Also, since the Enemy Editor is well on its way, the extra Sprite Csets will be used much more, which can cause ZC to crash if there are too many Csets at the same time. Now for the limits to the users-You can only access the first original 256 colors;the second 256 color palette is reserved for he GUI, transparency(SNES-style, which doesn't refer to a similar color within the palette), and Sprite Cset overflow.
Backwards compatibility should not be affected--previous versions will only use the palette limits of the version it was created in.
The only con currently is that it will use more memory, as far as I know. There could be color transfer problems as well, but I'd doubt it.
That's all I got to say for this thought. Comments?