search

ObsidianX / 3dstools

Tools for extracting and packing resources found in 3DS games
53 stars 16 forks source link

bffnt incorrectly decodes ETC1 image #17

Open rawlinson opened 6 years ago

rawlinson commented 6 years ago

I have a font file for which bffnt fails to produce valid pngs. The resulting images contain many 8x8 blocks as expected, but the colours are all incorrect. Incidentally, I have to force the version to be 4 in code to allow it parse successfully. The file is correctly decoded by BFFNTtoGTX.bms. Font file attached. turbo_messageFontOutline_50.zip

Tyulis commented 6 years ago

This is known... And we search how to fix (see #10). GTX can store ETC1 compressed data in the same format as BFLIM and BFFNT, so BFFNTtoGTX just converts headers, it's not really useful for me. Thanks for the file, concerned files to work on are always helpful.

Tyulis commented 6 years ago

I'll pull request for version issue

Tyulis commented 6 years ago

I tried to manually extract BFLIM sections of the file, and convert them with bflim.py, got the same result. 2 possibilities: there is a problem with the decompression algorithm (not probable, all ETC1 BFLIM files work fine), or it is not ETC1...

rawlinson commented 6 years ago

It turns out it is actually compressed as ATI1N/BC4U. So the pixel format specified in the TGLP header doesn't seem to be enough to identify the actual format used. Also, as I said, I had to force the version to 4 to use the correct headers despite the version being specified as 3.

Tyulis commented 6 years ago

I pull requested for the version issue, waiting for merge. The pixel format specified in TGLP works for any uncompressed font I tested, so ETC1 is probably replaced with another compression. I will try to work on the compressions you said. Thanks for help!

Tyulis commented 6 years ago

You're right, after searching in BFFNTtoGTX and on the web, I found that it's compressed in BC4.

rawlinson commented 6 years ago

Your fix for the version issue has already been merged and was used to open this file. It reports itself as version 3 but only works with the version 4 headers... and even then not perfectly, I had to modify the TGLP header struct to be "%s4sHxx4BI6HI", note the "Hxx" instead of "I".

It is a GameCube file so perhaps the formats aren't consistent between systems. If GameCube support is wanted then I think a system switch on the command line will be needed.

Tyulis commented 6 years ago

No, my previous version fix introduced some confusions between BCFNTv3 and BFFNTv3, I made another PR to split into BCFNT and BFFNT to avoid this, and I wait for merge. The problem has been found on some WiiU files, so i don't think this is specific on GameCube. I have to see if there are structure problems (as you said, v4 structures work, and appear to unpack coherent data), and for texture conversion. The TGLP header is correct, the "I" you replaced represents the whole TGLP section length, data included