News: 11 March 2016 - Forum Rules

Author Topic: SEGAGAGA compressed PVRT image decompression?  (Read 1665 times)

Mistyhands

  • Jr. Member
  • **
  • Posts: 2
    • View Profile
SEGAGAGA compressed PVRT image decompression?
« on: November 10, 2021, 09:46:34 pm »
The main challenge posed in translating the game SEGAGAGA, apart from the font width issue, seems to be the fact that most textures are stored in a compressed format and I haven't seen anyone online successfully able to decompress them.

These textures appeared to be stored in .MRG files (which are just the files in a row, with gaps of variable size). However, no PVR, PVR-X or any related tool (also tried Noesis and PuyoTools) seems to be able to open them.

Header example: left (uncompressed PVR file), right (compressed). .

Based on my rudimentary knowledge, I guess it could be LZSS compressed but maybe the standard header info is omitted and hard coded elsewhere. Given discussion has come up on it years ago though, if it were that simple, I'd assume someone would have figured it out already.

So I suppose my question is - is there any clue on how to decompress these images?

Sample MRG file (contains a bunch of compressed PVRT files): https://vixyn.eu/file/_SG_LOGO.MRG
Sample uncompressed PVRT file which is readable by all tools: https://vixyn.eu/file/WOODBOX.PVR


FAST6191

  • Hero Member
  • *****
  • Posts: 3529
    • View Profile
Re: SEGAGAGA compressed PVRT image decompression?
« Reply #1 on: November 11, 2021, 06:05:10 am »
My usual link for overviews of compression is https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf

I assume those are not the same file -- it is generally best to try to get those. Can be between different regions/betas/whatever but most tend to have them come from RAM where it is decompressed to be used. Can figure it out from comparing things there, though if you can then tracing tends to work well as most decompression tends to run if this then copy this section*/repeat this value a bunch of times else carry on to next one.

*LZ being more direct on that front, huffman being more of a lookup of a given value from a table.

kof888

  • Jr. Member
  • **
  • Posts: 12
    • View Profile
Re: SEGAGAGA compressed PVRT image decompression?
« Reply #2 on: November 12, 2021, 09:38:23 am »
If you can read sh4's assembler

the decompression entry for this game is at 8C019F78

where there are several different branches

register r4 is the address where the decompression data is stored

register r5 is the address of the compressed data

Mistyhands

  • Jr. Member
  • **
  • Posts: 2
    • View Profile
Re: SEGAGAGA compressed PVRT image decompression?
« Reply #3 on: November 13, 2021, 10:32:13 am »
If you can read sh4's assembler

the decompression entry for this game is at 8C019F78

where there are several different branches

register r4 is the address where the decompression data is stored

register r5 is the address of the compressed data


Cheers. I saw that nullDC had a working debugger but there was no way to dump memory or go to a specific memory address. Admittedly there is probably something I'm overlooking

ateam

  • Jr. Member
  • **
  • Posts: 2
    • View Profile
Re: SEGAGAGA compressed PVRT image decompression?
« Reply #4 on: December 18, 2021, 12:24:06 am »
Here's a modified version of NullDC with RAM and VRAM dump functionality:
https://drive.google.com/file/d/1VJCrK54OukQHT8xMPfx9AuN-89aEcSHi/view?usp=sharing

In case you haven't figured out the header of the .MRG files, or how to extract the individual files from them, it's formatted as follows.



  • First set of 4 bytes is little-endian representation of number of files in the container (BE 0x02000000 => LE 0x00000002 => decimal 2).
  • Second set of 4 bytes is little-endian representation of location for first file (BE 0x00080000 => LE 0x00000800 => decimal 2048).
  • Third set of 4 bytes is little-endian representation of length (in bytes) for first file (BE 0xFD7B0000 => LE 0x00007BFD => decimal 31741).
  • Fourth set of 4 bytes is little-endian representation of location for second file (BE 0x00880000 => LE 0x00008800 => decimal 34816).
  • Fifth set of 4 bytes is little-endian representation of length (in bytes) for second file (BE 0x391B0000 => LE 0x00001B39 => decimal 6969).
« Last Edit: December 18, 2021, 10:47:53 am by ateam »