Alright, filling the screen with tiles from compressed data is working in my program.
Now I encounter the problem that I was able to circumvent in my previous game by simply hardcoding the upper static background graphics and by only using one and the same palette for the lower, dynamic part of the screen:
How do I set a palette attribute value if I know the x and y position of the corresponding tiles?
Let me elaborate:
I understand that each attribute value refers to a 16 x 16 pixels (2 x 2 tiles) area. Alright, fair enough.
But why did they also have to align each attribute byte in a square format?
Why couldn't one attributes byte, which contains the palette information for four 16 x 16 areas, simply refer to a 64 x 16 area? Why does it have to be a 32 x 32 area?
This makes connecting the PPU address offset of a certain tile with the PPU address offset of the corresponding attribute value a pain in the ass.
So, is there a good function that can change the attributes value according to an x and y position?
What I need is basically a function like this:
void ChangeAttributeBits(byte x, byte y, byte palette, ref byte[64] attributes);
x: Meta tile x position from 0 to 15. (Tile position would be x * 2 and pixel position would be x * 16.)
y: Same as x, only for y.
palette: Palette index value from 0 to 3.
attributes:
An array that is a copy of the 64 attribute bytes from a single name table from the PPU.
This value gets changed:
The palette index value is written to the correct two bits in this array. So, after writing the changed array back into the PPU to $23C0, $27C0, $2BC0 or $2FC0, the 2 * 2 tiles at location x * 16, y * 16 use this new palette value.
Now I encounter the problem that I was able to circumvent in my previous game by simply hardcoding the upper static background graphics and by only using one and the same palette for the lower, dynamic part of the screen:
How do I set a palette attribute value if I know the x and y position of the corresponding tiles?
Let me elaborate:
I understand that each attribute value refers to a 16 x 16 pixels (2 x 2 tiles) area. Alright, fair enough.
But why did they also have to align each attribute byte in a square format?
Why couldn't one attributes byte, which contains the palette information for four 16 x 16 areas, simply refer to a 64 x 16 area? Why does it have to be a 32 x 32 area?
This makes connecting the PPU address offset of a certain tile with the PPU address offset of the corresponding attribute value a pain in the ass.
So, is there a good function that can change the attributes value according to an x and y position?
What I need is basically a function like this:
void ChangeAttributeBits(byte x, byte y, byte palette, ref byte[64] attributes);
x: Meta tile x position from 0 to 15. (Tile position would be x * 2 and pixel position would be x * 16.)
y: Same as x, only for y.
palette: Palette index value from 0 to 3.
attributes:
An array that is a copy of the 64 attribute bytes from a single name table from the PPU.
This value gets changed:
The palette index value is written to the correct two bits in this array. So, after writing the changed array back into the PPU to $23C0, $27C0, $2BC0 or $2FC0, the 2 * 2 tiles at location x * 16, y * 16 use this new palette value.