2

There is a gamecube videogame (called Winning Eleven) which i want to translate, but i had no success in extracting the textures out of the files which contain them.

I have tried several tools, one of them was a tool for a specific gamecube game (Mario Sunshine iirc), but it didnt work out, most likely because it uses a different, unique decompression method.

The files which contain the textures are .bin files, which i extracted from so called .txs files with the help of a zlib tool.

I would really appreciate it if someone, who is knowledgable in this matter, could take a look into this file.

Someone might recognize it or even knows already how to work this out.

I uploaded 4 of those bin files which ive extracted out of the txs file, and i also added a tool called AFS Explorer.

Download Link: http://s000.tinyupload.com/download.php?file_id=30125217858357016099&t=3012521785835701609927187

To extract the bin files i used the built-in Zlib Manager of the AFS Explorer.

How to open and explore txs files:

  1. Open the AFS Explorer
  2. Go to "View" on the top bar and choose "Zlib Manager"
  3. Choose "Load sections from file" and open the txs file.

Im just mentioning this for you to see how the bin files were extracted in first place, for a better understanding.

I would appreciate it a lot if you could help me to work this out.

Edit: Those are definitely no animations, just normal bitmaps with texts as content. I can even show you how they look like, these are from the PS2 Version of the same game, form the exact same file named "form.txs", the only difference obviously being that the PS2 Version uses a different compression method which was already discovered.

There are several tools which work with the PS2 files, but not a single of them with the NGC files, obviously because of the format differences.

Edit 2:

Ive uploaded a Texture Tool which works with the PS2 bin files, but obviously not with the GameCube ones. Despite searching intensively for it (also on old archived websites), i couldnt find the sourcecode of this texture tool. But i thought i still should upload it, it might help too. I hope tinyupload.com is ok for uploads.

Download Link: http://s000.tinyupload.com/index.php?file_id=92363414871112387548

6

This looks .. interesting.

When i open the first and second of your files in a hex editor, one has 20240 bytes, the other has 10240 bytes (all numbers in hex). So, 2^16+220 in one case, 2^17+220 in the other case.

Both files have data that "looks a certain way" in their first 240 bytes, then the data starts looking differently. Example:

enter image description here

To me, this smells like:

0000-003F metadata, whatever 0040-0240 palette; probably 256d entries of 2 bytes, 565 encoding? rest image data

Notice how regular the pattern looks when you set the width of the hex display. This seems to be a 20x20 (32x32 decimal) pixel bitmap. However, looking further down in the file, there seem to be other widths as well.

So no, this is not a recognizable (by me) format, but it shouldn't be too hard to decode it.

The other 2 files seem to have a different format, they're only 30 bytes larger than a power of 2, and there's not a distinct pattern change 30 bytes into the file. Not sure what to make of that, yet.

Edit:

Interpreting the image data of the AFS73DB.tmp_0.bin file as 32x128 tiles and placing them next to each other yields (some parts omitted):

enter image description here

This looks to me like an animation, maybe of an explosion or something similar. The colors are probably way off, though. Does this ring any bells? Do you have a screenshot or two how this should look on the Gamecube?

Also, it seems that the lower part of the texture isn't used and thus filled with random bytes.

If you want to check out my attempt at a decoder, check https://github.com/gbl/GamecubeTextureDisplay.

Edit2:

Having an example what the output should look like helped, a lot, and i was able to update my decoder.

Each block of 32 input bytes is stored as an 8x4 pixel block in the output, with the next block to the right of it, until the whole line length is reached, like this:

00 01 02 03 04 05 06 07     20 21 22 23 24 25 26 27   ....
08 09 0a 0b 0c 0d 0e 0f     28 29 2a 2b 2c 2d 2e 2f 
10 11 12 13 14 15 16 17     .....
18 19 1a 1b 1c 1d 1e 1f

Each palette entry seems to be a big endian 2-byte word, with the msb unknown (alpha value?), followed by 5 bits for red, green, blue. So for example a palette entry 8CE2 translates to 1000 1100 1110 0010, split to 1|00011|00111|00010|, resulting (when the individual colors are filled to 8 bit) in r=00011000=24, g=00111000=56, b=00010000=16.

Using this, your files result in

enter image description here enter image description here

which looks quite good. However, there are some red pixels in the first image that shouldn't be there, and the letters in the second one almost look like 3D letters with their shifted green/red pixels. Could this have to do with an alpha value?

Still not sure what to make of the b/w pictures.

(to be continued)

  • Just edit the question if you have more information to share. The image files are interesting: the color files have 1 byte/pixel + 512 bytes (palette?) + 64 bytes header. The b&w files have 1 nibble/pixel + 32 bytes (greyscale palette??) + 64 bytes header. So they definitely aren't compressed. Information like this helps tremendously, even though i can't make sense of the format, yet. – Guntram Blohm May 14 '16 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.