CHR Editor for *nix?
Moderator: Moderators
CHR Editor for *nix?
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.
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.
Re: CHR Editor for *nix?
Bob Rost saves the day, sort of. NES Sprite Tools.
Re: CHR Editor for *nix?
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.Imperial wrote:I'm able to compile and run .nes binaries with FCEUX.
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.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 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.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.
Sorry if I an't recommend a specific tool, my experience with LINUX is very limited.
Re: CHR Editor for *nix?
If you have a working Java runtime installed, you can try Tile Molester.
Re: CHR Editor for *nix?
Noted. Thank you.tokumaru wrote: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.Imperial wrote:I'm able to compile and run .nes binaries with FCEUX.
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.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.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?)
Yeah, it became clear that the bmp which I got from chr2bmp was very, very different from hexedit's output.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.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.
It's okay. The good news is that there is code available that I can use if I need to figure something out.Sorry if I an't recommend a specific tool, my experience with LINUX is very limited.
Re: CHR Editor for *nix?
Thank you. If it'll work, it might help. Currently I don't have Java installed.Joe wrote:If you have a working Java runtime installed, you can try Tile Molester.
Re: CHR Editor for *nix?
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'
Re: CHR Editor for *nix?
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.
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.
Re: CHR Editor for *nix?
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.tokumaru wrote: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.
EDIT (2018): updated install command to reflect use of Python 3 and package rename
Re: CHR Editor for *nix?
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.tepples wrote: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.
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.
Re: CHR Editor for *nix?
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.
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.