My question now becomes how to decode which is which with code when i read the data into the program, there are way too many possibilities to try and code for each one of them. Surely there is a logic he be found here givin that each "color" has its own unique traits it gives the resulting hex values.
I'm not entirely sure I understand this question.
Once you have a 4-color image, the game will assign a palette to that image, which will tell you what colors to use for each pixel value. If you take a look at the PPU viewer in FCEUX, you'll see that it has 8 palettes at the bottom.
On the NES... "pixel 0" is always transparent, and pixels 1-3 get mapped to the desired palette entry. But for an editor, you can usually ignore the transparent thing and assign a 4th color for "pixel 0"... unless you want to draw multiple tiles on top of each other.
Where the palette is in the ROM is dependent on the game. I'm sure there are docs available on this site which go over changing palettes in NES games.
how to decipher which colored block is where based off of the hex values I find stored in the hex at any time when i read it into my program, any help on this? Any code in any language would be nice and very helpful here.
?? Are you asking for a code example of how to decode NES graphics?
Here's some pseudo-code:
// 'output' is a 2D array to hold generated image.
// output[y][x] represents 1 pixel in the image, and can have a value between 0-3
for( int y = 0; y < 8; ++y )
{
byte lo = ROM[ offset + y ]; // low bitplane byte for this row
byte hi = ROM[ offset + y + 8 ]; // high bitplane byte for this row
// left-most pixel is in bit 7 of the lo/hi bytes. So we need to extract that bit
//
// ((hi >> 6) & 2) <- this moves bit 7 to bit position 1: H....... becomes ......H.
// then masks out the interesting 'X' bit
//
// ((lo >> 7) & 1) <- this moves bit 7 to bit position 0: L....... becomes .......L
//
// |'ing them together combines them: ......H. | .......L becomes ......HL which is our desired pixel
output[y][0] = ((hi >> 6) & 2) | ((lo >> 7) & 1);
output[y][1] = ((hi >> 5) & 2) | ((lo >> 6) & 1); // <- same but with bit 6
output[y][2] = ((hi >> 4) & 2) | ((lo >> 5) & 1); // <- bit 5
output[y][3] = ((hi >> 3) & 2) | ((lo >> 4) & 1); // <- bit 4
output[y][4] = ((hi >> 2) & 2) | ((lo >> 3) & 1); // <- bit 3
output[y][5] = ((hi >> 1) & 2) | ((lo >> 2) & 1); // <- bit 2
output[y][6] = ( hi & 2) | ((lo >> 1) & 1); // <- bit 1
output[y][7] = ((hi << 1) & 2) | ( lo & 1); // <- bit 0
}
When the two planes are combined on a single plane the 0s and 1 will be opposite for the lower and higher planes
Not necessarily. The low plane and high plane can be completely different.
The part I dont get is where 2 and 3 come from, im guessing these are the other two colors of the four?
Yes, there are 4 pixel values: 0, 1, 2, and 3
If the coresponding bit in the low plane is set, you add 1 to the pixel value
If the coresponding bit in the high plane is set, you add 2 to the pixel value
pixel 0 = bit is clear in both planes
pixel 1 = bit is set in low plane, but not in high plane
pixel 2 = bit is set in high plane, but not in low plane
pixel 3 = bit is set in both planes
Topic: Nes sprite editing with only hex editor (Read 12088 times)