I've tried raw2chr and bmp2nes and they never work for me. Probably because I can't find any graphics software that will save in a 2 bit colour format. I even found software that would save in interleaved raw data from but never in 2 bits form. Any ideas? If I can't find anything, I'll code something that will take a .bmp with 4 colour bits but only 4 distinct colours and convert it into a .chr (interleaved 2 bitplane 8 pixel/2 byte graphics format). Does anybody know of any windows or DOS software that will import/draw and save to a 2 bit bitmap or a 2 bit colour interleaved RAW format? Thanks for any help.
I've been working on something called "bmp2tiles" that takes an indexed image and turns it into tiles for any of several formats (1-bit, NES, GB, SNES, Genesis, GBA, etc), but I haven't yet had a chance to make a proper package of it. Want it?
For converting graphics I've had alright luck using Tile Molester and Tile Layer Pro.
Hi, thanks for your replies. I didn't realize Tile Molester was such a powerful program. It looks like it will be just what I needed. Tepples: I would be happy to try your program if you want to send it to me.
I always use YY-CHR for all my graphics needs
works excellent both for nes and snes
YY-CHR is the best! Without a doubt (in my mind) the best graphics editor for the NES out there! Okay, now let's not get in a debate where everyone's like: "No, Tile editor pro is the best" then "No, Tile molester is the best" then "No, YY-CHR is the best", because I really really hate when people debate about useless crap! I think YY-CHR is the best! If you don't! Deal with it! Sorry, I've just seen too many really long threads on sites where people debate about useless crap, then there's that one person who's like, "Can't we all just get along?" and it's the cheesiest thing I've ever seen! Just don't start debates, and you'll be fine! Okay, I'm done.
If you're creating a new console program from scratch (as opposed to CHR hacking a commercial title), then the best console graphics editor is any bitmap editor you darn well please followed by a conversion to the console's native format. Using a command line converter lets this happen automagically whenever you change the bitmap, thanks to the power of GNU Make.
Doesn't seems to work good... I just got random pixels in output file.
I use a program I wrote a while ago:
http://www.nesstuff.kit.net/nestc.jpg
You have to change the extension from JPG to RAR, my server won't take RAR files so I had to rename the file.
It is very simple, it is not an editing APP, it just does the conversion. I figured out it was a waste of time trying to write a nice image editing GUI, wich can be really hard, when there are nicer tools around. In my program you can only open a BMP, pick 4 colors from it and then convert to the NES format. There are some limitations, if I remember correctly, like the BMP file must have dimensions multiple of 8 pixels, since it will be converted to 8x8 tiles.
tepples's program seems very nice. I'll check it out at home.
Bregalad wrote:
Doesn't seems to work good... I just got random pixels in output file.
Are you sure you used a 4-color indexed bitmap and that you specified
-b nes? The proper command line looks like this:
Code:
bmp2tiles -b nes tst.bmp tst.chr
Oh, and "nestc" isn't really all that trustable, as a lot of sites used "nestc" as the file name for some obsolete emulator that I don't need to mention here.
Ah, so in both cases, the bitmap should already be 4 colors ? Sorry, I was thinking the conversion to 4 colors would be done in the programm, if so it is probably my fault.
Tokumaru's programm is pretty cool, because you can still convert an image with more colors using more layers easily, by picking colors.
Edit : The best by all, and the most usefull, would be to have a programm showing the list of all different colors used in the BMP file, and each one would be manually pointing to one of the four NES colours. So an image doesn't need previous conversions, anyone can easily design two or three layers/attributes aeras to allow more depht, and the thing is still done by hand, so you won't have bad result as in Tile Layer / Tile Molester.
I'll try these programs sometime.
I'd still like to see a gfx converter for my crazy FAU format. The one that alternates between changing one palette entry and one attribute byte every scanline. I bet that's a little hard to write, I wonder how stuff would look with it though.
Bregalad wrote:
Tokumaru's programm is pretty cool, because you can still convert an image with more colors using more layers easily, by picking colors.
Yeah, sometimes I do that. Colors you don't pick turn into 0's, allowing for you to pick groups of colors separatelly. The problem is that you'll have to rename the image for that, as the program always saves the CHR with the same name as the BMP. The program is far from perfect, but for converting stuff for original games it works great. It is less complicated then most command line app's.
In fact I wrote a command line DOS converter long before I wrote this one. It's the crappy bmp2nes that's on the nesdev page, when I used the name "q7h1460". That one only reads 8-bit BMP's and you must use the first 4 indexes. Not easy to get that right without complex image editing software. Since I draw most my stuff in mspaint, I needed another converter.
Memblers wrote:
I'd still like to see a gfx converter for my crazy FAU format. The one that alternates between changing one palette entry and one attribute byte every scanline. I bet that's a little hard to write, I wonder how stuff would look with it though.
I think I never heard of it. Seems pretty interesting. Is that all that's possible to do during HBlank? Change 1 palette entry and one attribute byte? What would be a practical use for changing the attribute byte? Wouldn't it be beter to change 2 or more palette entries? If they are consecutive, would it be possible to change a full palette (4 colors)?
How does it work? After changing the stuff you have to set up $2005 and $2006 again? If we could change a full palette every scanline, that would kick ass!
Has this been discussed before? Could you point me to that discussion? I vaguely remember that...
I'd like to know more about this format... I'd be interested in writing a tool to convert to such a format, that allows the NES to show more beautifull images.
It was discussed a while back, on the old forums.
http://nesdev.com/cgi-bin/wwwthreads/showpost.pl?Board=nesdev&Number=1312
Here's the (old) source, if anyone wants the newer version let me know and I'll retest it. I think it mostly worked at that point, but was slightly broke.
http://mywebpages.comcast.net/memblers/fautest.zip
latest test version (July 2004):
http://mywebpages.comcast.net/memblers/fau.nes
There's not enough time in hblank to do much, so it shuts the screen off early. Even then, since it has to set and reset $2006 and $2005 there's only enough time for one $2007 write. If it blanked every odd scanline and displayed the even ones it could change the palette a lot more, I bet. Though it would halve the vertical resolution and put in horizontal bars..
So the current code for each scanline switches between changing a palette entry and changing an attribute byte. Changing the attribute byte like this was supposed to allow for more color varations. But I don't know if that part of the program even worked (the test data doesn't seem to do much with it).
Man, this looks to be damn OLD !!! Before I even enteren in NESDev scene.
I remember trying to understand how your FAU works, and I never got it at all. What advantages does it exactly features ? More colors, but how exactly ? What's up with attribute tables, I can't see much interest by modifying them ? Will gabarage show up on the rightmost border of the screen ? How fine works to set-up scrooling regs every scanline ?
How could this format be used in an actual game ? To enhance portrait or cutscenes ? Could this be converted to work on a PAL system ?
Hrm... I take it it's not supposed to jerk around like it does in my emu and Nintendulator?
I'm particulary interested in the "blank every odd scanline" thing. The blank lines are not such an ugly thing to look at, and a full scanline will give you enough time to change all the palettes, I suppose. 13 unique colors per scanline! Can you imagine that? The images would look great. Of course, we'd still have the limitation where every run of 16 pixels has to share the same palette, and the ammount of data needed for such a picture would be huge.
Maybe if we cut some of the left AND right side of the screen (without the blank lines) we'd be able to change 1 full palette, that would be great. It seems useless for the in-game parts, but is very usefull for cutscenes.
I'd imagine writing to the palette mid-frame would be difficult, since when the PPU is off and the PPU address is in the palette range (3Fxx) it will render whatever color is stored at the current address (not always the color at 3F00)
Oh yeah... I forgot about that detail... so, no blank scanlines!
The effect would be useful for a game if it was simplified more, actually I was inspired by Chris C.'s stretch demo to make a racing game with ramps, hills, mountains.. heheh. The trick lets you scale the background vertically. That got me wanting to figure out how to use $2006 mid-frame without glitches. I never wrote any of that game though, just the FAU-mode test. The palette and attrib table changing was just to see how far I could push it.
see the fau.txt file in the zip for what I wrote about it, it's not real useful though.
The attribute thing was supposed to allow certain blocks to be as small as 16x2.
Yeah, there is some garbage on the right border. You can see the variations in the timing, and also there's a black comb-like thing on the edge.
I think it does jerk around sometimes on a real NES. Resetting would fix or break it, I can't recall if I fixed that in the last version.
This remember how the text boxes work in the SNES game Tales of Phantaia, where the SNES background color is changed every sacnline with a tricky trick. In menu, there is sometimes some more tricky tricks combinating transparent sprites and background color to allow this effect only available on a small horizontal block of the screen.