Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+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) (+1)

I didn’t mean to use lossless for the web version, but for the offline downloads. If it’s lossless, it’s the same quality, but saves the user download time and disk space. Again, not at all important, especially not this early in development, but you yourself mentioned that there would be a lot more in the future, so might be something to consider at one point. (Edit: Also, optimizing PNGs took a lot longer that converting to lossless webp, and only reduced sizes a little, so I don’t think it’s really worth it)

In my personal opinion, reducing asset quality for the web version is completely reasonable, so don’t sweat it too much 😁 (Edit: I’m on Android so I see no difference in quality really, the screen is too small for that 🤷, and even on desktop, unless you try to find faults, reasonable quality loss should be fine)

JXL situation really sucks, could’ve been something great.

Lastly, webp has a setting called preset which you can set to drawing. According to the docs:

Specify a set of pre-defined parameters to suit a particular type of source material. Possible values are: default, photo, picture, drawing, icon, text.
Since -preset overwrites the other parameters' values (except the -q one), this option should preferably appear first in the order of the arguments.

Did you use that when converting to lossy webp? Could that improve the quality a bit?

(+1)

I wasn’t aware of that, I used imagemagick and I didn’t see that option when I checked the docs, but maybe that’s what image-hint was for…

Optimizing the downloadable versions is a good idea.

In my personal opinion, reducing asset quality for the web version is completely reasonable, so don’t sweat it too much 😁 (Edit: I’m on Android so I see no difference in quality really, the screen is too small for that 🤷, and even on desktop, unless you try to find faults, reasonable quality loss should be fine)

It’s probably just because I know what to look for, so it sticks out to me. But yeah, that’s a good point, especially on mobile there’s no way you’d be able to tell.

(1 edit)

Would it be possible to dynamically detect screen size/platform and fetch assets of slightly lower quality on mobiles (Android and IOS), and stightly higher on desktops? That would be the best of both worlds kind of approach, though it would take twice as long and as nuch effort to encode in 2 different quality settings.

that’s a good idea! I’m actually already detecting the screen’s size to decide which interface scaling settings to default to, so I could do that. having to encode the imaged an additional time is annoying, but it’s not a deal breaker or anything