This topic was archived here:

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

chrrox, posted Mon Sep 01, 2014 4:07 pm (336)

---

Can this be added to quickbms.
There is source code for it.
https://code.google.com/p/dsdecmp/
And i have attached a sample.

chrrox, posted Mon Sep 01, 2014 10:43 pm (342)

---

it appears the tool miss calculated the size and did not add it to the header at the end.
But i am still having trouble with this file.
http://gbatemp.net/threads/recompressin ... le.329576/

aluigi, posted Fri Sep 05, 2014 3:22 pm (384)

---

dsdecmp contains various algorithms and quickbms already implements most of them.
You can check them in goldensun.c, luminousarc.c and nintendo.c

The list of comtypes should be the following:
lz77wii
lz77wii_raw10
lz77wii_raw11
lz77wii_raw20
lz77wii_raw30
lz77wii_raw40
goldensun
luminousarc

It's not clear in that pmo files where the compressed data starts.

chrrox, posted Fri Sep 05, 2014 9:37 pm (391)

---

its this format
https://code.google.com/p/dsdecmp/sourc ... s/LZOvl.cs

Code:

            #region Format description
            // Overlay LZ compression is basically just LZ-0x10 compression.
            // however the order if reading is reversed: the compression starts at the end of the file.
            // Assuming we start reading at the end towards the beginning, the format is:
            /*
             * u32 extraSize; // decompressed data size = file length (including header)   this value
             * u8 headerSize;
             * u24 compressedLength; // can be less than file size (w/o header). If so, the rest of the file is uncompressed.
             *                       // may also be the file size
             * u8[headerSize-8] padding; // 0xFF-s
             * 
             * 0x10-like-compressed data follows (without the usual 4-byte header).
             * The only difference is that 2 should be added to the DISP value in compressed blocks
             * to get the proper value.
             * the u32 and u24 are read most significant byte first.
             * if extraSize is 0, there is no headerSize, decompressedLength or padding.
             * the data starts immediately, and is uncompressed.
             * 
             * arm9.bin has 3 extra u32 values at the 'start' (ie: end of the file),
             * which may be ignored. (and are ignored here) These 12 bytes also should not
             * be included in the computation of the output size.
             */
            #endregion

this looks like the lz-0x10
https://code.google.com/p/dsdecmp/sourc ... ro/LZ10.cs

aluigi, posted Sun Sep 07, 2014 6:35 am (396)

---

ok, basically it works from the end to the beginning of the compressed data.

The code of dsdecmp has been updated from the last time I checked it for quickbms, what I don't understand is why lz10.cs differs so much than the old code.

chrrox, posted Sun Sep 07, 2014 11:20 am (405)

---

Yes it seems to be reverse compression.
Do yo think its possible to add this to quickbms?

aluigi, posted Sun Sep 07, 2014 4:47 pm (408)

---

yes, it's in my TODO list.

My doubt now is about the other algoritms because I know that they work in quickbms so I would avoid to re-porting the dsdecmp code again to match the current code.