Managing free space and cleaning the old data

Many tools and tutorials forget to clean the old data after repointing.
I am using PGE to insert sprites of NDS pokemon into Emerald, but it doesn't clean the old sprites.
I think am doing something wrong, because a single sprite sheet adds 40k bytes into the rom and the source png file is only 4kb.

So I have a question. Given an offset to an image, how to know the length in bytes of that image? I need to know how many bytes of old data I have to release manually.

Stocke said:

Many tools and tutorials forget to clean the old data after repointing.
I am using PGE to insert sprites of NDS pokemon into Emerald, but it doesn't clean the old sprites.
I think am doing something wrong, because a single sprite sheet adds 40k bytes into the rom and the source png file is only 4kb.

So I have a question. Given an offset to an image, how to know the length in bytes of that image? I need to know how many bytes of old data I have to release manually.

Click to expand...

The size of an image depends on a number of factors, including its dimensions, format and whether it is compressed or not. You won't be able to see how much space a PNG should take up, since PNG is a compressed format completely different to that of the GBA format, so the size will obviously change when you insert it.

To answer your question, if the image is compressed, it's really easy to tell the size. A compressed image looks like this:

10 XX XX XX [BYTES...]

The 0x10 indicates LZSS compression, while the XXs (little endian) are the length of the bytes section. Simply clean those 4 bytes and then that length number of bytes after it.

If it is uncompressed, you need to work out the length of the image manually. For 4bpp images this is width * height / 2 bytes and for 8bpp images it is width * height bytes.

Touched said:

To answer your question, if the image is compressed, it's really easy to tell the size. A compressed image looks like this:

10 XX XX XX [BYTES...]

The 0x10 indicates LZSS compression, while the XXs (little endian) are the length of the bytes section. Simply clean those 4 bytes and then that length number of bytes after it.

Click to expand...

I see, but it is the real size of the image. I am looking for the size of the space used by the compressed image. Where does the image data end in the rom? It is important in order to delete the image and reuse the space.

Palettes are compressed as well, I found a palette that starts with 1C.

Stocke said:

I see, but it is the real size of the image. I am looking for the size of the space used by the compressed image. Where does the image data end in the rom? It is important in order to delete the image and reuse the space.

Palettes are compressed as well, I found a palette that starts with 1C.

Click to expand...

You're not going to be able to find out the compressed size of the image without decompressing it (i.e write custom software), which is probably why no tool cleans up after itself. The compression algorithm just keeps reading bytes until it has decompressed the number of bytes that appear in that header.

All LZSS packing tools (including those provided in the Nintendo SDK) enforce the 0x10 in the header. While this exact value is not enforced by the BIOS, the unpacking routines expect at least one byte to be there. I doubt any build procedure would have removed or changed this value because that would've unnecessarily complicated things, so I'm guessing that palette you found was just uncompressed.

Thank you for the help.
I have found a decompression function to get the size.

https://gist.github.com/Prof9/872e67a08e17081ca00e