search

haroohie-club / NitroPacker

A utility for (un)packing NDS ROMs as well as patching their ARM9 and overlays
GNU General Public License v3.0
15 stars 2 forks source link

detecting if overlay is compress seems strange #8

Closed axel7083 closed 7 months ago

axel7083 commented 7 months ago

In the SM64DS editor we are using the flags to determine if an overlay is compressed or not (see NitroOverlay.cs#L56 ).

You seems inside your RomOVT class to have a similar flag, named OVTFlag https://github.com/haroohie-club/NitroPacker/blob/37b5f247d9cb42ad212e2b566c54bf679e9ec5ab/HaroohieClub.NitroPacker.Nitro/Card/Rom.cs#L619-L623

But this is not used to determine if the overlay is compressed or not. You are using some operation that I am not sure to understand https://github.com/haroohie-club/NitroPacker/blob/37b5f247d9cb42ad212e2b566c54bf679e9ec5ab/HaroohieClub.NitroPacker.Nitro/Card/Rom.cs#L631

The issue i am having is, inside the SM64DS editor we are decompressing the overlays, this is necessary for some patches and we disable the compression using flags &= 0xFE; making the value of OVTFlag = 2;

As visible in the following screenshots ran on a patched rom, with decompressed

image

When using the unpack command, the overlays are decompress with the following check https://github.com/haroohie-club/NitroPacker/blob/b6876413434a0eb2f4a84ebd33cc5521786d03e9/HaroohieClub.NitroPacker.Core/NdsProjectFile.cs#L125-L130

which raise an error, as the data is not in a compressed format.

I am wondering if we (SM64DS Editor) are doing something wrong (maybe we are not properly changing some properties), or the issue is on how you detect an overlay is compressed.

Thanks you again very much for this amazing tool, I love it!