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
Hex: Becoming a Succubus
Hex is an erotic visual novel RPG.
Status | In development |
Author | Outsider Artisan |
Genre | Role Playing, Visual Novel |
Tags | Adult, Fantasy, Female Protagonist, Multiplayer, NSFW, Story Rich, Text based, Twine |
Languages | English |
Accessibility | High-contrast, One button |
More posts
- Be wary of links in the comments20 hours ago
- I need some testing help.12 days ago
- Wakizashi fixed18 days ago
- Hex v0.1.4 (Patch)18 days ago
- Hex v0.1.3 (Patch)20 days ago
- Redemption Code: Red Prostitute Outfit21 days ago
- Hex v0.1.2 (Patch)22 days ago
- Hex v0.1.1 (Patch)24 days ago
- Major Update - "City Life"25 days ago
Comments
Log in with itch.io to leave a comment.
According to Crystallize:
Might be worth looking into, though, should also check how well that avif is supported on the web.
Edit: Another quote:
Edit2: Nevermind:
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?
Interesting, thanks. I’ll investigate for the future.
You were right about this, AVIF looks so much better, even when it’s more compressed. Thanks for telling me!
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.
based on my testing, the alpha channel works even using lossy compression (unless I’m misunderstanding something). here’s a comparison
I mean:
And yet:
Maybe this is old info, or incorrect or something :P
looks like javascript documentation now, lol. the web has infected it
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:
Notes:
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. usingForEach-Object -Parallel
.Commands used:
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.
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
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
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.
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 :)
That’s a good point, i kinda hit everything the same way here. I definitely have room to fine tune it. I’ll experiment.
Would've preferred the same image for comparison between PNG and webp in the above post.
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.