Terminology for palettes and palettes

Hi, I am developing a graphics editor for NES development. I want to make it as feature rich as I can. The idea is to cover all graphical assets creation needs and be as confortable for artists to use as possible, while exporting NES ready binary files as well as a parsable JSON format if the user so chooses. Going crazy with ideas, I want it to have metasprites animations, parallax simulations (this just for mockups), etc.

Here's how it currently looks (very early in development):


What I want to know is a simple question: what would be the best extension for the NES colors palette (containing RGB representations of each of all available colors) and the PPU palette containing the 32 colors currently in use? I want to let the user use whichever palette he wants and not be stuck with one or a list of palettes I provide, but then there's the problem of calling everything palettes and the files all being .pal, as they are obviously not compatible.

YY-chr differentiates these as .pal and .dat. But dat is too generic to me.
NST only has pal and I think you can't choose another color set.

Since the user will handle PPU palettes a lot, I thought maybe keep those as palettes/.pal and choose another name for the NES colors values. Maybe .yiq? .rgb? Would it be called "NES Colors" or something?

Then again, we download palettes and they are all .pal. There doesn't seem to be a consensus.

Suggestions are welcome! Thanks.

I think .pal is nearly universally used for RGB triples for emulator base palettes.

For the 4/16/32 bytes colour index palette data used in NES games, I think there are a bunch of common ones. .bin, .pal, .dat, etc.

All I'd suggest for the latter is don't force the user to use only one of those. Let them open and save files with an extension of their choice.

For sorting out the difference between an RGB triple .pal or an NES index .pal, I think that's more of a problem for the user organizing their files, not something that a utility needs to solve. If they've thrown a bunch of these into the same folder and don't know which is which that's an issue they created for themself. ;P

Interesting. I guess I'd add an extension preference for each type of binary resource then, and it automatically uses that for each file to be exported, though it would let the user modify it when saving anyway.

Still open for more people to share their opinion though. I'm inclined to have a suggested standard that differentiates them.

IMO, the above situation (re: "For sorting out the difference between an RGB triple .pal or an NES index .pal"), to be fair, you need to allow importing and exporting of both -- but for very different purposes. There are going to be people who want to use both features for different reasons, sometimes in combination, sometimes not. This is my view on the matter:


All of these should refer to the "NES index palette", e.g. the 16 bytes that make up the native palette associated with the relevant parts of $3F00-3F0F and $3F10-3F1F. I would also suggest allowing for an import or export of both palettes in a single 32-byte file. This should make doing fancy title screens/etc. (ones which use both sprites and standard nametable tiles to make colourful screens) easier.

You can also replace the word "native" in the above menus with "NES" if you want. I chose the word "native" to imply native-to-the-NES. "Import/export palette indices (BG/Sprite)" would also be OK.

You can pick whatever file extensions you want for these, but I would recommend .bin. .pal will just confuse people, making them think that they're RGB palettes for emulators. To ensure someone can't load one of those, you should check the file contents to see if they're != 16 bytes (or != 32 bytes), and if so, tell the user that they're trying to load the wrong kind of palette file (see below).

Importing/exporting raw RGB palettes affect the on-screen colour in the editor itself, and thus should be under a COMPLETELY different menu section to differentiate the purpose. This makes the difference clear to the user. For example:


Overall, all of this will need to be explained in documentation. PLEASE WRITE DOCUMENTATION FOR YOUR EDITOR! DO NOT RELEASE IT WITHOUT DOCUMENTATION! As long as you explain this clearly in the docs, if users show up crying/whinging over it, you can say "read the documentation" with pride. We live in a time where most people don't read README.txt that comes with software etc. and that's their own fault -- do not cater to that!

Thank you for making an editor! Tools like this will greatly help people. We need more of this. :-)

"Please turn to page 5 of the manual and enter the fifth word line 3"