Add support for ZIMs in texture replacements #14467
Conversation
Larger, but can be ZSTD compressed and load much faster.
There's decompression speed tradeoffs at some levels.
|
Cool. I wonder whether it would make sense to try something extremely light and SIMD-able as a preprocess, like deltas just between lines, or something. Or maybe not, since being within 25% of png isn't too bad. We still have free flags though so could easily experiment with variants if we can be bothered :) The Basis codec has been standardized into KTX 2.0 btw, that's another one that would be cool to support now that it'll hopefully get some more tool support... I'll take a closer look and probably merge tomorrow. |
|
Yeah, I also saw https://github.com/catid/Zpng which was someone's experimental thing. I think it would be easy to apply some fast filters that could be applied during a copy. But then I'm inventing a new format and maybe basis is better. I suppose there's this: I was a bit scared away by the repo saying it requires LFS, which I'm not sure if means it's not a great submodule candidate... -[Unknown] |
|
Well basis is a different thing, it's lossy. However doubling the resolution while using lossy compression can look better than lossless at original resolution, if you're talking quality per byte... |
|
Right, and it'll use less or same VRAM still as long as the GPU supports some compressed format. This was just easy because I'd previously added ZSTD for the UI texture ZIM (which was previously gzip.) Since this is 2.75x PNG, if it significantly improves hitching for people experiencing it, that should confirm the likely benefits of Basis support and potential preloading options. I don't necessarily intend for everyone to create ZIM texture packs, but someone trying it will give useful information and it's easy to keep support anyway. -[Unknown] |
|
OK :) That's a good reason. |
|
Although KTX2 is now the recommended choice for most textures. For fonts and other things that need to be pixel-perfect though, ZIM is a good alternative. |
This makes zimtool (built as ext\native\tools\build\ZimTool.exe on Windows) able to compress using ZSTD, and then supports such images in texture replacements. Only 8888 is supported.
I realize we could support more exotic formats, but this was a very easy format to support given our codebase already handles it.
To test, I hacked replacements to always reload the texture and went to an area with primarily a single 512x512 texture upscaled to 1024x1024. Then I measured different image types:
Most of the time was in
fread()when uncompressed. Importantly, this was the same image over and over again - so this doesn't measure the stresses of a large texture pack accurately. Still, ZIMs load much faster.In my tests, ZIMs were about 25% larger on disk at level 22 (keep in mind there are no PNG filters at play here), and less than 50% larger at level 12. Uncompressed was obviously much larger.
-[Unknown]