09-08-2014, 09:06 PM
OK, looks like the "4bpp linear" that the document was talking about is different than how this is supposed to be done. After comparing expected results with what I was getting, and looking at the instructional bytes themselves and their bits, I figured that it truly is linear. That is, each half byte has all 4 bits for a pixel, and they're just read in order. No bitplanes, which is way simpler and quicker. "Reverse order" probably means reading the 4-bit chunks from right to left, which also explains Ailos's comment "the bottom 8x8 is 4bpp linear reverse order only thing that changes is that the columns of 2x8 pixels switch places". I sort of did it from right to left intuitively anyway though.
After some more testing, I also realised that both the palette and the instructions are in little-endian; I had been reading the former in that manner already, but I thought the latter was in big-endian.
Anyway, now that I'm managing to extract them properly, how should the program go about doing this? Do you want it to extract all the 16x16 tiles, or only the unique ones (i.e. skip duplicates)? And should it extract them all as separate 16x16 images, or as one big image?
After some more testing, I also realised that both the palette and the instructions are in little-endian; I had been reading the former in that manner already, but I thought the latter was in big-endian.
Anyway, now that I'm managing to extract them properly, how should the program go about doing this? Do you want it to extract all the 16x16 tiles, or only the unique ones (i.e. skip duplicates)? And should it extract them all as separate 16x16 images, or as one big image?