Web version changes coming soon.


So if you didn’t know, I use a CDN to deliver most assets to the web version of Hex, which keeps the game running and loading well despite the massive number of assets the game requires. This ended up being much more expensive than I anticipated. While the traffic will certainly go down over the next few days, the game will only get bigger and hopefully more popular over the coming months and years, so some changes are needed in order to keep the game playable and fun (and possible for me to provide for free).

The web version of the game will be serving WebP format images from now on. You can see a comparison above. WebPs are extremely lightweight and support transparency (an absolute must for our use-case), but are actually designed specifically for photographs and often look rough with artwork that has smooth gradients and sharp lines. However, WebPs are more than 80% smaller than PNGs. While the images on the web version won’t look as good and may have visible artifacts, the savings are just too good to ignore.

The offline browser version will still use PNGs, and the Windows version will also use PNGs and continue to provide an option for 4K PNGs as well. This will create a clear hierarchy for the game’s quality, so I encourage users to use the Windows version if at all possible, then the offline browser version, and finally the web version if that’s their only option.

Get Hex: Becoming a Succubus

Download NowName your own price

Comments

Log in with itch.io to leave a comment.

(3 edits) (+3)

According to Crystallize:

AVIF: Utilizes the AV1 video codec to achieve superior compression rates, resulting in file sizes up to 50% smaller than JPEG and 20-30% smaller than WebP for equivalent quality levels.

Might be worth looking into, though, should also check how well that avif is supported on the web.

Edit: Another quote:

AVIF is supported since: Chrome version 85, Edge version 121, Firefox version 93 and Safari version 16. bringing full support since 2024-01-26.

Edit2: Nevermind:

AVIF supports transparency for lossless images but doesn’t support transparency for lossy images. On the other hand, WebP is the only image format that supports RGB channel transparency for lossy images.

Looks like it won’t work for the use case. I wonder how well would JPEG XL have worked, if only Google didn’t murder it -_-

Edit3: Might still be worth considering for things like the backgrounds, where alpha is not needed?

(+2)

Interesting, thanks. I’ll investigate for the future.

(+2)

You were right about this, AVIF looks so much better, even when it’s more compressed. Thanks for telling me!

(+2)

Happy to have gelped, though as I mentioned, apparently it doesn’t support alpha channel/transparency when using lossy compression. Also, apparently, it doesn’t support sRGB, so the conversion from PNG to AVIF is not 100% lossless, since there’s some small loss when converting color spaces.

(1 edit) (+2)

based on my testing, the alpha channel works even using lossy compression (unless I’m misunderstanding something). here’s a comparison

(+1)

I mean:

AVIF supports transparency for lossless images but doesn’t support transparency for lossy images. On the other hand, WebP is the only image format that supports RGB channel transparency for lossy images.

And yet:

AVIF supports alpha but instead of using a pixel format like most other codecs, it uses a second video stream as an alpha matte.

Maybe this is old info, or incorrect or something :P

(1 edit) (+1)

looks like javascript documentation now, lol. the web has infected it

(5 edits) (+1)

I tried comparing encodings myself too, though in my case I tried lossless compressions, in case you decide to to reduce the size of the offline files without loosing the quality:

Edit: Forgot to mention, I used the 0.1.1 version in this test, in case you want to reproduce.

| | Total | % Total | 503 Images | % Images | Time | | ——— | —— | —–– | ––––– | –––– | –––– | | Original | 437 MB | 100 % | 168 MB | 100 % | 00:00:00 | | Optimized | 418 MB | 96 % | 150 MB | 89 % | 01:00:00 | | Webp | 364 MB | 83 % | 94 MB | 56 % | 00:04:04 | | JPEG XL | 345 MB | 79 % | 77 MB | 46 % | 04:21:02 | | AVIF | 396 MB | 91 % | 127 MB | 76 % | 00:36:49 |

Edit: Damn, looks like the markdown engine doesn’t support tables, using an image instead:

Table

Notes:

  • The measured time are not very accurate, since I was using the system at the same time as the encoding was happening. I also lost the time it took to optimize PNGs, so I just put how long I thought it took (about an hour). Still, it should give a rough indication on encoding speed.
  • I used the most aggressive settings on all encodings, in other words, I let the tools use as much time as needed to get as little files as possible. A more sane configuration would probably reduce the time while keeping most of the space saving.
  • cjxl (the tool used to encode to jxl) didn’t seem to use more than one core even though I told it to use 32 threads, next time I’d parallelize jobs manually, e.g. using ForEach-Object -Parallel.

Commands used:

  • For optimization I used PNGGauntlet, which is a GUI application that “Combines PNGOUT, OptiPNG, and DeflOpt to create the smallest PNGs”
  • cwebp -preset drawing -lossless -z 9 -m 6 -pass 5 -quiet IMAGE.png -o IMAGE.webp
  • cjxl IMAGE.png IMAGE.jxl -a 0 -q 100 -e 10 –num_threads=32 --quiet
  • avifenc --lossless -q 100 –qalpha 100 -s 0 --jobs 32 IMAGE.png IMAGE.avif

Takeaway: Even though AVIF generally has the best compression ratio when using lossy compression, it’s only a bit better than an optimized PNG when using lossless compression (and it’s not actually 100% mathematically lossless, since AVIF doesn’t support the same color space that PNG uses, so there’s some change during color space conversion). The best format seems to be JPEG XL, unfortunately Google really wants to push WEBP and AVIF, which are both fully or partially designed by Google, so support for JXL is not good, so with that said, the best all around for lossless compression seems to be WEBP with almost half the space of PNG while still being 100% lossless, but also the fastest to complete the encoding due to the maturity of the libraries.

(+1)

Thanks a lot for doing all of this! I don’t think I can do lossless rn, but this is really useful information! If my budget gets high enough, I do plan to increase the quality of the web assets in accordance. I am committed to the web as a platform, so it really hurts me to provide a compromised version on the web. It does seem like WebP for lossless and AVIF for lossy is the way to go. Optimizing the PNGs is also something I should do…

I’ve rewritten a ton of code to abstract away all the “.png”s in the code base already, so I should be able to quickly move to and deploy different image formats easily now. All the legwork is basically done. I did actually look at JXL, but yeah, the browser support is a non-starter. I wish I had investigated AVIF more earlier though

(2 edits) (+3)

WebP has both lossless and lossy compression support, they aren't inherently any different from .png image quality unless you specifically choose to make them so. On average the lossless WebP is 25% smaller than a PNG, while the lossy version size depends entirely on what image quality you choose - set it to 0 and you get tiny, absolutely horrendeous images, set it to 100 and they look almost as good as PNG, but are basically JPG in size.

For example, taking the Hex banner image, the png is 2.4MB, lossless WebP is 1.5MB, 100% quality lossy is 0.6MB, 80% is 0.2MB, and the 0% is only 34KB but looks as attached :P

(1 edit) (+1)

In this case, I had a predefined target I wanted the total assets to reach, so I went with a level of quality that got me there. It’s all budgeting though, if the game does really well I’ll be able to offer larger files. I think the game ran well enough on the web with the PNGs so I could likely go all the way up to 100% quality if I can budget the for the bandwidth.

(+2)

Makes sense, that's a quick and easy solution.

One thing you could still play with is using different levels for different types of assets - especially compressing backgrounds with lots of details and noise with lossy WebP will provide a *massive* size improvements compared to PNG which is terrible at compressing that (as showcased in my example of 2.4 -> 0.6/0.2), which could allow you to still use lossless for the sprites. Kinda best of both worlds.
But mostly, I just wanted to make sure you knew that lossless is an option for you to use :)

(+2)

That’s a good point, i kinda hit everything the same way here. I definitely have room to fine tune it. I’ll experiment.

(+3)

Would've preferred the same image for comparison between PNG and webp in the above post.

(1 edit) (+2)

That might’ve been smart. Here’s some of the more obvious differences I was trying to show. I’ll update the image in the post later if I have time.