qoir VS chess

It's important to notice that ZPNG beats virtually all QOI variants, as discovered in: https://github.com/nigeltao/qoir

But most platforms these days have some form of CRC32 "acceleration". Adler32 is easy to compute so I'm even less concerned there.

I spent a bunch of time optimising the code in [fpnge](https://github.com/veluca93/fpnge), which is [often notably faster than fpng](https://github.com/nigeltao/qoir/blob/5671f584dcf84ddb71e28d...), yet checksum time is basically negligible.

Having said that, the double-checksum aspect of PNG does feel unnecessary.

* AFAIK it does this while beating the original QOI in terms of speed AND efficiency

Lots of benchmarks in: https://github.com/nigeltao/qoir

QOIX

QOIX is my very own version that adds:

I think it's in the title: assets. The example case is replacing the BMP assets used by a game with QOI with a resulting 10x size reduction: https://github.com/skeeto/chess/commit/5c123b3

I think this functions as a test case. For a game as simple as a chess UI, PNG would probably be fine unless you're code-golfing on the final output binary or refusing to use common dependencies. But for some programs (e.g. large video games), preloading all your assets is very common and decoding speed can be crucial. Maybe the assets could even be left in compressed form in memory in order to reduce the system requirements? I'm not sure if this is common or not.

However, I don't really like the constraints this imposes, so I prefer my #include trick. In real programs I don't actually rely on xxd (part of Vim), and instead write a custom embed tool as part of the build. It's only a few lines of code to match the standard input behavior of xxd.

https://github.com/skeeto/chess/commit/9cc8c60 (depends on Vim xxd)