ZenHAX

Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Fri Jul 30, 2021 5:59 pm

All times are UTC




Post new topic  Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Thu Jul 22, 2021 4:04 pm 

Joined: Thu Jul 22, 2021 3:40 pm
Posts: 3
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


Attachments:
RMfiles.rar [3.23 MiB]
Downloaded 9 times
Top
   
PostPosted: Fri Jul 23, 2021 3:25 pm 

Joined: Mon Jun 07, 2021 8:20 pm
Posts: 27
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".


Top
   
PostPosted: Fri Jul 23, 2021 4:44 pm 

Joined: Thu Jul 22, 2021 3:40 pm
Posts: 3
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


Top
   
PostPosted: Fri Jul 23, 2021 5:55 pm 

Joined: Mon Jun 07, 2021 8:20 pm
Posts: 27
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.


Top
   
PostPosted: Thu Jul 29, 2021 9:18 pm 

Joined: Thu Jul 22, 2021 3:40 pm
Posts: 3
Not sure if this is even remotely the same NRV2b compression used. Or how to modify this compressor/decompressor https://github.com/mdrngrng/nrv2b


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 5 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited