This palette also includes a hack for getting a better 00 ~ 30, 0D~3D range. Reckless!! Use at own risk

Why would you do this? If it's intended for use in an emulator it'll just make games that use $20 as white look dull. If it's intended for use in making NES graphics, those colours aren't going to work on the real thing.

hawken wrote:

I think I have the .pal file laid out correctly, but not really sure how to convert for FCEUX to test out. If anyone can help?

The .pal file should have 64 x 3-byte RGB entries (or 512 if including emphasis), so either 192 or 1536 bytes. I don't know how you arrived at 631 bytes.

This palette also includes a hack for getting a better 00 ~ 30, 0D~3D range. Reckless!! Use at own risk

Why would you do this? If it's intended for use in an emulator it'll just make games that use $20 as white look dull. If it's intended for use in making NES graphics, those colours aren't going to work on the real thing.

(theoretically it's just a luminance ramp, $20 was "meant" to be light grey. Would be interesting to know how it came out on actual PAL / SECAM sets with their differing chrominance. As shown above, $20 is a light grey on SECAM - although that might be the machine - I imagine artists went for $30 as white?)

Can take these out of the final .pal, this is just a test.

rainwarrior wrote:

hawken wrote:

I think I have the .pal file laid out correctly, but not really sure how to convert for FCEUX to test out. If anyone can help?

The .pal file should have 64 x 3-byte RGB entries (or 512 if including emphasis), so either 192 or 1536 bytes. I don't know how you arrived at 631 bytes.

The .pal file is output from ASEprite (64 lines plus header), I may be out of my depth here but why does FCEUX need .pal in 8bit colour space?

The .pal file is output from ASEprite (64 lines plus header), is there a utility that can convert to the way FCEUX needs it?

Opening it with a hex editor I discovered it's a "JASC-PAL" format. Never heard of this one before, but it looks like a simple text file containing a list of decimal triples.

Apparently there's also a Microsoft .pal format that's different.

Those are the two most common .pal formats, FCEUX is custom

Thanks I'll look in to converting to 8bit colour space 3-byte. The FCEUX .pal files are a little confusing (at least to me) in a text editor as there's 12 rows of 8 entries (96 entries) [edit: ah I get it]. Also does anyone know why do they need to be in 8bit colour space?

It's a very simple and natural format used by other NES emulators, though. It's not intended for anything but NES palettes, e.g. there's no header to say how many entries there are supposed to be, because there's only one way to do it, really. I don't think it originated with FCEUX, either.

Oh, so the idea is based on some particular piece of Dendy clone hardware?

hawken wrote:

I imagine artists went for $30 as white?)

In NES games, no, not really. $20 and $30 are supposed to be the same white, and there are practical reasons why you might want to use $20 instead of $30. The main one I can think of is that it makes fading out look more natural when white doesn't persist for an extra step of the fadeout.

Some games prefer $30, some prefer $20. (Some appear to use both, e.g. Jaws.)

Last edited by rainwarrior on Sun Mar 05, 2017 10:44 pm, edited 1 time in total.

In NES games, no, not really. $20 and $30 are supposed to be the same white, and there are practical reasons why you might want to use $20 instead of $30. The main one I can think of is that it makes fading out look more natural when white doesn't persist for an extra step of the fadeout.

I was reading a bit about what "official" games were allowed to use and Jaws is a pretty rare case, apparently developers were asked not to use $30 because it caused problems with some CRT sets as it was "whiter than white" - indeed games would be rejected by Nintendo if they used #30. The same went for $0d as it was "blacker than black" (not sure what damage that could do though). $e & $f range were not allowed either.

Having trouble converting this for FCEUX (as it requires 8bit colour depth), which this is not. The quest ends here

I was reading a bit about what "official" games were allowed to use and Jaws is a pretty rare case, apparently developers were asked not to use $30 because it caused problems with some CRT sets as it was "whiter than white" - indeed games would be rejected by Nintendo if they used #30. The same went for $0d as it was "blacker than black" (not sure what damage that could do though). $e & $f range were not allowed either.

Having trouble converting this for FCEUX as it requires 8bit colour depth, which this is not. The quest ends here

I don't know what your sources are for this but they're completely bogus. (If you'd care to share the source, I'm sure there's people here who wouldn't mind correcting them.)

Again, $30 is the same as $20 by design, so this "whiter than white" idea makes no sense.

Super Mario Bros. uses $0F for black, and $30 for white. (So do a lot of games.) I'm certain that $0E is acceptable too, but I don't have a common example offhand.

I mentioned Jaws only as a weird case that I happened to notice uses both $20 and $30 on the same screen.

Nintendo didn't really have a way to test for and reject $0D either. For example, the common TMNT uses $0D and it made it through all licencing tests and was one of the highest selling games for the system. It doesn't use large amounts of it on the screen, just for sprite outlines, so I don't think it tends to cause the common desync problems, but my point is I don't believe they did any sort of categorical test for the use of $0D.

Who is online

Users browsing this forum: No registered users and 2 guests

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