It is currently Tue Dec 18, 2018 6:48 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Thu Jul 26, 2018 10:43 pm 
Offline
User avatar

Joined: Thu Jul 26, 2018 10:27 pm
Posts: 5
Location: San Francisco, CA
Hi nesdev forums!

First time poster, here!

Back in 2003, I started working on a tool called nesromtool that I mostly got working to the point where you could transfer tiles between rom files and do some basic import/export in photoshop raw format, but then got distracted with gamecube hacking and never really picked it up again. But a few weeks ago, I was thinking about this and decided that it would be interesting to pick it back up again and rewrite it using everything I've learned in the past 15 years.

nesromtool2 is a package of commandline utilities for macOS, Linux and other *nix-like OSs. Licensed via the MIT software license, it currently (at the time of this post) supports:

    * validating nes ROM files in the iNES format (validating headers and data size)
    * dumping information about ROMs (CHR/PRG bank count, some mapper info, etc)
    * the import and export of CHR and PRG banks
    * import and export of CHR as either raw or PNG files (2-bit indexed color)
    * getting/setting/removing title metadata

There's also a pair of helper tools: chr2png and png2chr which can help during development so you can convert PNG files into CHR banks in your Makefile, for example. As long as the PNG remains in indexed color and only the first 4 colors in the palette are used, they can be re-imported.

I'm not sure if this is the right forum to post this, but I figured I'd get this out there so folks can take a look and give me feedback on it. It's still got a ways to go, but it's pretty well documented and should be more or less bug free (of course, now that I said this, it's gonna completely fail to compile).

Check it: https://github.com/sadistech/nesromtool2


Top
 Profile  
 
PostPosted: Thu Jul 26, 2018 11:49 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1024
These things may be good to have, but I have a comment about this part:

Quote:
There's also a pair of helper tools: chr2png and png2chr which can help during development so you can convert PNG files into CHR banks in your Makefile, for example. As long as the PNG remains in indexed color and only the first 4 colors in the palette are used, they can be re-imported.
I wrote Farbfeld Utilities, which can do these things. See the bitff and ffbit programs, as well as perhaps ff-strip, to deal with CHR files. See pngff and ffpng to deal with PNG files. Indexed colour is not necessary, though; these programs can work with any kind of PNG file.

Quote:
nrt (as it shall now be referred) is a commandline tool used to aide work with NES ROM files in the iNES v1 format.
Perhaps NES 2.0 should be supported too (in addition to the old format).

My own opinion of design is the UNIX philosophy:
  • Each program does one thing, and is doing one thing well.
  • Each program should act as a filter (using stdin/stdout).
  • You have enough ropes to hang yourself and also a few more just in case.

_________________
.


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 6:57 am 
Offline
User avatar

Joined: Thu Jul 26, 2018 10:27 pm
Posts: 5
Location: San Francisco, CA
Thanks for the reply!

Quote:
My own opinion of design is the UNIX philosophy:
Each program does one thing, and is doing one thing well.
Each program should act as a filter (using stdin/stdout).
You have enough ropes to hang yourself and also a few more just in case.


I agree here, and I think I've read this before, somewhere...

I was a bit torn on how to approach the nrt utility and initially had planned to have it be a series of separate tools, especially when I started documenting how I wanted the use-cases to be. The issue I ran into was that naming things nrt-title and nrt-chr didn't really get me anything when it came to simplifying the CLI API, so I stuck with a single tool as the old one was. But it should be relatively trivial to break it all out into separate tools since that's how the code is structured, anyway.

I spent about 4 days going back and forth making it both ways to see which I liked better and I figure it's generally better to ship something than not. paralysis through analysis and all that.

I'll revisit this, but it's also the reason that chr2png and png2chr are standalone utils. the API was straight-forward to design and those made a lot of sense to be built that way.

I also failed to mention that another goal of this project is to provide a low-level C library for working with these ROM files, so bindings could be added to other languages like python, node, or even bash.

Quote:
Perhaps NES 2.0 should be supported too (in addition to the old format).


This is definitely on the roadmap. Are patches still a thing? I had some code for the IPS patch format, but I don't recall if that was ever bug-free or even worked in my original code-base.

Quote:
I wrote Farbfeld Utilities, which can do these things. See the bitff and ffbit programs, as well as perhaps ff-strip, to deal with CHR files. See pngff and ffpng to deal with PNG files. Indexed colour is not necessary, though; these programs can work with any kind of PNG file.


I'm curious how this fits in to the CHR bitmap format since it's only capable of having a 4-colour palette per tile and is indexed color. Last week, I googled around and found that someone had made a nodejs utility for converting PNG->CHR, but the way they did it was by converting the image into 4-colour greyscale and assigning colors to the palette. Back when I was in graphic production, techniques like this led to some really incorrect edge-cases, so I wanted to avoid that by allowing the user to be very precise with their source PNGs.

Thanks for all the input! If you've got any other suggestions, let me know!


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 8:03 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
I made a program that lets the user specify a PNG file and a 32-digit background palette string, and it attempts to convert the image using that palette. See "savtool.py" in pinobatch/nesbgeditor.


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 11:09 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 857
I had also written chr2png and png2chr back in 2015.


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 11:11 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1024
spizzike wrote:
Quote:
I wrote Farbfeld Utilities, which can do these things. See the bitff and ffbit programs, as well as perhaps ff-strip, to deal with CHR files. See pngff and ffpng to deal with PNG files. Indexed colour is not necessary, though; these programs can work with any kind of PNG file.


I'm curious how this fits in to the CHR bitmap format since it's only capable of having a 4-colour palette per tile and is indexed color. Last week, I googled around and found that someone had made a nodejs utility for converting PNG->CHR, but the way they did it was by converting the image into 4-colour greyscale and assigning colors to the palette. Back when I was in graphic production, techniques like this led to some really incorrect edge-cases, so I wanted to avoid that by allowing the user to be very precise with their source PNGs.!
The bitff and ffbit programs of Farbfeld Utilities require you to specify the colours.

_________________
.


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 4:20 pm 
Offline
User avatar

Joined: Thu Jul 26, 2018 10:27 pm
Posts: 5
Location: San Francisco, CA
calima wrote:
I had also written chr2png and png2chr back in 2015.


ha, oh man. I need to do better research. could you provide a link?


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 4:23 pm 
Offline
User avatar

Joined: Thu Jul 26, 2018 10:27 pm
Posts: 5
Location: San Francisco, CA
zzo38 wrote:
The bitff and ffbit programs of Farbfeld Utilities require you to specify the colours.


ahhh, ok. I got it. that makes sense. thanks for the clarification.

I wonder if that would make sense for my tooling. My thought is that the user should be able to control the format of the file from their graphics editor and deal with it there. ie: ensure that they're using indexed colour and only utilize colours 0-3 in the palette. Seems like that would be the best place in my case.

Do you agree?


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 4:23 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2356
Location: DIGDUG
Also...

I've been meaning to test this, plug in for GIMP.

https://www.romhacking.net/utilities/1405/

imports and exports...
"NES 1bpp
NES 2bpp
SNES/GB 2bpp
NGP 2bpp
GBA 4bpp
SNES 4bpp
GG/SMS/WSC 4bpp
MD 4bpp"

into GIMP

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 4:34 pm 
Offline
User avatar

Joined: Thu Jul 26, 2018 10:27 pm
Posts: 5
Location: San Francisco, CA
dougeff wrote:
Also...
I've been meaning to test this, plug in for GIMP.


Oh man, that's awesome. I'll have to dabble with this. My GIMP skills are nearly non-existent (I'm a former photoshop guy but don't have a copy of it on my main machines).


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 4:37 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2356
Location: DIGDUG
Just noticed this in the documents...

"Palettes: Does not yet import palettes and defaults to internal standard palettes"

Hmm. I don't think it does what I wanted it to do. Although, maybe it can be useful anyway.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Fri Jul 27, 2018 5:06 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1024
spizzike wrote:
zzo38 wrote:
The bitff and ffbit programs of Farbfeld Utilities require you to specify the colours.


ahhh, ok. I got it. that makes sense. thanks for the clarification.

I wonder if that would make sense for my tooling. My thought is that the user should be able to control the format of the file from their graphics editor and deal with it there. ie: ensure that they're using indexed colour and only utilize colours 0-3 in the palette. Seems like that would be the best place in my case.

Do you agree?
I can neither agree nor disagree, but nobody seems to be stopped from using nesromtool2 and Farbfeld Utilities together if you want to do so, anyways.

(Note also that farbfeld is a 16-bits-per-channel true-colour format, so it does not do indexed colours, although the pngff program can still read indexed colour PNG files, and ffpng will automatically determine what colour format to use (and this auto-detection can also be overridden by the user).)

_________________
.


Top
 Profile  
 
PostPosted: Sat Jul 28, 2018 2:15 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 857
https://forums.nesdev.com/viewtopic.php?f=21&t=13339


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 4 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