Yet another NES palette topic

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Yet another NES palette topic
by on (#159997)
Over at https://gbatemp.net/threads/ripping-the-nes-virtual-console-palette.371706/, someone has claimed to have ripped the NES palette from the Wii and 3DS Virtual Console. The 3ds one looks pretty good to me. Out of curiosity, I was wondering how feasible it would be to take the RGB triplets and determine if Nintendo just picked colors that looked good, or if they actually converted the NTSC to RGB using the same methods as found at http://bisqwit.iki.fi/utils/nespalette.php and http://drag.wootest.net/misc/palgen.html. If the latter, does anyone with more familiarity with NTSC video and the math behind the conversion know which values of Hue, Saturation, Brightness, Contrast, and Gamma they used?

Also, going through this board, I've read that someone along the line has ripped the palettes from the Animal Crossing NES emulators. I haven't been able to find it--can someone post a link to it? Thanks!
Re: Yet another NES palette topic
by on (#159998)
zomgwhat wrote:
Out of curiosity, I was wondering how feasible it would be to take the RGB triplets and determine if Nintendo just picked colors that looked good, or if they actually converted the NTSC to RGB using the same methods as found at http://bisqwit.iki.fi/utils/nespalette.php and http://drag.wootest.net/misc/palgen.html.

VC ROMs are iNES files taken off the internet. How much effort do you think Nintendo put into this?
Re: Yet another NES palette topic
by on (#159999)
How would you tell the difference between "off the internet" and a new dump? (Unless it was a copy of a popular bad dump, or had "diskdude" in the header, there wouldn't be any difference.)

iNES headers are practical. Why wouldn't you use them for your emulator? They make it very easy to tap a huge existing library of files to test with. I can't think of a single NES emulator that doesn't support iNES headers, what reason would Nintendo have to use anything else for their own?

I will say, though, I am annoyed they didn't implement PAL DPCM speeds properly; the VC version of Ufouria has an out of tune bassline and it makes me sad.
Re: Yet another NES palette topic
by on (#160001)
rainwarrior wrote:
iNES headers are practical. Why wouldn't you use them for your emulator? They make it very easy to tap a huge existing library of files to test with. I can't think of a single NES emulator that doesn't support iNES headers

Pasofami :P
Re: Yet another NES palette topic
by on (#160003)
tepples wrote:
rainwarrior wrote:
iNES headers are practical. Why wouldn't you use them for your emulator? They make it very easy to tap a huge existing library of files to test with. I can't think of a single NES emulator that doesn't support iNES headers

Pasofami :P

I'm pretty sure Pasofami eventually added iNES support. It did have its own format too (because it existed before iNES did), but even the last released version came with two .NES demo files.
Re: Yet another NES palette topic
by on (#160005)
rainwarrior wrote:
How would you tell the difference between "off the internet" and a new dump?

The presence of iNES headers in NES ROMs, and the names of SMS ROMs suggest that these files have been downloaded from the internet, rather than obtained from the companies' own archives, but I obviously can't prove anything. It just makes sense to me... I can see obtaining such old things internally being a bureaucratic process.

Quote:
iNES headers are practical. Why wouldn't you use them for your emulator?

Most emulator authors get their ROMs from the internet, as do players that use these emulators, so it makes sense to stick to a standard. A company that's releasing games officially, however, doesn't need to worry about community standards because it's providing both the emulator and the ROMs, so if they were indeed using their own binaries they could have added meta-data to them in a multitude of other ways, but instead they chose to legitimize the format that was created as a product of what they consider illegal activity. That'd be at the very least weird.

Quote:
I will say, though, I am annoyed they didn't implement PAL DPCM speeds properly;

Another example confirming they don't care as much as the community does.

My point is, if using an RGB palette created by Nintendo themselves makes you feel any better, and you really think that the visual result is better, then by all means, use that palette, but I seriously doubt that it's in any way more accurate than all the other options we have.
Re: Yet another NES palette topic
by on (#160006)
tokumaru wrote:
rainwarrior wrote:
How would you tell the difference between "off the internet" and a new dump? (Unless it was a copy of a popular bad dump, or had "diskdude" in the header, there wouldn't be any difference.)

The presence of iNES headers in NES ROMs, and the names of SMS ROMs suggest that these files have been downloaded from the internet, rather than obtained from the companies' own archives, but I obviously can't prove anything. It just makes sense to me... I can see obtaining such old things internally being a bureaucratic process.

It was a rhetorical question, which I hoped I'd clarified in parentheses, but it's literally the same data either way. My point is that it doesn't matter even slightly where the ROM came from. It's still the correct data.

tokumaru wrote:
rainwarrior wrote:
iNES headers are practical. Why wouldn't you use them for your emulator?

Most emulator authors get their ROMs from the internet, as do players that use these emulators, so it makes sense to stick to a standard. A company that's releasing games officially, however, doesn't need to worry about community standards because it's providing both the emulator and the ROMs, so if they were indeed using their own binaries they could have added meta-data to them in a multitude of other ways, but instead they chose to legitimize the format that was created as a product of what they consider illegal activity. That'd be at the very least weird.

I don't think it's weird at all, though it is slightly humorous.

I think the concern over whether this "legitimizes" emulators is a purely ideological concern that has really nothing to do with the practical problem of building an emulator. iNES format is convenient and useful, it has practical value. There's lots of reasons to use it. Why would someone working on an emulator at Nintendo want to do it differently? Using iNES makes it easier for them to test and compare against other emulators, which I'm sure they do. Creating a new format would be a waste of time for zero gain.

The iNES header is not meta-data, it is required information about the contained game (more or less). The VC does have some additional metadata, stored elsewhere (e.g. those filenames in the SMS post you linked).
Re: Yet another NES palette topic
by on (#160007)
rainwarrior wrote:
My point is that it doesn't matter even slightly where the ROM came from. It's still the correct data.

Of course, it doesn't make a difference in the final product, but I mentioned this as an example that companies don't necessarily do everything by the book just because they created the games/consoles in the first place. If they indeed took the shortcut that's downloading illegal ROMs, because it's easier/faster than going through the process of obtaining old binaries internally, do you think they would dedicate any time to studying how to make the most accurate palette? I don't think so.

Quote:
I think the concern over whether this "legitimizes" emulators is a purely ideological concern that has really nothing to do with the practical problem of building an emulator.

I didn't mean legitimizing emulation as a whole, just this particular file format. From the moment Nintendo starts using it in their official releases, it becomes the official way to store NES games outside of a cartridge.
Re: Yet another NES palette topic
by on (#160010)
Virtual console games do use the iNES file format, but nothing it being Nintendo licensed makes their palette any better than any other emulator.
Re: Yet another NES palette topic
by on (#160011)
Going back to the OP's question:
zomgwhat wrote:
I was wondering how feasible it would be to take the RGB triplets and determine if Nintendo just picked colors that looked good, or if they actually converted the NTSC to RGB using the same methods as found at http://bisqwit.iki.fi/utils/nespalette.php and http://drag.wootest.net/misc/palgen.html. If the latter, does anyone with more familiarity with NTSC video and the math behind the conversion know which values of Hue, Saturation, Brightness, Contrast, and Gamma they used?

If I was to try and analyze a given NES RGB palette, I'd probably start by plotting it on a CIE graph, just like in drag's palette generator that you linked. That would give you an easy way to compare it against other palettes. You should see the same patterns (i.e. 4 elliptical rings, some adjustment for saturation, etc.) and it would give you a good visual idea of how you could make more detailed comparisons from there.
Re: Yet another NES palette topic
by on (#160046)
Dwedit wrote:
Virtual console games do use the iNES file format, but nothing it being Nintendo licensed makes their palette any better than any other emulator.

Even more so, I would not be surprised at Nintendo for modifying the palette a little to suit a game if it made it look more like current marketing wanted it to look. I don't know of this happening, but if they were to release the NES Pac-Man for example, I would not blame them for changing the orangey-yellow to a full on bright yellow. (They wouldn't bother releasing the NAMCOT home version when the arcade one is available, but it is listed as an example).
Re: Yet another NES palette topic
by on (#160073)
tokumaru wrote:
I can see obtaining such old things internally being a bureaucratic process.

I think it's more to do with the fact that most of the time companies tend to lose their old files (especially any that changed owners in the process). There's a good reason why whenever games get altered they usually patch the ROMs instead of modifying the source code (even if the latter would have been easier).