nesdev.com

I have YY-chr99 and NES Screen Tool. In both of them I'm having trouble having 4 colors when I open my own picture that I made in MS Paint and Gimp. It opens up with either 2 or 3 colors instead of 4, making at least one of my 4 colors the same as another.

In NESST when I final found a color scheme that worked, having 4 colors, I noticed that it did not work all the time. In NESST I would sometimes get a message saying, "Too many unique characters 256" which makes wonder if I'm not supposed to save it as a 256 color bitmap when using paint. I also tried saving it in 8-bit format in paint.net but that didn't help either. It seems that NESST is limited to how many different tiles there can be on the screen at one time. My images are 256x240; Are they supposed to be a different size? Then, when I looked for tutorials using YY-chr they started out with a .chr file, so that didn't help much. Someone also said that they wouldn't ever be able to get the colors right, which made me wonder how the mapper knew the right colors in the first place. If this paragraph confuses the situation more, please help me with the problem stated in the above paragraph.

I just want to make sprites and do some background animations for like a beginning screen that's not part of a level and turn them into .chr files if that's what I need to do to get the colors right for an NES game. It would also be nice if I knew what color was used for trasparency or background. I would rather use NESST if I can get it to work; I assume, I'm just supposed to load the sprites into CHR bank B.

Post the images please? The NES backgrounds also only can have 1 primary BG color and then 3 others on 4 pallets. And sprites, color 0 namtter what it is will show the background pixel. Sprite color 0 will never have any color, although in emulation all four sprite transparencies equal pallet #0.

'Characters' are the tiles. NES can select from 256 background, and 256 sprite tiles (more can be shown at once with programming tricks though, specifically mid-frame bankswitching). By tiles I mean the 8x8 pixel tiles, of course. So it's complaining that it doesn't fit.

For a bigger image, often shifting the whole thing over by some number of pixels will produce varying amounts of unique tiles. It depends entirely on the image, the difference could be nothing or make it 10 times smaller.

I haven't used NESST specifically yet, that I can recall. Previously, I've had decent luck importing tiles using Tile Layer Pro (the windows version) and Tile Molester.

Thanks a bunch Memblers That helps out a lot! I understand now.

I'm not sure if you got your answer regarding the color import problem. I usually recolor to four basic colors so it avoids any problems when importing images. I usually use Black White Green Red.

Then I set my palettes and assign my attributes after the fact. I'm not sure if you are designing an image specifically for a background, or just want to import some sprites etc. NESST is useful for backgrounds, but like Memblers said you have too many unique tiles, so you need to pay attention to the NES constraints and design your image around them (and don't import a screen with sprites already on it).

Now I have another color problem
The transparant color for the background is not the same when switching the .pal file from NES Screen Tool to Nintendulator. Why is that, or more importantly, how does the programmer or I fix it?

I'm aware that you can export code and data for the pallet, but is that really nesseccary? Can't moving over the .pal file be enough?

I know of two kinds of palette file, and they are intended for two different steps of the rendering process. One cannot substitute for the other.

• The 16-byte one used by NSA and 8name is a dump of PPU memory $3F00-$3F0F. Its indices are NES attribute*4+pixel_value and whose values are NES color values. It's suitable for including in an NES program with ".incbin" commands in emulators.
• The 192-byte one is used by emulators such as Nintendulator. Its indices are NES color values and its values are RGB triplets. These are useful for emulating the RGB PPU in a PlayChoice or Famicom Titler and essential for emulating Vs. system games.

Thanks for helping us!
Are the colors from the 16-byte pallet near the colors from the 192-byte pallet? All of the colors look correct except the first transparent color of each pallet. On her computer it is a nice sky blue... and on mine it's a dark dark green.

The transparent color of the .pal file is $31 when opened up in Nesst, but it changes to $0B when the .pal file is running using Nintendulator. The rest of the colors have the same $ value according to both programs. So how can $0B in Nintendulator be changed to $31 in Nintendulator?

The short answer is to make every fourth byte in the palette file (the 16byte one) $0B. That will make it work for you.

The long answer is, even though each NES palette entry is four Colors, only the last three are actually used. The first color of every palette entry is actually a mirror of the transparent color. So if you write $31 as the first color of the last palette entry, that overwrites the transparent color for the whole system.

Some emulators and tools do not properly take this i to account. Nintendulator does.

This is actually not entirely true. In NES PPU there actually exists memory for palette locations $4, $8 and $C, however they're never used while rendering (they can only be accessed by turning rendering off and pointing PPU address to those locations). So only a palette entry written to $10 will overwrite the background color at $0. $14, $18 and $1C are mirrors of $4, $8 and $C respectively.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

qbradq: That didnt work for our game. The short answer didn't work because changing the forth (?:?) color to $0b would be something we weren't wanting. Thanks though.



ahhh yes, thank you, thefox, very much for this important info! At first your post didn't make any sense. But after spending some time thinking about it I opened the second pal file and the color $10 was $0B!! So changing that to $31 made the screen look more normal... must show her tomorrow! Good night thefox and qbradq.

Thanks for the clarification. I never was quite clear on all of that, I just never write anything to those palette slots.

Thank you all so much!
I now understand what happened. The transparent color of the sprite's .pal file was set to $0B because I thought, being transparent, it didn't matter what color it was. Now, I know it has to be the same color that I want the background color to be.