nesdev.com

I actually reduce the resolution of my screen to 1024*768 every time I have to use Nes Screen Tool for "zooming".

_________________
This is a block of text that can be added to posts you make. There is a 255 character limit.

I draw a sample picture with windows xp paint.
I used only 7 colors and the picture is 256 x 240 :



I saved it 16 color bmp (4bit)

Then I import it to nes screen tool (Import --> BMP file as nametable) :



Why does it mess up the colors?
Do I have to clean it up manually?

NES Screen Tool doesn't use the picture itself to make the background palettes for NES.

NES Screen Tool uses the palette inside the image file.


The palette of the image you uploaded is seen on the left, above.

Every 4 colors are supposed to correspond with an NES background palette. The palettes there are impossible to make your image (there's not even a universal color), so NES Screen Tool doesn't do well.

I set up the palette properly (white is universal):

And this is the imported result with no changes/cleanup:

Note that the tree bark got the same color as the sun. This is because NES Screen Tool tries to find the closest match in the actual NES palette to the palette in the image. The closest match for those two different colors ended up being the same color. But you can just change that palette color since it is still separate:



You need to use an image editor with actual palette control to set up the palettes. Graphics Gale is a program that will let you do this for free.

Here's the image you uploaded with a fixed palette:

_________________
https://kasumi.itch.io/indivisible

What is the name of this software?

That was Aseprite.
As stated in the post, Graphics Gale is another option which is free for this if you're not into buying or compiling Aseprite. The free, older version of Aseprite will let you do it, but it's not as convenient in that one as Graphics Gale.

_________________
https://kasumi.itch.io/indivisible

I swapped (drag and drop) and replace (ctrl + drag and drop) the palettes.
But as you can see the whole colors are messed up!

If you shift click and drag, you can move the colors around without destroying the image.

_________________
https://kasumi.itch.io/indivisible

Thank you it works now

What is the rule to arrange those colors?
Do I have to visually check out the adjacent colors and put them in one group?
Is there any tutorial on how to covert a picture to tileset, name table + attribute, palette?

I'm not sure I understand the question.

It's the NES background palettes, arranged as they would be on the NES.

Index 0, 4, 8, and 12 are the universal color (color 0). Index 1, 5, 9, and 13 are color 1 for each of the four palettes. Index 2, 6, 10, and 14 are color 2. Index 3, 7, 11, 15 are color 3.
Index 0, 1, 2, and 3 are palette 0. Index 4, 5, 6, and 7 are palette 1. Etc.

On NES, each 16x16 pixel (2x2 tile) region can use the four colors from any one palette. Colors 0 must be the same color in all four palettes. If you draw an image where there's 5 colors in a 16x16 pixel region, or one that uses 4 colors that don't match any of the given palettes, it's not going to work.

I chose white as the universal color because it's the most common (or at least overlaps with more than the green), and worked out which palettes were needed by the image from there. But you can arrange your palette however you like, so long as it doesn't break the above rules. Ideally you draw with the palette restrictions in mind, rather than drawing an image, and then trying to constrain it to palettes.

Edit: I guess the last line was edited in or I missed it. I don't know of a tutorial (or software) to get an arbitrary picture broken down into tiles with decent guessed palette info. I was working on something like that, but it will require more time that I do not have at the moment.

_________________
https://kasumi.itch.io/indivisible

There is an alternative approach, where you literally just give the converter a 256x240 pixel PNG image plus a 32-character hex string representing the NES palette that you want to use. However, it requires installation of a Python interpreter as well as use of the command prompt.* This "savtool", as I call it, is bundled with my graphics editor for NES.

Or do you require that it be point and click and in the form of a single EXE for the Microsoft Windows operating system? If so, let me know, and I may put it on my list of things to make for the community once The Curse of Possum Hollow wraps.


* I prefer the command line for data conversion tools like these because it allows me to script the conversion in a makefile, so that when I edit the original PNG image, Make can detect the changes and re-run the conversion.

I think we need a tool that let people design their picture inside of it and then generate chr.bin name.bin and palette.bin

I bet that 90% of the tools were written because people were unsatisfied with the current tools. NES screen tool can be used to do what you want, just slowly.

I've recently looked at the source code of NES screen tool, thinking about changing things, or adding functions, but it's entirely uncommented... so I don't know if I can even convert it to a form that I can compile, let alone add features to.

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

I find it futile to implement drawing tools from scratch. Most artists are already used to advanced drawing programs, with things like layers, transparency (for onion skinning), animation, and so on. Implementing all of these things from scratch is not at all trivial, especially if you want to convince artists to switch over from whatever it is they're already used to. Few programmers would be capable (or willing) to implement something as versatile as Photoshop or GIMP inside their little tile editors.

A customized graphic drawing software for NES can help the designer to stay within the limitations while drawing the picture.
Designing the graphic with modern softwares and then converting it to use with NES gives me really headache.
I bet nes designers used such a customized software back then.

Yes, and the early games look really blocky and flat because of all the limitations of the drawing process that was used back then. Pattern tables, name tables, palettes and such are aspects of the distribution format, and editing directly under those constraints can be very limiting for artists. I know I often break the rules of NES graphics, doing things such as using more colors than allowed to color code parts of the drawing before applying the final colors and effects. An editor that only allowed 4 colors per tile taken from 25 colors distributed in 8 palettes would never let me work like this. Sometimes we break the rules temporarily as part of the creation/cleanup process, meaning that the restrictions imposed by the hardware should not be applied/enforced until the very last step. This might not be clear to people who are not artists, but not everyone works exclusively with the delivery format.

This is similar to questioning why an illustrator uses brushes, transparency and vector tools when the final product he must deliver is just an array of RGB pixels. Sure, he could just open MS Paint and draw the entire picture pixel by pixel, but it'll take much longer and the result will hardly be as good. It's much better to let artists choose their own limitations during the creation process, and just create the final product by exporting/converting.

Nowadays we have very advanced tools to do things, and trying to mimic the way things were done in the 80's does NOT make your retro games any better. Back then they often used crude assemblers, that only supported tiny labels, no macros, and so on. Why would anyone choose to work under those limitations nowadays, when we have much better tools?

I'm not saying that everyone should draw their NES graphics in Photoshop or GIMP... in fact, I personally think that's overkill. But every artist already has their own workflow, and telling them to drop that in favour of the quirks of a tiny little editor will hardly give the best results. That's why I think it's better to focus on the conversion process and optimization of the distribution data, rather than pointlessly trying to offer good drawing tools, which may not be easy to do, and will hardly please artists anyway.