Email or username:

Password:

Forgot your password?
Top-level
Foone🏳️‍⚧️

the datafile has 1938 matches for "CFLAGS 64", so... does this game have 1938 separate textures? maybe!

25 comments
Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

fun fact: just about every other game and file format in the world solves this complex problem by JUST PUTTING A FUCKING HEADER IN THE FILE WHAT ARE YOU DOING

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

what do you think this is, classic macos with resource forks?

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

1984 called they want their filesystem design back, Pipeworks!

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

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?

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

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

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

my favorite part is that nintendo literally calls this RGBA when it's not in RGBA order.
It's in ARGB order. Or, you know, ARARARARA... order.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

re-parsed.
Yeah it turns out my code worked perfectly on the first try!
I just, wasn't, uh... running it.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

well I'm not sure what that is but it didn't parse properly

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

OH GOD THEY CHANGED THE BLOCK SIZE FOR GREYSCALE IMAGES
they're 8x4, not 4x4

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

NINTENDO IS JAPANESE FOR "I HATE THE VERY IDEA FOR MAKING ANY FUCKING SENSE"

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

it's only slightly better when properly parsed, to be honest

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

oh wow. I parsed IA8 correctly on the first try!

(it is, of course, in AI byte-order)

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

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.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

so for each subblock, there's 64 bits.
The first half is two 16-bit values, c0 and c1. Their numeric value is important, as they're compared, and mean different things which one is bigger.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

so the two numbers are compared, and either way, c0 and c1 are RGB 5:6:5 colors.
Then, depending on which is bigger, c2 and c3 get calculated.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

if c0 is bigger than c1, then:
c2 is set to 2/3rds of c0 + 1/3rd of c1
and
c3 is set to 1/3rd of c0 and 2/3rds of c1.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

but if c1 is bigger than c0, then:
c2 is set to 1/2 c0 and 1/2 c1, and c3 is set to transparent black.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

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.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

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.
Then it's a simple 4-bit paletted image, like we're running a CGA 3D Renderer over here.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

ugh it turns out it's hard to decode 0-width fonts, thanks to divisions.

Foone🏳️‍⚧️ replied to Foone🏳️‍⚧️

I'm now mass-converting all the textures.
I don't think this one is working right. Just a guess.

Go Up