@susie @Jain @SuperDicq :blobcatgrimacing: kinda both on the woozybus here. asset compression has its own problems and its ok because non-gamedevs generally don't know this but

the graphics card doesn't speak JXL, and the sound card doesn't speak Opus, so you end up having to have decoder stages.

For sound its been fine for decades as we have enough compute and RAM to just decode a little bit of mp3 at a time in to a buffer that gets pulled by the audio interface (the soundcard tells you when its sound time, we don't tell it)

for textures its not as good because we do the equivalent of unpacking the jpeg-xl and saving it as a bmp file. that bmp file is basically how the image exists in vram. much, much larger file, quickly slurping your 4GBs.

so instead we do a little texture compression, which uses algorithms that the GPU does happen to speak, and those tend to be significantly worse (both in terms of giving you shitty blocky graphics easier, but also only having 1:2 or 1:4 ratios, far worse than a naive clone of JP2K or anything) and on top of that it also makes the file kinda already compressed, so you can't then pack it again.

games tend to just store stuff in these texture formats despite the size because you can immediately pop them open, slurp the texture size you want (they also tend to store the texture in 1/2 recursive sizes, for mipmap purposes) and jam it on the GPU, skipping unpacking steps, because the player has ADHD and is frothing at the loading screen in anger during this whole process.

there are some tricks like basis universal that tries to find a way to store the textures 'mostly' compresed, so they can quickly finish the job based on the target GPU while still being able to pack it with zstd for shipping, which i've never used (but terry's neurons will activate at the mention of, and people do ship it)