Yaz0 compression can cause data corruption in Pikmin 2
RenolY2 opened this issue · 2 comments
Recently somebody notified me about an issue related to image data in Pikmin 2 being corrupted from yaz0 compression when using either of two compression tools, wszst and GCFT. The corruption pattern can be different depending on the tool, with GCFT it can look like this:
The bubble background that you can see in the bottom left corner of the screenshot is affected by this corruption. That colored bunch of pixels below the bubble isn't supposed to exist and the bubble is supposed to look like this normally:
I've investigated this more in depth and I've found that the cause of this issue is the lack of padding. The corruption goes away when padding the yaz0 data to a multiple of 32 bytes with zeros. All szs files in Pikmin 2 seem to be padded to a multiple of 32 bytes with zeros. I think Pikmin 2 doesn't check on every byte if it has reached the end of the file and instead on every 32 bytes so it reads past the end of the file and tries to parse any garbage that lies there as compressed data, which is why the padding with zeros is necessary. In this case the corruption is visual but I can imagine that depending on what file is located at the end of a rarc the corruption could even cause a crash.
I used GCFT 1.8.0.
The following zip contains the original compressed and the GCFT compressed res_ground file from Pikmin 2.
res_ground.zip
Wind Waker, Twilight Princess, and Super Mario Sunshine all have ARCs that aren't padded to 0x20 in vanilla. If Nintendo's tools didn't enforce this, I don't want to either, but I could add an optional checkbox to do it.
Nintendo's tool for Pikmin 2 seems to have enforced it but their tool for the other games seem to not have enforced it. An optional checkbox might be the way to handle this.