CHR Editor for *nix?

[Imperial]

Greetings everyone, first post here. I'm a C programmer on OpenBSD who is making just a little progress in making a game for NES. I have CC65 set up, according to Shiru's tutorial, and I'm able to compile and run .nes binaries with FCEUX. My goal is first to make Towers of Hanoi, and I'd ultimately like to make my answer to the Atari game, Adventure.

All that said, I need a tool to modify CHR files, and one that will work on BSD. I have tried a couple DOS tools in Dosbox, which certainly didn't seem to work. I'm perfectly able to run a CHR through hexedit and see the really obvious patterns of image data, but I know nothing about the format. (Got further reading?) That gave me the idea of just writing a program to open any binary file, as a hex editor, and display each byte as a color in a 256-color palette. But really, a Gimp plugin might be best for my case.

I really appreciate any help, and thank you so much for this site.

[Imperial]

Bob Rost saves the day, sort of. NES Sprite Tools.

[tokumaru]

I'm able to compile and run .nes binaries with FCEUX.

Be sure to test on other emulators (or, preferably, a real NES) as well. FECUX is a very good development tool with lots of debugging features, but the accuracy of its emulation is not the greatest. If your game works consistently across different emulators, the chances of it working well on hardware are higher.

I'm perfectly able to run a CHR through hexedit and see the really obvious patterns of image data, but I know nothing about the format. (Got further reading?)

The format itself is pretty simple: each tile is 16 bytes, where the first 8 contain the lower bit and the last 8 contain the higher bit of each pixel (a tile can use only 4 colors, so each pixel is 2-bit). That's not something easy to see/edit in hex... but you could use binary to define CHR data in your ASM file(s) if the graphics are relatively simple. An actual editor would make things much easier though. If you can't find any, a tool to convert PNGs or other formats to the NES format should be trivial to code in LINUX, and then you could use any generic image editor you have.

That gave me the idea of just writing a program to open any binary file, as a hex editor, and display each byte as a color in a 256-color palette.

That wouldn't help you much with NES graphics, since each byte represents half the colors of an entire row of pixels... so the result wouldn't make any sense or resemble the original graphics in any way.

Sorry if I an't recommend a specific tool, my experience with LINUX is very limited.

[Joe]

If you have a working Java runtime installed, you can try Tile Molester.

[Imperial]

I'm able to compile and run .nes binaries with FCEUX.

Be sure to test on other emulators (or, preferably, a real NES) as well. FECUX is a very good development tool with lots of debugging features, but the accuracy of its emulation is not the greatest. If your game works consistently across different emulators, the chances of it working well on hardware are higher.

Noted. Thank you.

I'm perfectly able to run a CHR through hexedit and see the really obvious patterns of image data, but I know nothing about the format. (Got further reading?)

The format itself is pretty simple: each tile is 16 bytes, where the first 8 contain the lower bit and the last 8 contain the higher bit of each pixel (a tile can use only 4 colors, so each pixel is 2-bit). That's not something easy to see/edit in hex... but you could use binary to define CHR data in your ASM file(s) if the graphics are relatively simple. An actual editor would make things much easier though. If you can't find any, a tool to convert PNGs or other formats to the NES format should be trivial to code in LINUX, and then you could use any generic image editor you have.

Well, Bob Rost's chr2bmp helped, and Gimp imports the resulting bmp just fine. Unfortunately, Gimp seems to have trouble exporting to a bmp which will work with bmp2chr. That's my problem now.

That gave me the idea of just writing a program to open any binary file, as a hex editor, and display each byte as a color in a 256-color palette.

That wouldn't help you much with NES graphics, since each byte represents half the colors of an entire row of pixels... so the result wouldn't make any sense or resemble the original graphics in any way.

Yeah, it became clear that the bmp which I got from chr2bmp was very, very different from hexedit's output.

Sorry if I an't recommend a specific tool, my experience with LINUX is very limited.

It's okay. The good news is that there is code available that I can use if I need to figure something out.

[Imperial]

If you have a working Java runtime installed, you can try Tile Molester.

Thank you. If it'll work, it might help. Currently I don't have Java installed.

[Imperial]

Code: Select all

$ chr2bmp tileset.chr tileset.bmp
Image 'tileset.bmp' created successfully
$ xpaint tileset.bmp
$ bmp2chr tileset.bmp tileset.chr
   Could not load image 'tileset.bmp'

Okay, so Gimp gives me a similar problem to this. After loading tileset.bmp into xpaint, and then saving it right back and closing it, bmp2chr is unable to load tileset.bmp. I have a strong feeling it has to do with the image editor changing the pixel format. However, in Gimp, even if I change the image to Indexed and set the colormap to 0x000000,0xffffff,0xff0000,0x0000ff for CHR storage, the problem is the same. Bmp2chr will not load it.

[lidnariq]

Here's a pair of very simple netpbm-compatible converters I wrote some years ago:

I like pnmtools a lot because I like command lines, so making a tool that I can just throw into the middle of a pipe makes me happy.

chr2pgm takes an optional extra argument: a scalar for previewing the CHR with grids.

Hope they're useful.

[tepples]

a tool to convert PNGs or other formats to the NES format should be trivial to code in LINUX, and then you could use any generic image editor you have.

That's how I work. My template includes a BMP/PNG to CHR converter written in Python. You may have to install Pillow (Python Imaging Library) first though. I have no idea how OpenBSD's repositories work, but under Ubuntu it's sudo apt install python3-pil build-essential to install all dependencies.


EDIT (2018): updated install command to reflect use of Python 3 and package rename

[Imperial]

That's how I work. (...) I have no idea how OpenBSD's repositories work, but under Ubuntu it's sudo apt-get install python-imaging build-essential to install all dependencies.

A quick pkg_add py-Imaging and there it is. Thank you, and I'll give your and lidnariq's programs a whirl in a bit.

Meanwhile, I do have a theory of what Gimp and xpaint did to the pixel format, and I'll have to check that out, too.

[Imperial]

Got it! I'm sure you all knew this before I did, but I'd like to write here for posterity.

When using Gimp with Bob Rost's NES Sprite Tools, you have the option to not overwrite the color space. This is easy to miss. It falls under "Compatibility Options", so look for that when trying to export. If you do not select this option when exporting to BMP, the BMP will not work with bmp2chr. (This was my problem.)

The BMP you wish to convert to a CHR must be 24bpp with only 4 colors. These are 0x000000, 0xffffff, 0xff0000, and 0x0000ff.

While it's better to create your artwork in an indexed mode with 4 colors per sprite of your choosing, when you export to BMP, you must switch the colormap to the above colors. Then, change the image to RGB 24bpp mode, and then export -- without overwriting the color space.

So, it's probably a good idea to keep these palettes around when working with Gimp or another tool of your choice.