TvC FPK tool

I've written an FPK packer for Tatsunoko vs Capcom. It will scan a folder recursively and compress the files into a fpk.

The fpk files generated by the packer can be unpacked with unFPK, but I haven't been able to test by replacing files on the ISO. The files are generally larger by around 1k or 2k than the original fpk files.

The entire file format is accounted for except for the first 4 bytes, which changes from file to file. I think it's a checksum, but I haven't yet been able to figure out how it's computed.

Hopefully TvC will accept FPKs with the first 4 bytes set to zero.

You can download the tool (and VS2005 source code) here.

CODETo create an FPK:

fpktool -p

To unpack an FPK:

fpktool -u

Would anyone like to help with testing?

 

@ganons:

FPK is more or less an archive file, used to store related sets of data.

The TvC FPKs seem to store data related to the characters, as they are stored in folders such as "fpk/ryu" and "fpk/sak". When unpacked, you get a bunch of folders and files, with various extensions like *.MOT, *.BRRES, *.SEQ. I suppose in TvC these files are used for the character models, as some of them likely contain textures.

I'm not too well versed with GC/Wii/Ninty file formats as I'm new to the scene (just bought my Wii a month ago). I was just bored at work/home and wanted to get back into programming-for-fun.

@WiiShizzza:

Yeah, it is a bit slow. The compression algorithm currently does a brute-force search for matching sequences, so there's still room for improvement. However if TvC actually does require the checksum and refuses to load the fpk, speed will be the last of our problems

 

I was thinking about how to reverse those formats when it occurred to me that we have the code for reading the formats. It's a long shot, but shouldn't the game contain the code for reading those files?

The main.dol of TvC contains the folder names for the ssds, fpks and other resources.

If they are aligned sequentially and of the same size, then I would assume that some code references them via an index, and a pointer to the first item. If the binary contains a "%s.fpk" string, some code pointing to that would likely call a sprintf routine of some sort to build the path prior to loading it. Of course I have no idea as of yet how memory is loaded into the wii and how it is referenced in code.

If two games both use a certain file format, the dols might contain the same code, making identifying the code a matter of diff-comparing the two dols. Anyway, all this is just to help make identifying which portion of the code to disassemble much easier.

I was also thinking that maybe the dolphin emulator could be modified to break when it tries to "load" a certain file in the ISO, or access a certain part of memory. I know Dolphin has a debug mode, but it doesn't seem to have the ability to trigger a break on memory access, nor can I actively scan memory for some strings.

If anyone can point me to good information about dols, how they are loaded, disassemblers and PPC assembly, it would help a lot.

I've done some NES and SNES assembly in the past. I tried to convert Willow to a SRAM- instead of password-based save for the NES, and for SNES I started a ROM translation project for Akazukin Cha Cha RPG, adding roman font and variable font width routines.

 

I don't know if I did this correctly, but I replaced ryu's 0000.fpk file with a recompiled one using WiiScrubber's replace function.

Unfortunately, TvC now freezes whenever I select Ryu. So it's either my compression is wrong in some places, or the checksum thing...

Things to try with a clean ISO:

1. Extract a file and replace without changes, to show that replacing works without issues.
2. Extract a file, modify the "checksum" bytes, replace, to confirm that TvC actually does something with those bytes.

I doesn't make sense to put a checksum in there though, the game usually expects all the data to be good. I mean, it won't throw a checksum error because there would be no way to recover from it anyway.

Oh well, back to the drawing board...