Genesis:
pros
Don't feel like you need to fine-tune the colors as much as SNES.
cons
Sometimes, the color your looking for is just not there.
SNES:
pros
Usually you'll find the color you need.
cons
Sometimes colors are so close to eachother, it gets hard to find the perfect shade, among similar looking colors.
8-bit systems with fixed 16-color palettes are the most fun for sure - ZX Spectrum (acid bright primary colors), C64 (a brown rainbow), MSX and other TMS9918-based systems (pastel, candy-like colors).
Genesis, SNES - not that fun, because they provide a lot of freedom compared to these.
The solution is very easy then: make games for the SNES but restrict your palette to only the colors that the Genesis can produce, except for the ones that "just not there".
This may sound like a joke, but if you think about it it really makes sense. If you reduce your options on purpose, it gets easier to pick the initial palettes, and then you fine tune the ones that feel off.
ZX spectrum makes EGA look good.
But then EGA (16 colors out of 2bpc RGB) is not too far from the Master System.
I was expecting something around Fixed vs RGB vs HSL etc.
I like to work with fixed palettes, you have your limits set and you got to work within them, you can just do anything right away without being able to worry too much as there's too little to cause any significant headache.
I like HSL way better than RPG as it's more "human-eye friendly".
If you are doing SNES-dev I'd consider using a HSL to RPG conversion program so you can pick the hue and brightness of all your colors and it's easier to get the color you want like that than by using R, G and B values.
RPG palette?
I think the ideal color space for games would be HSY, (hue, saturation, luminance) but I don't know where I can get one.
With RGB palettes, I think 4096 colors is the perfect balance between too little and too much. I always thought the SNES's 32000 colors was overkill for the type of graphics that you usually saw on the SNES. The CPS2 only had 4096 colors and nobody ever complained about it.
NES, Game boy and Wonderswan are my favorites, as are CGA-VGA, C64 and Speccy!
Game Gear's 12-bit palette makes SMS 6-bit and Game Boy Mono palettes inferior, although Game Gear is at a Game Boy res!
One computer system I am developing has a special RGB config I call RGBZ that allows for ~14.3M colors from 15 bits.
HSL I never liked, at least not for creating colors, only for modification of already created colors which I created in RGB
A problem with HSL is that, despite its friendliness to art designers, it's not well suited for use at runtime in any environment that has to implement gel (colored lighting) or translucency. So GIMP has a couple color pickers that display the color in HSL and then convert it to RGB after the user clicks OK.
The thing that bothers me about HSL is that red, green and blue are all at L=128 and not at their individual luminance values.
It's possible to design an HSL style color picker closely related to YUV, where the HS plane is essentially UV converted to polar as seen on
vectorscopes. That would put pure green at a higher lightness than pure blue, as you'd prefer.
Quote:
A problem with HSL is that, despite its friendliness to art designers, it's not well suited for use at runtime in any environment that has to implement gel (colored lighting) or translucency
SNES supports transparency in hardware.
About lightning, HSL is better than RGB as you can do various kinds of effects by addning some bias to the L values, and it'll look overall better than adding some bias to individual R, G and B components.
Also you can do saturation effects (for example if something colored is turned to stone you can do it "smoothly" or hue effects (if you want something to change it's color gradually, it'll be extremely simple as opposed to the complex calculation it'd be in RGB).
Bregalad wrote:
Quote:
A problem with HSL is that, despite its friendliness to art designers, it's not well suited for use at runtime in any environment that has to implement gel (colored lighting) or translucency
SNES supports transparency in hardware.
Because its underlying color model is RGB. HSL/HSV/HSY is polar, and polar coordinates with unlike hues don't add easily.
Quote:
lightning [...] addning
Are we talking about lighting or lightning?
What I meant is that if a room has a green light in it, the green is supposed to be "emphasized" to use the NES term, with red and blue diminished. This is a set of three component-wise multiplications.
Quote:
Also you can do saturation effects (for example if something colored is turned to stone you can do it "smoothly" or hue effects (if you want something to change it's color gradually, it'll be extremely simple as opposed to the complex calculation it'd be in RGB).
These are each a matrix multiplication in RGB. Slowly interpolating saturation in HSV family representations works if something turns to gray stone, not to colored stone, and definitely not to something with a different specularity such as metal.
Well I'm pretty sure that for any effect that is simple in a color space, it can be done with a more complex (not mathematically complex but computationally complex) 3x3 matrix multiply.
tepples wrote:
But then EGA (16 colors out of 2bpc RGB) is not too far from the Master System.
This works only in 640x350. Due to IBM wanting compatibility of EGA in 200 lines modes with CGA monitors, only the 16 CGA text mode palette colors can be displayed in 200 line modes (640x200, 320x200 etc.). That is why most EGA graphics looks pretty bad.
Beeper wrote:
Due to IBM wanting compatibility of EGA in 200 lines modes with CGA monitors, only the 16 CGA text mode palette colors can be displayed in 200 line modes (640x200, 320x200 etc.). That is why most EGA graphics looks pretty bad.
Was it only BIOS that couldn't reprogram the palette in EGA modes, or did the card's hardware restrict the color palette whenever the dot clock was set below the frequency for 640x350? I seem to remember that a CGA would just use EGA green intensity for all three channels' intensity.
No-one with the actual hardware has tested, but I strongly suspect that the color mapping (whether to treat secondary-green as secondary-all) is just a function of sync polarity.
Back when I used QBASIC, I remember being able to map any of the 262144 VGA colors to the 16 indexes of SCREEN 7 (I had to directly write to some ports instead of using the built in palette manipulation command though). I don't know if that was standard or not...
I failed to read!
tepples wrote:
Was it only BIOS that couldn't reprogram the palette in EGA modes, or did the card's hardware restrict the color palette whenever the dot clock was set below the frequency for 640x350?
Neither! It's the monitor.
lidnariq wrote:
that the color mapping (whether to treat secondary-green as secondary-all) is just a function of sync polarity.
The question, however, is whether the EGA monitor's circuitry for hsync can self-sync to either 16kHz or 24kHz independent of sync polarity, or if the sync polarity determines both the mapping of digital values to colors as well as what hsync rate the monitor will not blow up on.
tokumaru wrote:
Back when I used QBASIC, I remember being able to map any of the 262144 VGA colors to the 16 indexes of SCREEN 7 (I had to directly write to some ports instead of using the built in palette manipulation command though). I don't know if that was standard or not...
Yeah, VGA cards, in order to be backwards compatible with EGA software, retained the EGA's hardware palette. I remember explicitly configuring the EGA palette (replacing brown, EGA palette 20, with dark yellow, palette 6) to simplify VGA palette wipes.