In your game assets do you make room for explicit sanity checks, or do you have some generally expected bounds which you assert?
I've been thinking about how we compress data and thought that it's much better to have the former, and less of the latter. If your data can exceed your normal valid ranges, but if it does it's an error, then surely that implies you're not compressing the data well enough?
What do you do to find out if your data is compressed as far as it can be, and what do you use to ensure your data isn't corrupted and ensure it's an official release?
I'm not interested in sanity checking the file size, but instead, how you manage your sanity checks and whether you arrange the excess size caused by the opportunity to do sanity checks by using explicit extra data, or through allowing the data enough file space (data member size) to be out of valid range and thus able to be checked merely by looking at the asset in memory after loading.
QUOTE: "runtime performance is valued very highly while maximal compression is merely a nice thing to have"
yes, but we're still having issues with our media being slower than decompression algorithms, especially with situations where programmers and data desginers have not considered the footprint of their data layouts and are unnecessarily creating assets that have redundant storage capacity.
I must assume that there are very few people who consider the importance of bandwidth outside of those working on platforms that are strictly bound by their data throughput rate or storage capacity.