Jump to content

BLZ re-compressing failure


modder

Recommended Posts

Hello everyone, I am new to DS rom hacking and I need some help on the compressing of overlay files on black/white.

1. What I have done.

I have unpacked using DSLAZY and decoded the overlay_0093.bin using BLZ.exe, then modified some entries on the type effectiveness table. I never inserted or deleted anything (which means file size stays exactly the same for the uncompressed version).

Then, I re-compressed the overlay_0093.bin using BLZ.exe -en option, and packed using DSLAZY again.

The game whites out whenever I enter a battle, which means, very likely the effectiveness table is not loaded correctly.

2. Some guesses and testing

2.1 TEST1

I then realized the size of the re-packed nds file is not same as the original one because of some possible trimming by ndstool, which is basically called by DSLAZY.bat.

I wanted to try some other packing tools but I am not able to use dsbuff on my windows 8 environment as the windows size is messed up and I am not able to see any button on the bottom portion of the window so I don't know will that one be able to generate a same sized file.

However, then I tried using the original overlay_0093.bin and re-packed using DSLAZY, this time it worked fine, which leads to the conclusion that it's not likely to be packing problem.

2.2 TEST2

I also tried to manually insert the compressed file into the original .nds file (replace the section of the original file in a hex editor), but that did not work either.

Based on test1 and test2, I would say it's 99% not because of packing issue and is 99% because of compressing issue.

2.3 TEST3

I decompressed the original overlay_0093.bin (lets say it's Ver0) using -d option and immediately recompressed it without any modification. The resulting binary (lets say it's Ver1) is much different from the original one. (ver0 different from ver1)

However, when I tried again decompressing ver1 and immediately recompress it back, the resulting binary ver2 is exactly same as ver1.

In addition, the decompressed version of ver0, ver1, ver2 are all the same.

I am kind of out of idea now because it is either the decompressing of ver0 is wrong or the compressing process is wrong but I can't figure out which it is.

Well since someonehad successfully modified the type table before I would say the BLZ code itself is not wrong.

I can only think of two possibilities:

A. I am not using the BLZ correctly

B. Only partial portion of the file is compressed and I need to somehow only decompress and compress that portion.

Can anyone help me with this? Especially if someone had successfully done some modifications on the type effectiveness table could help me I would really appreciate!

At last, thank you for taking the time reading this long post.

Sincerely,

modder

Link to comment
Share on other sites

An update here

I modified the overlay table so that the program now reads into the memory without compressing, and packed directly using the uncompressed version of the modified overlay_0093.bin and the battle does not white out anymore.

It is clear now that the problem is the compressing.

Is it supposed to not work? Am I missing some extra options or anything?

Even though things worked now I am still curious about why the compressed version does not work.

Link to comment
Share on other sites

Oh my ogd finnaly I have found the reason. My guess was totally wrong.

The overlay table actually has 3 bytes before the compress-or-not flag byte that indicates the size of the overlay binary. I set that 3 bytes to the new value which is 4 bytes less than the original value and things worked.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...