RAI PAY ATTENTION TO THIS TOPIC, YU Sprites Options

[Dr Strum]

So, essentially the file structure (sans whatever is embedded in the eboots themselves) for Kitten and XYZ are as follows:
Green = converted to useable format.
Yellow = Uhhh... Sort of...

Kitten PSP

• data01.afs
  • Memory Card Image (Plain)
  • Memory Card Image (Maria)
  • Memory Card Image (Mellia)
  • Memory Card Image (Yggdra)
  • PT* series file(s)
  • PT* series file(s)
  • Unknown! Animations? Effects? Actually I think it may just be filenames/descriptions of other media.
• POWDATA.SFS - PT* series file(s) + script = battle information
• sound_bgm.afs - ADX files
• sound_se.afs - ACX files (ADX collections)
• sound_voice.afs - It's a bunch of ATRAC3+ files. Semi readable, I suppose... But not really.

Hexyz Force

• BGMDATA.afs - ADX files
• BGMDATA22k.afs = ADX files
• data0.afs - a mishmash of files, some ADXs have been converted to waves, but a lot are clearly compressed and thus currently beyond my abilities.

Yggdra Union PSP

• bgmData.afs - ATRAC3+ files. As far as I can probably get.
• data0.afs - Bunch of shit. I discovered a lot of ACX files, see below for the issue.
• voiceDataEng.afs - ADX files. See below
• voiceDataJpn.afs - ADX files. See below

Issue with ACX/ADX files: my ADX file decoder (that I did not write) seems to be extracting shitty sounding wav files. I'm not sure if this is the fault of the decoder or if the ADX files actually sounded shitty from the start (haven't played the game in a long time) but I'm looking into it. Hopefully I'll figure it out soon, then we'll have a million billion YU voices to sort out.

For file conversion (source code):
AFS
PTBD
ACX (will convert embedded ADX files)


Update: I broke out the YUPSP ISO today and took a look. Realized some lovely surprises. I may have to dig out the RiviPSP ISO to check on that, now, too.

[Dr Strum]

Progress was been being made.

Kitten:
-1967 sound effects converted to wav, in need of identification
-135 BGM tracks converted to wav, in need of identification

XYZ:
-54 BGM tracks (x2) converted to wav, in need of identification
-165 voice clips (all from battle, I believe) converted to wav, in need of identification (I'll soon have more, as I've identified another file format housing voice clips)

YUPSP:
-1868 battle voice clips (and maybe SFX) converted to wav, in need of identification
-419 English and 418 Japanese cutscene voice clips converted to wav, in need of identification

Of course, these will only be identified if people actually want them ordered/on the site/whatever, but if you want to take on the identification of something, let me know and I'll provide the archive.

[Raijinili]

I don't even remember what PTX is.

[Dr Strum]

Image Data. They can be stand alone images, but more commonly they're housed in PTG files (I don't know exactly what the point of these are, but they always hold 2 PTX files and have to be arranged in a special way), and PTA files (animation files), which tend to ignore the standard rules of PTX data and even the headers contained in the PTX files and make decoding a pain.
The file format can be found in YUPSP, Kitten PSP and Hexyz Force.

[Raijinili]

I should graduate first.

[Dr Strum]

Pssh fuck that. Graduation is for newbs.

[Dr Strum]

So, I have two mysteries regarding the PTG files before I have them totally figured out.
1) The PTG files for Hexyz for some reason have a lot of their block data multiplied by 0x40... Or maybe the Yggdra ones have them divided by 0x40 and one is easier for calculation than the other? Don't know. I have a simple code work around, but it's still a curiosity.
2) For some reason all the colours are outputting properly but the skin. The skin is transparent in most image viewers, and absolute gibberish colours in some others.

Otherwise I could move on to other, for the most part easier file formats.

Also, I figured out why PTG files consist of two PTX files: it's an offshoot of the LIM file format. Having two embedded files allows for saving on space (as, if you remember, the LIM files, while conserving a lot due to their not including alpha pixels wasted a lot to remain block-aligned).

[Dr Strum]

RAI, WE HAVE BEEN FANTASTIC IDIOTS
The files are compressed simply and with ZLIB. Some may be encrypted, as I haven't tried all of them, but I think they're just compressed, and they can be easily decompressed using the library. For example, I just used the Python ZLIB library in my DAR unarchiver for Gungnir. An extra two lines of code and each file extracted is also decompressed.

[Raijinili]

k

Kitten too?

[Dr Strum]

Yeah.

[Raijinili]

dang. well, get on that and share me.

[Dr Strum]

Get on what? I already unzipped everything in GG, and I could easily unzip Kitten/XYZ/YUPSP stuff, I'm pretty sure, I'm just obsessed with hacking GG right now. It's almost entirely TPL files, even the sprite data, it seems. But some of the files are arranged differently, and I'm not exactly finding a header-based explanation, so I may just have to use exceptions as they come up which will suck.
There are also .bin files that go with some of the files, and I think they describe animation or something to that effect, as they appear with a lot sprites and other things that would probably be animated. I have little idea of how the files work right now, though.

[Raijinili]

Give me a specific task and talk to me about transferring the stuff over.

[Dr Strum]

Let me take care of the TPL files and then I'll figure out where we stand on all the files and delegate thusly.
SPEAKING OF THAT
Sting is taking liberties again. In case I didn't tell you, Rai, the TPL file format is actually a fairly common texture format, especially for GC games. But Sting made some changes for their own purposes. Now they're making more. The sprites for the game, as well as a lot of the faces, have a form of construction data added towards the end, and I still can't really find any indicator of its existence (as they treat it like another image in the TPL file header), except for the lack of either palette or width/height. There may be one thing, but I'm still investigating. <3

[Dr Strum]

ALRIGHT I HAVE FIGURED IT OUT
I FIGURED OUT THE SPRITE TPL FILES IN GUNGNIR MORE OR LESS
In each TPL file there will be a special image which is not an image at all, but is actually the instructions on how to assemble the randomly assorted image data that the previous image contains. This is how it works. For this example I'm using wine.tpl, which produces three sprites of a wine glass. The assembly data is as follows:

CODE

08 00 00 00 03 00 00 00 20 00 00 00 F4 4F 01 02
2C 00 00 00 F0 1F 01 02 38 00 00 00 EB DF 00 01
00 00 00 00 06 20 00 04 06 00 06 20 01 00 0C 00
09 20 00 04 15 00 07 14 00 00 1C 00 10 18 65 00

Looks like a bunch of crap.
First we have a header of sorts:

CODE

Int:         Header Length
Int:         Images

Followed by that is Images * 8 bytes of data.

CODE

Int:         Offset (relative to header) of image construction code
Byte:        Dunno. Usually a negative value.
Short:       Dunno. Usually a negative value.
Byte:        Construction Commands

The construction commands are actually fairly simple. The offset mentioned above will point to Construction Commands * 6 bytes of data to read in.

CODE

Byte:        Horizontal Shift
Byte:        Vertical Shift (>>1)
Short:       Data start
Byte:        Data to read in
Byte:        Dunno. Usually 0x20

So yah. Let's parse wine.tpl based on this info:

CODE

Header Length: 0x8
Image Count: 0x3


I1 Offset: 0x20
I1 ?1: 0xF4
I1 ?2: 0x14F
I1 Commands: 0x2

I2 Offset: 0x2C
I2 ?1: 0xF0
I2 ?2: 0x11F
I2 Commands: 0x2

I3 Offset: 0x38
I3 ?1: 0xEB
I3 ?2: 0xDF
I3 Commands: 0x1


I1 Commands:
        I1C1 Horizontal Shift: 0x0
        I1C1 Vertical Shift: 0x0
        I1C1 Data Start: 0x0
        I1C1 Run length: 0x6
        I1C1 ???: 0x20
        I1C2 Horizontal Shift: 0x0
        I1C2 Vertical Shift: 0x4 (=0x8)
        I1C2 Data Start: 0x6
        I1C2 Run length: 0x6
        I1C2 ???: 0x20
        
I2 Commands:
        I1C1 Horizontal Shift: 0x1
        I1C1 Vertical Shift: 0x0
        I1C1 Data Start: 0xC
        I1C1 Run length: 0x9
        I1C1 ???: 0x20
        I1C2 Horizontal Shift: 0x0
        I1C2 Vertical Shift: 0x4 (=0x8)
        I1C2 Data Start: 0x15
        I1C2 Run length: 0x7
        I1C2 ???: 0x14  
        
I3 Command:
        I1C1 Horizontal Shift: 0x0
        I1C1 Vertical Shift: 0x0
        I1C1 Data Start: 0x1C
        I1C1 Run length: 0x10
        I1C1 ???: 0x18
    
Junk(?): 0x65, 0x00

When dumped as a straight image (scaled to 1000%), we get:

If you try assembling it per the information above, you'll end up with three wine bottle sprites, one standing vertically, one at about a thirty degree angle, and one lying horizontally.

Hopefully a little more exploration will reveal what the unknown fields do, but I have a feeling at least two of them are pointless counters. But first, time to try to generate an algorithm for this shiznass.