Level5 .xi file format

Discussion in '3DS - ROM Hacking, Translations and Utilities' started by onepiecefreak, Jan 22, 2017.

  1. onepiecefreak
    OP

    onepiecefreak The Special One

    Member
    388
    130
    Aug 12, 2015
    Germany
    Hey there,

    I need to find out how to properly "read" the .xi files from Level5 games.
    The xfsa-tool from @Nagato doesn't support it and there is nowhere another tool that can do anything with it.

    Information I could gather until now:
    • Header is IMGC (probably short for "Image compressed" or somethng like that?)
    • At 0x3c 4 bytes long it seems it is the size of the image data
    • At 0x48: Through other sources it should be a compressed table that shows how the picture is build in the end
    • Image data should consist of 8x8 tiles (at least this source tells it)
    • Image data begins at Total_File_Size - [0x3c] I think
    All these "facts" aren't confirmed but most likely true. I don't have any idea of the compression and also don't know if the 8x8 tiles of image data are compressed and/or which picture compression they use in the end (so RGB888 or RGBA8 or RGB565 and so on)

    This is the source I used to gather these information to work on:
    https://www.vg-resource.com/thread-28385.html

    Hopefully we can work on something to help.

    P.S: Enclosed you can find such a xi-file and most likely it's corresponding png (png was exported from Citra Graphic buffer)
     

    Attached Files:

  2. Nagato

    Nagato GBAtemp Advanced Fan

    Member
    533
    513
    Jul 15, 2011
    United States
    Quick look at the data with the raw image:
    0x10-0x14 is the width and height


    Not entirely sure, but I think
    0x1c - Data start offer?
    0x34 and/or 0x38 - Size of first table (some kind of compression table/dictionary of some sort?)
    0x3c - Size of compressed image data

    The value at 0x34 (or maybe 0x38) + the value at 0x1c should give you the start of the compressed image data.
    You can see how that's the case because adding the size of the table + the value at 0x1c should put you at the position where you can read exactly the number of compressed image bytes.

    My educated guess is maybe it's some kind of Huffman table? It's plausible because that was commonly used in the Level-5 games that I could figure out before.

    I'll test that theory out for you I guess, hold tight.
     
  3. onepiecefreak
    OP

    onepiecefreak The Special One

    Member
    388
    130
    Aug 12, 2015
    Germany
    That would be very nice.

    It's only in this file. I figured that out too. But in other xi files it isn't that exact. I would say it's coincidence. But I can't know that for sure.
    I also could figure out when you change 0x01 to 0x00 at position 0x128 in the attached xi file, the game will see the image data as uncompressed. So this 0x01 at 0x128 is some sort of compression flag.
    And it seems if you change it to another value above 0x01 it interpretes the image data as another compressed format again.
     
  4. Nagato

    Nagato GBAtemp Advanced Fan

    Member
    533
    513
    Jul 15, 2011
    United States
    No, I confirmed it with other images too. It's pretty consistent.

    At any rate, I'm fairly sure that it's Huffman compression and some LZSS scattered around.
    The compression stuff seems consistent with the code in my tool already.

    Unfortunately, there's some issue with decompression for whatever reason.
    I have other things to do so I can't dedicate too much time to this, but I added some lazy quick support for the format to xfsatool.
    Some real quick hacky code so it's not that great.
    If someone wants to play around with the code and maybe debug why it doesn't decompress everything, please feel free.

    http://www.mediafire.com/file/zoibzhqbqllaf4m/3ds-xfsatool-master.zip
     
  5. onepiecefreak
    OP

    onepiecefreak The Special One

    Member
    388
    130
    Aug 12, 2015
    Germany
    I will do my best. Thx for your base work.