Strike Witches: Silver Wing/Notes

From Data Crystal
< Strike Witches: Silver Wing
Revision as of 20:28, 18 March 2024 by Anonmoosekaab (talk | contribs) (Fix for quickbms reinsert2 bloating archives. Testing on if this fixes freezing from reinsert2 TBD)
Jump to navigation Jump to search

File Formats

GGXArchive Packed Files

Most of the game's files appear to be archives created with "GGXArchiver v1.00". These can contain various types of files, including but not limited to models, textures and text. Some entries are stored as little endian

GGXArchiver Format
Entry Format
Magic "GGXArchiver1.00" + 0x00
Unknown (number of files? more info?) 16-bytes, ex: 0x02 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 (/media/data/sc_logo.bin)

First four bytes are number of entries in the archive's file table(LE)

Second four bytes are number of "valid" entries in the file table (blank entries of 32 0x00 are "invalid")(LE)

Remaining 8 bytes are probably padding

File List 32-bytes per file, relative path to file, directories supported
File Headers Table Size seems to scale with number of files in archive

0x00-0x03 NID(LE)

0x04-0x07 static 1(LE)

0x08-0x0B uncompressed file size(LE)

0x0C-0x0F Size of compressed file data in archive, probably includes compression commands(LE)

0x10-0x13 Boolean? (could also represent compression type), is data compressed(LE)

0x14-0x17 Offset from end of file headers table to start of file(LE)

Repeated for each file in archive

Compression related data See below
File Data The actual data for each of the archived files. Appears to be have some endian weirdness, reversed every 32-bits? (Xenon is 32-bit BE, makes sense?)

Compression Information

Appears to be compressed with BPE (Byte-Pair Encoding) compression (quickbms compression method 25/55). quickbms sometimes fails decompression, may require new utility or manual decompression.

quickbms's reinsert2 is bugged, and will overwrite large swathes (if not the entire original file data) of the file data with zeroes, and then point GGXArchiver down to the new data. While this sometimes works, it could be the cause of freezing and bloats files regardless. Right now the solution is to manually hex edit the files to remove the zero padding and fix the offset pointers for impacted files. This has been successfully tested in Xenia on sc_title.bin.