Confused about the palette

[comegordas]

hi everybody! i'm having some troubles whit the palette.

i'm already able to fetch all the color bits, even the attribute table's ones. by assembling all the 4 bits i get an index to access the palette. first of all, i have a question about this diagram wich is in the wiki:

Code: Select all

43210
|||||
|||++- Pixel value from tile data
|++--- Palette number from attribute table or OAM
+----- Background/Sprite select

what about bit #4? i think that stands for the background/sprite palette selection, but don't know where does it comes from.

...and then i have another doubt about all of this.
there's (virtually speaking) two palettes: the game's palette (Hue/Satturation/Value-based) and the palette i have coded on my emu (RGB-based). the game loads its own palette into VRAM, based on Hue/Saturation/Value values. do i have to transform those values into RGB values in order to be able to show colors on the screen? as i understood that's the way it should work. i've read severall articles from the wiki, the NESTECH doc and Qee's doc and couldn't find another way to combine all these things.

BTW, while trying to understand how the attribute table works, i made a table that shows what byte of the attribute table uses each one of the 960 tiles of the screen. maybe someone would like to download it from Megaupload or see it in Pastebin...

[tokumaru]

what about bit #4? i think that stands for the background/sprite palette selection, but don't know from where does it comes from.

If you are rendering background tiles, that bit is 0, if you are rendering sprites, it's 1. The background will never use the sprite palette and vice-versa.

...and then i have another doubt about all of this.
there's (virtually speaking) two palettes: the game's palette (Hue/Satturation/Value-based) and the palette i have coded on my emu (RGB-based). the game loads its own palette into VRAM, based on Hue/Saturation/Value values. do i have to transform those values into RGB values in order to be able to show colors on the screen?

Of course you have to convert the NES color values into something that makes sense to the computer your emulator is running on. You can use a look-up table for that (use the NES colors as indices to retrieve RGB values). When making this table you should take into account the color emphasis bits, which can give 8 distinct configurations to the whole palette, so the table would have 64 * 8 = 512 entries.

[Dwedit]

BTW, pastebin is a much better place to put text files than megaupload.

[comegordas]

first of all thanks for your (fast!!!) replies

Tokumaru:
so i shouldn't care about that. just manually select one or another palette according to what i'm rendering at the time. is it correct?

about the emphasis, now it makes to me those bits the 3 upper bits from PPU $2001. i've found this from Qeed's doc:

Code: Select all

static const float ntsc_emphasis_factor[7][3]
{
   {1.00, 0.80, 0.81},
   {0.78, 0.94, 0.66},
   {0.79, 0.77, 0.63},
   {0.82, 0.83, 1.12},
   {0.81, 0.71, 0.87},
   {0.68, 0.79, 0.79},
   {0.70, 0.70, 0.70}
};

so the trick is:
* pick up the Hue/Saturation/Value value from the actual VRAM's palette using the color bits/index taken from tile data and attribute table
* fetch the upper 3 bits from PPU $2001
* fetch the corrisponding entry of that array above using that 3 bits
* multiply the this last value fetched by each one of the 3 values of the array's entry
* ...finally i'll have 3 values: one for red, another for green and another for blue (in that order). is it correct?

Disch:
thanks! didin't know about that site! anyway, i tried it and font that the page uses and the small size of the view window makes the doc unreadable. maybe someone that knows about this things would make to place it a better site? (or the wiki XD)

EDIT: added to Pastebin -> http://pastebin.com/raw.php?i=gPeHaT0i

[doppelganger]

hi everybody! i'm having some troubles whit the palette.

i'm already able to fetch all the color bits, even the attribute table's ones. by assembling all the 4 bits i get an index to access the palette. first of all, i have a question about this diagram wich is in the wiki:

Code: Select all

43210
|||||
|||++- Pixel value from tile data
|++--- Palette number from attribute table or OAM
+----- Background/Sprite select

what about bit #4? i think that stands for the background/sprite palette selection, but don't know where does it comes from.

I believe that diagram is supposed to show you another way of looking at the palette memory at $3F00-$3F1F. See, the bits 4-0 form the low byte of the palette address, and %xxx00 is always interpreted as the background color 0 or transparency. The background tiles are always rendered with %0xxxx entries, and the sprites with %1xxxx entries. Bit 4 doesn't really come into play for the programmer except when referencing the palette by VRAM address.

I hope this doesn't lead to any more confusion.

[comegordas]

nope, no more confusion. thnx doppelganger

[Dwedit]

Your diagram about the attribute tables is incorrect. No bytes from the attribute tables are unused, and it does not wrap early to add 16 instead of 32.
Four unused bits from the bottom eight bytes will assign colors to the out-of-bounds area at the bottom, but no whole bytes go unused.

Also, some games set a negative scroll which displays some of the attribute table as tiles. Slalom, Super Mario 3, Teenage Mutant Ninja Turtles, etc. Most old TVs will cut it off, but you can see it in emulators, so if you're wondering why there are garbage tiles at the very top of the screen in TMNT, that's why. So the "unused" bits from the attribute tables will color the attribute tables if they are displayed for some reason.

[tokumaru]

so the trick is:
* pick up the Hue/Saturation/Value value from the actual VRAM's palette using the color bits/index taken from tile data and attribute table
* fetch the upper 3 bits from PPU $2001
* fetch the corrisponding entry of that array above using that 3 bits
* multiply the this last value fetched by each one of the 3 values of the array's entry
* ...finally i'll have 3 values: one for red, another for green and another for blue (in that order). is it correct?

No, I don't think so. That array you posted appears to be how much R, G and B must be modified, after you have already converted from the NES format to RGB.

See, you have to build a table with 64 entries, with the RGB values for all the colors the NES has. There are no official values here, each emulator uses what the author thinks is correct based on their own experience, so you can just copy the RGB values from an emulator you like or create your own.

OK, so this is the unaltered palette, when all emphasis bits are 0. What I suggested was that you pre-calculate all the possible modifications, so you'd effectively have a set of 8 palettes of 64 colors each. You'd use the values you just posted to compute the 7 variations of the basic palette.

Then, when rendering, you'd use 9 bits (3 from the color emphasis and 6 from the color index) to index the final RGB color from your look-up table.

[comegordas]

from Qeed's doc:

It has 4 extra bytes that isn't used for anything, since there
are 960 tiles and one byte corresponds to 4x4 (32*32 pixels) tiles,
(960/(4*4) = 60 bytes), shows that the the last 4 bytes are indeed not
used

...and that's writen in almost every doc that talks about the ATs. didn't know that the four last bytes were actually used.
so the thing is that those bytes are used, but no in its whole 8-bits, just a part. is that right? reminds the times when i was at college studying memory's fragmentation XD

also, i couldn't understand this:

and it does not wrap early to add 16 instead of 32

by seeing the diagram on the wiki, looks like the bottommost line of my table should be like this, so the 8 last bytes of the AT are fragmented at its half. got it right now?

[doppelganger]

Yes. That's right.