Regarding colors being off: welcome to the main reason why so many people hate NTSC. This is why NTSC TVs have a hue setting, which can change the colors completely. The saturation setting tends to be just as bad about this as well. For example, another color that tends to be dangerous is magenta, since it has a tendency to turn red.

Trying to account for different TVs is futile, they're all just way too different (especially for NTSC).

I actually really like the NES's palette because it's YIQ/YUV based. Trying to pick colors using raw RGB is harder because the luminance varies greatly depending on the hue, which is a problem if, for example, you're trying to make differently colored blocks all have the same relative lightness/brightness, especially if you're working with a very low resolution RGB, like RGB222.

Also, on a CRT, SMB's sky color looks like an extremely vibrant blue, not like the washed-out purplish blue a lot of emulators seem to give it. I like using hue C for stylistic purposes, but I go with other shades of blue if it clashes too much with the rest of the objects in the scene.

Oh, but I will have to disagree with you on one thing...$22 may have been the iconic sky blue of SMB, but any other colors could have been used. I usually find myself using $21 or $2C for my sky colors. $21 has more of a morning/afternoon color while $2C gives me the impression of noon.

That'd be an interesting hack for ShaneM to attempt. Super Mario Bros. appears to take place over the course of three days and two nights, the nights being worlds 3 and 6. So I wonder how hard it'd be to make SMB1's sky vary among $22, $21, and $2C based on "time of day":

That's not a very good palette to begin with, looks like the old Nesticle palette. (Dead giveaway is the really bright blue in the top row)Here's the palette that Nintendulator uses:You'll notice that the colors of each row look much closer to the same luminance level.

I actually really like the NES's palette because it's YIQ/YUV based. Trying to pick colors using raw RGB is harder because the luminance varies greatly depending on the hue, which is a problem if, for example, you're trying to make differently colored blocks all have the same relative lightness/brightness, especially if you're working with a very low resolution RGB, like RGB222.

Curiously, if you show me a color I can make a reasonable guess of its RGB value, but I'm utterly screwed when it comes to any other color system. This really seems to depend on which system one learned first, doesn't seem like any of them is particularly more intuitive in the long term (they still have their own advantages with other operations though, e.g. hue-based systems have it easy if you just want to change the hue, but simulating light addition/substraction is much easier with RGB, etc.).

...I wonder how hard it'd be to make SMB1's sky vary among $22, $21, and $2C based on "time of day"

Screw the sky, if someone did a hack like that you could change the entire level's palette! I played around a bit and was able to pull off 11 transitions, with two of them being repeated before/after noon...

But actually, I'm pretty sure something like this exists. Mario Adventure had different times of day and even weather effects. All it was missing were some morning and evening palettes!

Dwedit wrote:

That's not a very good palette to begin with, looks like the old Nesticle palette. (Dead giveaway is the really bright blue in the top row)

Oh yeah, definitely. I actually just ripped that palette from Wikipedia's article on console palettes to use as an example. But even though it's not that great of a palette, many of the problems I described plague a lot of palettes.

...Except for Joel Yliluoma's NTSC palette generator. That thing produces freakin' gorgeous palettes! The reds and yellows are really strong and the contrast is great. That mockup I made up there? I got the palette for it from Joel's generator with the saturation set to 2.0.

Question: has anybody tried to get the YUV colors straight from a PPU already?

That's what palette generators by Bisqwit and Drag attempt to do, and what NTSC filters in emulators attempt to do. In essence, they take the measured $x0 and $xD voltages, generate the composite output waveforms, and apply NTSC decoding functions to them.

Anyway, normally we think of brightness as one of the dimensions of a matrix transformation of the input RGB tuple. At least, given linear brightness. Doesn't DTRT with gamma-corrected input. I don't know whether these sqrts are supposed to be on linear brightness...

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum