okay having written an extractor for that format, I move onto the next format: GX_TF_RGBA8.
Hey, that seems simple! 8 bits per channel, RBGA, 32bit per pixel. Easy, right?
Top-level
okay having written an extractor for that format, I move onto the next format: GX_TF_RGBA8. 21 comments
my favorite part is that nintendo literally calls this RGBA when it's not in RGBA order. re-parsed. OH GOD THEY CHANGED THE BLOCK SIZE FOR GREYSCALE IMAGES NINTENDO IS JAPANESE FOR "I HATE THE VERY IDEA FOR MAKING ANY FUCKING SENSE" oh wow. I parsed IA8 correctly on the first try! (it is, of course, in AI byte-order) the final format I need to implement is GX_TF_CMPR, which is a variant of DXT1 texture compression, in 8x8 blocks. JUST KIDDING! it's implemented as four 4x4 sub-blocks. so for each subblock, there's 64 bits. so the two numbers are compared, and either way, c0 and c1 are RGB 5:6:5 colors. if c0 is bigger than c1, then: but if c1 is bigger than c0, then: so now you have 4 colors, c0 through c3. The final 32 bits of the subblock is an index into this palette, with two bits per pixel. so yeah. dxt1 works by having you define two colors, they get an extra bit of metadata by making the order of the colors important, then generate 2 more colors based on those colors + metadata. ugh it turns out it's hard to decode 0-width fonts, thanks to divisions. I'm now mass-converting all the textures. |
OH GOD NOPE.
So, it's encoded as 4x4 pixel chunks, right? But it's planar... interleaved planar.
So a 4x4 RGB8 chunk looks like this:
ARARARAR ARARARAR
ARARARAR ARARARAR
GBGBGBGB GBGBGBGB
GBGBGBGB GBGBGBGB