Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes, that's the problem. You can compress them for size at download time, and recompress them to a GPU-optimal format at the time of installation. You may even be able to do it at runtime with modern hardware, shortening loadtimes and sometimes even improving performance indirectly.


You can combine the approaches! KTX2, for example, supports "supercompressing" GPU block compressed formats with LZ4 or Zstandard. The project I have been working on ships BCn textures compressed with zstd and it has been pretty dang good.


Then you have to have the game reprocess all the assets on the users machine which could easily take an hour


Essentially any modern image compression format is going to be limited, or close to, by storage speed (for decompression). So unless the user has insanely fast internet (and the servers are also able to saturate their connection), it will be faster in the end.


With the size of games nowadays, that's likely a net time save for many people from the discounted download time.


Gamers being gamers though they’re not going to say “well, we on reflection I’ve not had to wait so long”, they’re going to slam you with one star reviews for the fact there’s an hour long loading screen on first start.


The recompression/decompression logic could (and I would argue, should) be packaged separately for distribution platform instead of being embedded as part of the game's logic. In the case of using Steam, it would be no different than how it shows separation of time spent downloading vs time spent installing.

This allows it to be ran automatically after download without having the user need to launch the game.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: