Hello everyone, it's my first post here. I've been recently playing around with nds games extraction and more particularly Lego Battles, a game dear to me. So much good memories during my childhood!
Anyway, I've read documentation about basic extractions using tools like Tinke and CT2. So far so good, I successfully managed to extract many assets like ost, 3d models, sprites, palettes...
Out of curiosity, I've analyzed the raw data in NCGR and NCLR files of the game to compare theory to practice (theory being the documentation on romhacking net about nds formats) and something caught my attention. To explain myself, please refer to this picture first:
In the upper part of the picture, we can see I exported the sprite on a grid of 8px of space. The last line of the sprite being one single color (let's call it color1), we can easily found the corresponding bytes in the file (n.b.: in the picture I removed header and information from the file to keep only the DATA). Now in the lower part of the picture, we can observe one patter repeating itself 3 times on the file. The pattern is composed as follow: 1x color1, 6x color6 and 1x color1 (color6 being the black pixels). The file has a tile bit depth of 4 bits btw.
When comparing the pattern with the corresponding bytes (0x50555550), my only conclusion is that one byte contains color for 2 pixels in a row (which is normal bc the palette has 16 colors and 2 pixels can fit in 1 byte) but not in the correct order. e.g.: the two first pixels of the pattern (color1 and color6) are stored as 0x50 which, if we cut the byte by 2, is 5 and 0 in decimal. That's exactly the 1st and the 6th colors of the palette.
So first question: why are the bits not arranged in a logical order ? (why do we have to make an inversion ?)
My second point is basically of the same nature as my first observation. This time it concerns the palette (NCLR file). Again, a picture to support my explanation:
On the upper left, a representation of the full palette and the raw file on the right side. Same proceeding as previous point: find a frequently repeated pattern and its bytes. Here, we see that color are stored in 2 bytes. Let's take the very first pixel (the green one) that is present on many lines and its 8bit color code (#087030). Now let's take the value as encoded in the file (0xC119). If we invert the two bytes and group the bits 5 by 5 as illustrated, we can make a link with the 8bit color code. We can observe that the color depth of the palette is 5bit, which explains the division by 8 for the RGB value (proof: 2⁸ / 2⁵ = 2³ = 8).
My second question is the following: again, why do we make an inversion with the two bytes ?
All this reasoning may seem pointless but I prefer to explain myself clearly before asking questions. I'm really sorry if I didn't make myself clear enough or if my post is a bit too long, but again it's just because I'm curious on how things work. I attached the files for those who are interested.
TL;DR: given the color depth of the palette (5bit), is it normal that colors encoded in the NCLR file and pixel in the NCGR one are "reversed" ? If not, is that some liberty that the studio that developed the game could have taken ?
Anyway, I've read documentation about basic extractions using tools like Tinke and CT2. So far so good, I successfully managed to extract many assets like ost, 3d models, sprites, palettes...
Out of curiosity, I've analyzed the raw data in NCGR and NCLR files of the game to compare theory to practice (theory being the documentation on romhacking net about nds formats) and something caught my attention. To explain myself, please refer to this picture first:
In the upper part of the picture, we can see I exported the sprite on a grid of 8px of space. The last line of the sprite being one single color (let's call it color1), we can easily found the corresponding bytes in the file (n.b.: in the picture I removed header and information from the file to keep only the DATA). Now in the lower part of the picture, we can observe one patter repeating itself 3 times on the file. The pattern is composed as follow: 1x color1, 6x color6 and 1x color1 (color6 being the black pixels). The file has a tile bit depth of 4 bits btw.
When comparing the pattern with the corresponding bytes (0x50555550), my only conclusion is that one byte contains color for 2 pixels in a row (which is normal bc the palette has 16 colors and 2 pixels can fit in 1 byte) but not in the correct order. e.g.: the two first pixels of the pattern (color1 and color6) are stored as 0x50 which, if we cut the byte by 2, is 5 and 0 in decimal. That's exactly the 1st and the 6th colors of the palette.
So first question: why are the bits not arranged in a logical order ? (why do we have to make an inversion ?)
My second point is basically of the same nature as my first observation. This time it concerns the palette (NCLR file). Again, a picture to support my explanation:
On the upper left, a representation of the full palette and the raw file on the right side. Same proceeding as previous point: find a frequently repeated pattern and its bytes. Here, we see that color are stored in 2 bytes. Let's take the very first pixel (the green one) that is present on many lines and its 8bit color code (#087030). Now let's take the value as encoded in the file (0xC119). If we invert the two bytes and group the bits 5 by 5 as illustrated, we can make a link with the 8bit color code. We can observe that the color depth of the palette is 5bit, which explains the division by 8 for the RGB value (proof: 2⁸ / 2⁵ = 2³ = 8).
My second question is the following: again, why do we make an inversion with the two bytes ?
All this reasoning may seem pointless but I prefer to explain myself clearly before asking questions. I'm really sorry if I didn't make myself clear enough or if my post is a bit too long, but again it's just because I'm curious on how things work. I attached the files for those who are interested.
TL;DR: given the color depth of the palette (5bit), is it normal that colors encoded in the NCLR file and pixel in the NCGR one are "reversed" ? If not, is that some liberty that the studio that developed the game could have taken ?
