It is currently Fri Dec 14, 2018 2:48 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 5 posts ] 

What should the two extensions be? NES colors - PPU colors
.pal and .pal 17%  17%  [ 1 ]
.pal and .dat 67%  67%  [ 4 ]
.pal and .ppc 0%  0%  [ 0 ]
.dat and .pal 0%  0%  [ 0 ]
.pal and .clu 0%  0%  [ 0 ]
.rgb and .pal 0%  0%  [ 0 ]
.yiq and .pal 0%  0%  [ 0 ]
only .pal, provide a fixed nes palette 0%  0%  [ 0 ]
something else 17%  17%  [ 1 ]
Total votes : 6
Author Message
PostPosted: Thu Nov 15, 2018 5:55 pm 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 325
Location: Rio de Janeiro - Brazil
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):
Image

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.

_________________
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!


Last edited by nesrocks on Sat Nov 17, 2018 1:29 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Nov 15, 2018 6:55 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7016
Location: Canada
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


Top
 Profile  
 
PostPosted: Thu Nov 15, 2018 9:08 pm 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 325
Location: Rio de Janeiro - Brazil
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.

_________________
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!


Top
 Profile  
 
PostPosted: Thu Nov 15, 2018 10:49 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3725
Location: Mountain View, CA
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:

Code:
Palette
  -> Import bg pal  = rename: Import native palette (BG)
  -> Export bg pal  = rename: Export native palette (BG)
  -> Import spr pal = rename: Import native palette (Sprite)
  -> Export spr pal = rename: Export native palette (Sprite)

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:

Code:
Edit
  -> Preferences
    -> Editor palette
      -> Import palette (RGB)
      -> Export palette (RGB)

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. :-)


Top
 Profile  
 
PostPosted: Fri Nov 16, 2018 7:22 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20875
Location: NE Indiana, USA (NTSC)
koitsu wrote:
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!

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group