nesdev.org

Arne's palette is so random. Even if your using a ROM palette, at least give all hues an equal amount of equally placed shades, and pick the colors from a low res RGB palette.

Well...Arne's palette might seem random, but from an artist's perspective it's actually a pretty great palette. It's an analog palette like the C64 palette, where everything was hand-picked to work best for low-resolution pixel art graphics. Giving all of your hues an equal number of shades is actually a really bad idea, because then you'll end up with lots of ugly, unusable magentas like in the EGA palette. Notice how the palette lacks any skin colors, so you have to make everyone look like a crab-faced mutant?

On the other hand, if you look at analog palettes like the famous Dawnbringer 16, you'll see that hand-picking your colors makes a huge difference. Both EGA and DB16 have 16 colors to work with, but the latter looks waaay better!

But with that being said, I do think arne could have organized his palette a lot better. I've attempted to organize it into a nice grid at least a million times and I've always failed.

Pedanticism: That's the CGA palette.

The EGA palette is much more diverse, basically the same as the SMS palette. Only 16 simultaneous colors instead of 32, though.

EtA: (moved this section to newest post)

Ohh! You're talking about that old 6-Bit palette, right? Remember how I said I wasn't able to organize Arne's palette? I was actually able to organize EGA into some nice ramps for my own purposes!



EGA (not CGA, sorry about that) is really cool because even though it's a machine-generated palette, it's actually really usable for pixel art. There's a nice mix of high-saturation and low-saturation colors and a neat pattern to how big each ramp is...Primary/secondary RGB colors have 6 colors in their ramps, tertiary colors have 2 colors and quaternary colors have 1 color each.

Also, keeping things on subject...would it be possible to make an NES ROM using EGA colors? I know NES hardware can't generate RGB colors, but in theory could one create an emulator palette file and get games to run in EGA? You'd have to completely redo a game's graphics from the ground-up and the game wouldn't work on actual hardware, but it would be an interesting experiment. Hmm...

DragonDePlatino wrote:would it be possible to make an NES ROM using EGA colors? I know NES hardware can't generate RGB colors, but in theory could one create an emulator palette file and get games to run in EGA?

Wouldn't you call that an SMS game? I mean, modulo the bits about how the NES has eight three-color palettes and the SMS has two fifteen-color palettes, and the SMS can't do split screen...


The Dawnbringer 16 palette is ... more-or-less completely divorced from the constraints of what made the market move in the way it did. It's made without an eye to the hardware constraints imposed by using RGB or YUV, and his stated intention to rely on halftoning makes it collide badly with PAL and NTSC. The specific colors he's chosen are randomly all over the place in terms of RGB and YUV values, so there's no hardware advantage to such a fixed palette, either (unlike the VIC20 and C64, where there were five fixed brightnesses, and seven (out of 16) predefined chroma angles chosen.)

So it's more or less only usable as a software palette. Which is fine! the Macintosh's and VGA's 16-color modes would have benefited. (In fact, a number of games released before Windows95 and the ubiquity of 256-or-more-color VESA modes look rather like this). But those are highish resolution modes, so the crunchy low-res aesthetic doesn't jibe with reality. And the VGA high-resolution mode doesn't leave enough memory to double buffer what's onscreen, in addition to making full-screen updates a pain because of the planar layout.

lidnariq wrote:and his stated intention to rely on halftoning makes it collide badly with PAL and NTSC.

That depends on what kind of filtering your video encoder uses. Most TMS9918 descendants (NES PPU, SMS VDP, S-PPU, MD VDP) use a really shortcutty 1980s design, but something that outputs YUV and applies the correct low-pass filter to UV channels before combining them with Y will make the checkerboards blend properly.

Ha-ha! It was a monumental success! With the aid of YY-CHR, a custom .pal file and a hex editor, I was able to convert a Super Mario Bros ROM to EGA color.



The 3-color tile restrictions are still in place, this isn't compatible with other NES palettes and this wouldn't work on actual hardware, but there are 10 more usable colors and a much better coverage of the RGB spectrum. In the conversion to EGA color, some things improved (more browns and super-smooth ? block flashing) while some things came out worse (oversaturated greens). Overall, an interesting experiment.

lidnariq wrote:The Dawnbringer 16 palette is ... more-or-less completely divorced from the constraints of what made the market move in the way it did.

Ah, what a shame...I've always wondered how gaming would have been different if we had gotten graphics like these on older systems. But it turns out, it would've only been possible on older PCs. Regardless, thanks for the insight. It makes a lot more sense to me now why older games had the palettes they did.

DragonDePlatino wrote:Heh, and we all know what Pokemon would've looked like on the Commodore 64!



DEM DOUBLE-WIDE PIXELS

Very very nice. This is actual oldschool pixel work that any classic console enthusiast can appreciate.

psycopathicteen wrote:Arne's palette is so random. Even if your using a ROM palette, at least give all hues an equal amount of equally placed shades, and pick the colors from a low res RGB palette.

Not true. Arne statistically sampled MANY images from random interenet sources, and used the results to calculate a 64-colour palette. http://androidarts.com/palette/PaletteUnwrap256rnd.png

DragonDePlatino wrote:On the other hand, if you look at analog palettes like the famous Dawnbringer 16, you'll see that hand-picking your colors makes a huge difference. Both EGA and DB16 have 16 colors to work with, but the latter looks waaay better!

Ew! Not THIS mess again! Why is this palette so over-used?! The colour selection is just nasty. :X I don't think I've seen too much art from it, that isn't horrible muddied.

DragonDePlatino wrote:But with that being said, I do think arne could have organized his palette a lot better. I've attempted to organize it into a nice grid at least a million times and I've always failed.

Did you even LOOK?! http://androidarts.com/palette/64PalV8Ordered.gif

Drag wrote:Very very nice. This is actual oldschool pixel work that any classic console enthusiast can appreciate.

Thank you so much! Even if I didn't get the aspect ratio right, I'm still proud of how much detail I was able to cram into the 12x21 resolution.

Alp wrote:Not true. Arne statistically sampled MANY images from random interenet sources, and used the results to calculate a 64-colour palette. http://androidarts.com/palette/PaletteUnwrap256rnd.png

Well, if he statistically sampled a ton of images and was able to generate a nice series of 4-color ramps, it isn't so random, is it?

Alp wrote:Ew! Not THIS mess again! Why is this palette so over-used?! The colour selection is just nasty. :X I don't think I've seen too much art from it, that isn't horrible muddied.

Weeell...it all depends on how you use the palette. Most people over on PixelJoint like to push palettes to the extreme, and while their work is amazing it can lack clarity sometimes. Here is a good example of something a little more clean. Unlike most 16-color palettes, you can plop down huge flat areas of green and it'll be pretty easy on the eyes.

Alp wrote:Did you even LOOK?! http://androidarts.com/palette/64PalV8Ordered.gif

No waaay! I didn't realize he had that tucked away somewhere on his site! I can't believe I wasted a whole afternoon trying to make that myself. D: Thanks for sharing this shiny new toy with me!

tepples wrote:That depends on what kind of filtering your video encoder uses. Most TMS9918 descendants (NES PPU, SMS VDP, S-PPU, MD VDP) use a really shortcutty 1980s design, but something that outputs YUV and applies the correct low-pass filter to UV channels before combining them with Y will make the checkerboards blend properly.

The PPUs are not TMS9918 descendants o.O (you could argue about tilemaps and sprites, but that stuff was inherited from arcades in general really) Also the TMS9918-based chips were RGB-based internally (which means its ugly palette makes even less sense since there wasn't any real restriction it seems).

Also while we're talking about random palettes, one thing that annoyed me was when trying to cram non-paletted RGB into 8-bit, it was usually 3 bits for red and green and only 2 for blue... which leaves blue with very few shades in comparison (the steps are still too big to not matter), not to mention making it impossible to make a convincing gray. I was messing around and making red and blue share the LSB would have been a much better idea (I should make an image of that palette again, the one I have is in the old Win98 machine). I wonder why nobody came up with it back then.

And yeah, CGA palette =P Which everybody calls EGA because nearly nobody bothered to change it from the default (although apparently there were some cheap clones that had it fixed to that, which may explain the issue...).

Sik wrote:one thing that annoyed me was when trying to cram non-paletted RGB into 8-bit, it was usually 3 bits for red and green and only 2 for blue... which leaves blue with very few shades in comparison (the steps are still too big to not matter), not to mention making it impossible to make a convincing gray. I was messing around and making red and blue share the LSB would have been a much better idea (I should make an image of that palette again, the one I have is in the old Win98 machine). I wonder why nobody came up with it back then.

This page shows a couple of interesting 8-bit palettes (RRGGBBSS and RRGGBBII).

And yeah, CGA palette =P Which everybody calls EGA because nearly nobody bothered to change it from the default (although apparently there were some cheap clones that had it fixed to that, which may explain the issue...).

I remember reading that the EGA palette couldn't be changed in the 320x200-pixel mode (EDIT: The wikipedia page says this), which was the most common for games.

Sik wrote:The PPUs are not TMS9918 descendants

True in that they were implementations from scratch of the same concept. But see 6502freak's post about the ColecoVision port of Donkey Kong being the Famicom's inspiration.

And yeah, CGA palette =P Which everybody calls EGA because nearly nobody bothered to change it from the default (although apparently there were some cheap clones that had it fixed to that, which may explain the issue...).

I think the 200-line EGA modes were in some sense fixed to the CGA palette because they were intended for compatibility with CGA monitors. Wikipedia states without citation: "The extended [64] color palette cannot be used in 200-line modes." Apparently game graphics weren't quite as high a high priority for International Business Machines as high-resolution business graphics.

Ugh at the palette thing =/ Though looked it up, apparently the problem was not the card itself but the monitors:
http://www.reenigne.org/blog/why-the-eg ... ine-modes/

And here I had just assumed that it wouldn't display fully correct colors when using a CGA monitor.

tepples wrote:True in that they were implementations from scratch of the same concept. But see 6502freak's post about the ColecoVision port of Donkey Kong being the Famicom's inspiration.

That seems to talk about the idea of a console in general though, not the hardware design in itself. Remember that the Donkey Kong arcade itself was based on tilemaps and sprites (it just lacked scrolling), and it certainly wasn't the first arcade to have that either, so it's not like Nintendo took the idea from the Colecovision.

May as well say that every system using tilemaps and sprites is a TMS9918 derivative.

Sik wrote:That seems to talk about the idea of a console in general though, not the hardware design in itself. Remember that the Donkey Kong arcade itself was based on tilemaps and sprites (it just lacked scrolling), and it certainly wasn't the first arcade to have that either, so it's not like Nintendo took the idea from the Colecovision.

May as well say that every system using tilemaps and sprites is a TMS9918 derivative.

But was there a tilemaps and sprites picture generator on a single chip with greater than 160 pixels across before the TMS9918? The TMS9918 proved that full LDTV-resolution tilemaps and sprites, as opposed to a dumb frame buffer like an Apple II or CGA or a chunky 160x96 tile plane like Odyssey 2 or INTV, could be done in a console. Notice how chunky Mario is in every pre-NES home Mario game other than Donkey Kong for ColecoVision:


Mario sprites on pre-NES consoles
Atari 800 Donkey Kong, Atari 800 Mario Bros, ColecoVision, Intellivision, Commodore 64, Atari 2600

What no one realized at the time was that it's possible to make colorful sprites on a C64 without making it look too chunky, by using two sprites: one full-res for the outline and one half-res for the innards.