nesdev.com
http://forums.nesdev.com/

YYCHR NESST color problem
http://forums.nesdev.com/viewtopic.php?f=21&t=7504
Page 1 of 1

Author:  ocicat [ Tue Feb 22, 2011 12:43 pm ]
Post subject:  YYCHR NESST color problem

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.

Author:  3gengames [ Tue Feb 22, 2011 3:40 pm ]
Post subject: 

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.

Author:  Memblers [ Tue Feb 22, 2011 3:58 pm ]
Post subject: 

'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.

Author:  ocicat [ Tue Feb 22, 2011 5:35 pm ]
Post subject: 

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

Author:  NESHomebrew [ Tue Mar 08, 2011 5:41 am ]
Post subject: 

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).

Author:  ocicat [ Mon Apr 25, 2011 7:10 pm ]
Post subject:  Another color problem

:D
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?

Author:  tepples [ Mon Apr 25, 2011 7:42 pm ]
Post subject: 

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.

Author:  unregistered [ Mon Apr 25, 2011 9:35 pm ]
Post subject: 

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. :?

Author:  ocicat [ Fri Apr 29, 2011 9:08 pm ]
Post subject:  Nintendular color problem

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?

Author:  qbradq [ Sat Apr 30, 2011 9:15 am ]
Post subject: 

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.

Author:  thefox [ Sat Apr 30, 2011 1:20 pm ]
Post subject: 

qbradq wrote:
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

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.

Author:  unregistered [ Sat Apr 30, 2011 11:04 pm ]
Post subject: 

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. :)

thefox wrote:
qbradq wrote:
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


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.


ahhh yes, thank you, thefox, very much for this important info! :D 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. :)

Author:  qbradq [ Sun May 01, 2011 2:51 pm ]
Post subject: 

thefox wrote:
qbradq wrote:
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

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.


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

Author:  ocicat [ Mon May 02, 2011 7:38 pm ]
Post subject: 

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.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/