Exomizer question

[ervin]

Hi everyone.

I've been messing about a lot with Exomizer recently, and it's working really really well.
But I'm wondering if there is a way to decompress part of an exomized file, instead of the whole lot?

For example, I've got a number of sprite sheets, and they all compress really well individually.
I decompress a sprite sheet when it is required for my game... so far so good.

But tests have shown that the compression ratio improves when there is more data involved.
So if I could compress all my sprite sheets into one exo file, and then decompress a sheet from that single exo as required, that would perhaps let me get more sprites into my game.

If Exomizer can't do this, are there any compressors that can?

[ralferoo]

Generally, no. The reason you get better compressability with all the sets together is that there's more redundant information.

However, what you might be able to do if there's a main tile set always resident in memory is to always compress the main tile set AND each of the individual tilesets. The beginning section of each compressed file will be the same representing the compressed main tile set and the part at the end represents the individual tile sets but they can reference similar data in the main tile set.

You'd probably have to do some code hacking of the exomiser source to achieve this though.

[Hicks]

I made a custom version of Exomizer decruncher where you can ask at each CALL how many bytes you want to decrunch. It was for the Phreaks demo by No Recess. Try to contact him if you want to get it: Contact - NoRecess. I don't know if it will be compatible with the latest version of Exomizer...

[Sykobee (Briggsy)]

IIRC the decompressor needs to see what it previously decompressed during decompression, as the compressed data is references to previous data.


So whilst you can stop decompression after a certain time before the end of the file, you cannot start it a certain amount into the file.


Maybe there's a way to share a common dictionary of compressed data between different compressed areas.


What are the memory usage differences you are seeing?

[Hicks]

Sykobee is true, you can decrunch a file LINEARLY part by part (= what I do in my custom version: you start from the begining to the end of the file by asking each time how many bytes you want), but you can't decrunch it in a NON-LINEAR order (decrunch a part of the end of the file, then a part of the begining, ...). The linear order can often be used in a demo, but a game is more non-linear because of the choices of the player, so...

Be careful: Exomizer is quite slow to decrunch, even in his optimized version, and it can be a problem for a game if you want to try real-time decrunching. Maybe you can try Aplib, which is approx. 3 times faster on my test-files...

[ervin]

Thanks for the info everyone.
Some really great ideas in there.

Unfortunately I decrunch a lot of data each time the player enters a different room, but the player is free to go back and forth between rooms as they wish, so linear decrunching isn't possible.

Speed isn't an issue - the decrunching happens when the player changes rooms, and it only takes around a second (each sprite sheet is 8K uncompressed). It's not a high speed game (or even a game really), so it suits the pace just fine.

Also, there is no common shared data between sprite sheets. Each one represents something very different.
(I can't wait to show you all what I've been working on for a long time now!)

Nonetheless, all of your ideas may come in handy for the future, either for myself or others.

[pacomix]

It would be great if a new parameter could be added to that modified version of Exomizer so that it skip the first N bytes to decrunch. Then we would be able to decrunch any part of the file with the drawback of having to process the bitstream from the beginning.