TEST: PNG/Deflate compression option for sprites

[ivan-mogilko]

WARNING: for test only, not for merging at the moment.

This is a remake of #2098, with properly linked zlib, fixed compilation and logical mistakes.

Introduces a new compression option for sprites, called "PNG" for simplicity sake, which uses Deflate algorithm.

Current implementation requires to link a zlib library. But I'd like to investigate if it's feasible to embed necessary set of functions directly into the engine, similar to how stb_image library does this (for example).

I did not configure CMake scripts yet, so for now here's a compiled Editor & windows engine for testing:
https://www.dropbox.com/scl/fi/frvbx4fbaxuk4ebz098cz/ags-3.6.1-testpng.zip?rlkey=5mmy8vyfasfqhir5rxpywgr9o&dl=0

WARNING: do either backup "acsprset.spr" before testing this on a real game, or make sure that you have all the sprite sources to recreate it from them, in case something goes wrong. Because of the new PNG option the spritefile's format will be changed and compression type not recognized by a standard version of AGS.

---

Tests on a real game shows improvement up to x2 in compressed size compared to LZW option (example: 485 MB vs 278 MB). More tests may be required to gather better statistics, but it's already looks very promising in regards to saved disk size.

The question of runtime performance (speed) still remains; I did not do any tests for that so far. Imo it's best to test speed with a high-resolution games, but I don't have an actual project source atm to try different compression options.
(although we could make a standalone tool that recompiles a spritefile, changing compression in a ready game).

But if decompression does not slow gameplay noticeably, the LZW option may actually be deprecated in favor of PNG.

Another potential future option would be to use PNG compression for room files too, in place of LZW, which might reduce game size further.

[ericoporto]

Not sure is useful, but this library exists: https://github.com/richgel999/fpng . It's Public Domain code, and only 3k lines of code, and it still has places to be sliced down. Edit: ok, now I understood the code, it's really just using deflate algorithm, not png files.

[ivan-mogilko]

it's really just using deflate algorithm, not png files.

Yes right, it's not about saving PNG format, but about compressing a random binary data. Currently we compress sprites in our own spritefile form (just a pixel array). But I guess we could make this compatible to compress any random data we need too.

I'm not biased towards any library, or cherry picking code from one; if there's a deflate/inflate code that works and provides a good compression results, then we might use that.

[ericoporto]

I found miniz one that is released as an .h and .c file, that is zlib compatible. Did a quick test throwing the files in AGS repo for testing ericoporto@c2067de (https://cirrus-ci.com/task/5672323672440832) - there is a lot from it that can be cutout still, I think I can get it from 7k lines to 3k lines of code or less - but maybe we still want to keep it out of the repo, but it appears it is fast enough.

Don't Give Up the Cat acsprset.spr file went from 645kb to 283kb. Made a test game with ~8000 of HD sprites clocked 1400 MB with the LZW compression. Using the deflate from miniz, it went down to 614 MB!

So it appears it's a reduction around 60% of size.

Using miniz it increased the acwin.exe in 33 kB.

[ivan-mogilko]

Closed this in favor of #2114 (we'll see which library variant works better for us).