Ikki Tousen: Shining Dragon

[mariokart64n]

The game uses a bunch of TM2's for its menu graphics, but for its character models, or level models aswell it uses an extension called *.mpt, which in turns seems to be another container to me. as it has 2 headers. and for this image format is uses the magic Lbin.

anyway, I've tried to just import this as raw, but I'm not having any luck I did how ever see something using raw import options of:
32x256 8channels 16bit with macbyte order, not interleaved. using photoshopcs2

the image in actuality must be 256x256, because when I combine the 8chanels of 32x256 in series, I get this 256x256. where you can see it has a face on the left and hair on the right.



i attached a few mpt's, if anyone wants to try and get this working

[Deniz Oezmen]

Well, this is kind of an odd format ... looks a bit like patch-work to me.
Anyway, I believe I have identified enough information to extract images. A rough format outline:

Code: Select all

char{4}      - MPT ID // (mpt 0)
byte {4}     - unknown
uint32 {4}   - number of names
byte {12}    - unknown

// for each name
  char {32}    - name

char {4}     - Lbin ID // (Lbin)
uint32 {4}   - number of blocks
uint32 {4}   - image descriptor offset (relative to Lbin ID)
uint32 {4}   - number of images

// for each block
  uint32 {4}   - block offset (relative to Lbin ID)

byte {x}     - padding up to image descriptors

// for each image
  uint32 {4}   - number of image data block
  uint32 {4}   - number of palette data block
  byte {4}     - unknown
  uint16 {2}   - image width
  uint16 {2}   - image height

// for each block
  byte {x}     - padding up to block offset
  uint32 {4}   - data offset (relative to block offset)
  uint32 {4}   - width for images, usually 16 for palettes
  uint32 {4}   - height for images, usually 16 for palettes
  uint32 {4}   - unknown, set for image blocks

  // if image block
    byte {x}     - image data, tiled into vertical stripes of 64 pixels (?) width

  // else if palette block
    // for each of the 256 (?) entries
      byte {4}     - colour data

However, a problem remains: I can't make anything out of the palette data. I does not (at least not trivially) contain RGB colour encodings, unless I'm too tired to see them. I've also tried a YCrCb conversion, but the results remain unsatisfactory.

Attached is an extracted example, with wrong colours obviously.

[mariokart64n]

oh cool, i guess it wasn't 256x256

also thats a very nicely detailed format outline, thats awesome

there were 2 other files, mpd, and smp, but I wouldn't imagine these are in any way connected as a palette.

anyway thanks for taking a look, I had thought it was compressed for a while

[Darkstar]

Have you tried all possible 15/16 bit pixel formats, both little-endian and big-endian? Especially if the game is a console game (or a console conversion) it might be a very "uncommon" format.

[Deniz Oezmen]

I'm quite certain that the image data itself is 8-bit indexed. As this obviously leaves room for up to 256 different colours and the (what I suspect to be) palette blocks are usually 1024 bytes in size, I tend to believe that each colour is somehow encoded into a 4-byte tuple. I have attached one such block in case you want to take a look at it.

(Ah, yes: The MPD and SMP files contain float values, so they're most probably models and/or animations.)

[mariokart64n]

I tired extracting the textures from PCSX2, with RipperDX, but I got scrambled data, its not even holding it differently in memory. only thing I can cetch are the TIMs, but if pcsx2 is showing the correct textures in the game, I don't get why its not converted properly in the d3d buffer...

maybe I should try a different emu's or plugins. having a reference texture will defiantly help

[mariokart64n]

ok, used a different d3d plugin for pcsx2, and forced d3d textures, I was able to rip some from the buffer, thx to ripperdx

Anyway interesting enough, all the flesh textures, are blue! i have no clue if this is fault of the emulator or what though its not really a step forward, till I can get a proper coloured/palletized img

[itg]

I not really strong in graphics format, but maybe there is some different color pallet like cmyk or...

[Darkfox]

Now I recall such blue skin problem in another game where the palette was read in reverse or something of that effect. I lost contact with Strobe who was going to fix it for that game. Not sure if that is the case here or not.

[mariokart64n]

aww, you are correct, instead of RGBA, it was BGRA.. well just for the pcsx2 rip. as for extracting from the raw file, i'm still completely in the dark

[Deniz Oezmen]

That rip was actually very helpful! (Never mind the RGB/BGR switch, I already suspected that.)

Contrary to my previous assumption, the palette is indeed pure RGB. But it is addressed in the weirdest way I have ever seen. Actually, it too is saved in some sort of tiled manner, each tile having a size of 8x2 in a 16x16 "palette image". Very odd stuff.

Anyway, try this converter. I'm not sure whether I'm handling the alpha channel correctly, but scaling it up by a factor of two seemed reasonable:

Code: Select all

MPT2TGA *.mpt

Please note that there is still some unknown stuff in the file, so the converter might fail in some cases.

[mariokart64n]

incredible!!

I was trying to compare between the 2, and really couldn't see much of a connect.

many, many thanks

[Deniz Oezmen]

You're welcome!