Strike Witches: Silver Wing/Notes: Difference between revisions

From Data Crystal
Jump to navigation Jump to search
m (Typo fix)
(Compression command research)
Line 36: Line 36:
Repeated for each file in archive
Repeated for each file in archive
|-
|-
| Compression commands? || Details unknown
| Compression commands? || 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?)
| 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 Commands===
Commands may be encoded both before and within the data.  Generally seem to be upper values of bytes (0xF0-0xFF), but occasionally lower.
{| class="wikitable"
|+ Commands
|-
! Command !! Behavior !! Notes
|-
| 0xF0 || Add 3 zeroes? || Changing the first instance of it after file data starts in sc_logo.bin\LOGO_GULTI.DDS to 0x00 or 0xF1 hardlocks in Xenia.  Untested on HW.  DDS textures need header length to be 32-bit, compressed archive stores it as 8-bit, so somehow command adds another 3 zeroes?
|-
| 0xF1 ||  ||
|-
| 0xF2 || Text related? ||
|-
| 0xF3 ||  ||
|-
| 0xF4 ||  ||
|-
| 0xF5 ||  ||
|-
| 0xF6 ||  ||
|-
| 0xF7 ||  ||
|-
| 0xF8 ||  ||
|-
| 0xF9 ||  ||
|-
| 0xFA ||  ||
|-
| 0xFB ||  ||
|-
| 0xFC ||  ||
|-
| 0xFD ||  ||
|-
| 0xFE ||  ||
|-
| 0xFF ||  ||
|-
| Reserved || For || Future Expansion
|}
|}




{{Internal Data}}
{{Internal Data}}

Revision as of 01:49, 12 March 2024

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 unknown (0x01 for LOGO_GULTI.DDS in sc_logo.bin)(LE)

0x04-0x07 unknown (0x01 for LOGO_GULTI.DDS in sc_logo.bin)(LE)

0x08-0x0B uncompressed file size?(LE) (131,200 bytes in sc_logo.bin, exactly 128K + 124 byte DDS_HEADER + 4 byte dwMagic)

0x0C-0x0F Size of compressed file data in archive, probably includes compression commands (ex: sc_title.bin - 311,009 bytes = 0x00 0x8A 0xBE 0x04 = 310,921 bytes + 88 bytes before, only 1 file in archive)(LE)

0x10-0x13 Unknown

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

Repeated for each file in archive

Compression commands? 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 Commands

Commands may be encoded both before and within the data. Generally seem to be upper values of bytes (0xF0-0xFF), but occasionally lower.

Commands
Command Behavior Notes
0xF0 Add 3 zeroes? Changing the first instance of it after file data starts in sc_logo.bin\LOGO_GULTI.DDS to 0x00 or 0xF1 hardlocks in Xenia. Untested on HW. DDS textures need header length to be 32-bit, compressed archive stores it as 8-bit, so somehow command adds another 3 zeroes?
0xF1
0xF2 Text related?
0xF3
0xF4
0xF5
0xF6
0xF7
0xF8
0xF9
0xFA
0xFB
0xFC
0xFD
0xFE
0xFF
Reserved For Future Expansion