It is currently Fri Dec 15, 2017 11:08 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Tue Feb 22, 2011 12:43 pm 
Offline

Joined: Tue Feb 08, 2011 6:14 pm
Posts: 5
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 22, 2011 3:40 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 22, 2011 3:58 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3487
Location: Indianapolis
'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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 22, 2011 5:35 pm 
Offline

Joined: Tue Feb 08, 2011 6:14 pm
Posts: 5
Thanks a bunch Memblers :D That helps out a lot! I understand now.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 08, 2011 5:41 am 
Offline
Formerly WhatULive4
User avatar

Joined: Fri Oct 30, 2009 4:43 am
Posts: 339
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).


Top
 Profile  
 
 Post subject: Another color problem
PostPosted: Mon Apr 25, 2011 7:10 pm 
Offline

Joined: Tue Feb 08, 2011 6:14 pm
Posts: 5
: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?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 25, 2011 7:42 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19347
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 25, 2011 9:35 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 806
Location: cypress, texas
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. :?


Top
 Profile  
 
PostPosted: Fri Apr 29, 2011 9:08 pm 
Offline

Joined: Tue Feb 08, 2011 6:14 pm
Posts: 5
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 30, 2011 9:15 am 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 939
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 30, 2011 1:20 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
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.

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 30, 2011 11:04 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 806
Location: cypress, texas
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. :)


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 01, 2011 2:51 pm 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 939
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 02, 2011 7:38 pm 
Offline

Joined: Tue Feb 08, 2011 6:14 pm
Posts: 5
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group