This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=15551

Sonikku A, posted Thu Jul 22, 2021 4:04 pm (65306)

---

So I noticed that Super Monkey Ball Adventure used the same engine as Crash Twinsanity. And similar to that the RM/SM archives contain the graphical data
However for whatever reason, the PS2 version the RM files are compressed, while PSP's isn't. As such, support from the Twinsanity editor only is for the PSP version, but given graphical downgrades, I'd like the PS2 version to be cracked as well
Here's the PS2 RM file and PSP RM file:
For those wondering, the GC version uses the Lego engine, so it won't help in this case

grandshot, posted Fri Jul 23, 2021 3:25 pm (65319)

---

Format is simple and described in twinsanity editor sources. Represents a Chunk Package, where chunks contain other chunks.
Structure is:

Code:

int32 type;
uint32 num_files;
For psp: uint32 num_files;
For ps2: uint16 num_files; uint16 unknown;
uint32 chunk_size;

if type is 0x01000100 then its the chunk table which having info about other files in package, in count of num_files:

Code:

uint32 file_offset;
uint32 file_size;
uint32 file_id;

Main difference between versions - ps2 files packed in PACK containers, with NRV2b compression. Difficult is that file_size value in chunk tables definite only uncompressed size. PACK containers have only 32 bit value, after "KCAP" magic, which doesnt looks like compressed file size.
Well, it's possible to calculate byte ranges of compressed data by "KCAP" magic's and known offsets, but thats the "real crooked nail".

Sonikku A, posted Fri Jul 23, 2021 4:44 pm (65320)

---

grandshot wrote:

Format is simple and described in twinsanity editor sources. Represents a Chunk Package, where chunks contain other chunks.
Structure is:

Code:

int32 type;
uint32 num_files;
For psp: uint32 num_files;
For ps2: uint16 num_files; uint16 unknown;
uint32 chunk_size;

if type is 0x01000100 then its the chunk table which having info about other files in package, in count of num_files:

Code:

uint32 file_offset;
uint32 file_size;
uint32 file_id;

Main difference between versions - ps2 files packed in PACK containers, with NRV2b compression. Difficult is that file_size value in chunk tables definite only uncompressed size. PACK containers have only 32 bit value, after "KCAP" magic, which doesnt looks like compressed file size.
Well, it's possible to calculate byte ranges of compressed data by "KCAP" magic's and known offsets, but thats the "real crooked nail".

So in my severely limited knowledge, that means it's only partially compressed? Sounds weird

grandshot, posted Fri Jul 23, 2021 5:55 pm (65322)

---

No, only if file starts with "KCAP" then it compressed.
In easy words, from chunks we know file offsets and file sizes. For PSP version we can just go to offset and read bytes equal to file_size. For PS2 version it's no work, because actial size of compressed data is smallest then file_size. We will read more bytes than needed, or, if that is the last file, get error what end of file reached before required bytes was readed.

Sonikku A, posted Thu Jul 29, 2021 9:18 pm (65405)

---

Not sure if this is even remotely the same NRV2b compression used. Or how to modify this compressor/decompressor https://github.com/mdrngrng/nrv2b