Thanks for trying it! I consider that use within the intent. Easier image->CHR is why I made it. It fixes two of my bigger issues with other tools. (Requiring creation of indexed palettes/images, and rejecting images that use colors outside an arbitrary NES palette.) Of course, creating a palette still helps if you want a specific result.FrankenGraphics wrote:I just had a first go with this tool, though maybe not for what it was primarily intended for but for one of its side features? It helped me organize a sprite overlay made in PS into a tidy chr at perhaps a quarter of the time it would take doing that with nesst
There are two types .pal files associated with NES.Any chance you might be interested making it accept a NES .pal binary as an option? I usually have those ready anyway while a bitmap strip on the other hand needs to be made. Not much of a problem, but i might as well ask.
If you mean load a 192 byte NES palette from an emulator .pal instead of "Assets/nespal.png", probably.
If you mean load a 16 byte NES Screen Tool palette instead of "(file)_palette.png", you'd still end up needing to either provide "(file)_palette.png" or hack "Assets/nespal.png" to ensure a specific result.
Image->Bitmap Strip Palette->.pal indices. (The bitmap strip ensures the index order of the colors is preserved, and the .pal replaces the color algorithm's guessed indices with the indices actually intended for each color. You'll get exactly the result you want.)
Image->.pal indices (It would look up each color index provided within the included palette, and then find the closest color in the image. But there's potential for say... two similar blues to have their color indices swapped due to the differences between the palette your .pal refers to and the included RGB palette.)
I don't think it'd be too hard, just realize you would have to change "Assets/nespal.png" to match the NES Screen Tool palette (which your .pal refers to) as well as only use colors in the NES Screen Tool palette in the image itself to ensure a specific result if you didn't also provide a bitmap strip. Let me know if I'm misunderstanding.
To answer the why...I’m curious as to why the output chr starts (at least in this particular case) with a series of identical blanks? Are those reserved?
Short answer: They're not reserved, but they're padded because of the animation support. It grows from 255 down rather than 0 up.
Longer Answer: I wanted the tiles to be contiguous and I wanted animated tiles at the end of the set. The diving girl is 65 tiles, 64 of which are animated. So all the animated tiles are put starting from tile 63 to 0 of one 64 tile bank, leaving one tile at the very end of a new 64 tile bank (to satisfy the contiguous condition). Starting at tile 0 would mean two 64 tile banks for every frame instead of one (to satisfy animated tiles being at the end of the set.)
You bring up a good point that this isn't too intuitive a default configuration for people not working with the bank swapping features. I'll come up with something to help with this.