Sanity checks vs file sizes

Question

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?

EDIT

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.

EDIT

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.

Answer 1

I've done two things for release builds in the past, I've never added extra data.

First is all the data is described by a manifest that has a CRC or MD5 and at program startup the local files are checked against their expected hash. A patching system will do this for you, if you use one, so it's almost automatic.

Second is not to use asserts (which disappear in release modes) but simple range checks, for example does a bitmap have >2048 width, which will catch malformed data.

Josh Petrie's remarks are right on. Since we're talking about Games here, runtime performance is valued very highly while maximal compression is merely a nice thing to have.

Preparing data offline to unpack directly into C structures on a target platform is very fast technique that's been used for decades. While I'm sure it could be perverted into an attack vector it's far more likely that the EXE itself is violated and not the data and so efforts to failsafe the data are wasted and better spent elsewhere.

Answer 2

I wouldn't bother sanity checking or asserting against the size of individual assets. I would have a report or something that could tell me the total size of my final asset bundle, and if that exceeded something I was comfortable with I might look into using a more aggressive compression routine or something, but that would be an entirely manual check unless I was working on a platform with very strict hardware limitations (and thus I had very strict memory budgets).

Regardless this would be something done at asset compile time, and would be optional, otherwise one might restrict the ability for end-users to mod one's game, which is usually a negative.

Remember that exceeding the predefined bounds of your asset volume may have just meant you mis-estimated your asset volume in your initial planning, not that anything has, per se, gone "wrong."

I also wouldn't worry too much about this because of most of the time compressing the data "well enough" or not is largely out of our hands -- sure, we can elect to use data formats that compress better under certain algorithms, but we shouldn't be doing that at the cost of quality of the in-game asset as a general rule, and unless we're writing our own compression there's only so far we can get things compressed. Unless I've misunderstood you, I sort of feel like this issue is overly hand-wringy.

Answer 3

It is telling that big games have not tried too hard to keep the file formats slim. Things like MD2 and MD5 would compress much much better and be much smaller if they weren't text formats, if they were triangle strips and fans and such, and other simple tricks. Its as if the team were deliberately not concerning themselves with data size.

On the other hand, compressing the textures and the cut scenes seems to be worth much more effort.

I would always favour robustness over size. It worries me when I see binary formats that are designed to fit a given C struct layout. That will really bite you later. And its where bugs can hide and, later, an attack vector. Best to go with nice formats that you read in and validate each and every load. Triply so if you start using user generated content or p2p.

I'm just a hobbyist who has looked at file sizes for the current spins on Glest and my own efforts. I see that Charles Bloom - someone who really made an impact on compression in the 1990s - then went to Oddworld. One wonders why compression wasn't a talked-up part of what he did there - you can draw the conclusion that if the top dog in the data compression field goes and does graphics engines for game company, rather than data compression, that data compression is not where its at. He probably cares more about load times in the gaming context? His blog is brilliant.

Compression is about data modeling. It is legal for all vertices to be in any random point in 3D space, but then your model would look like a porcupine. In real life, the actual position of a vertex - if you know those it is attached to - is fairly constrained and predictable. If you google "compress mesh" and such you find lots of academic papers, but I don't know anything mainstream.

I've played with making predictors. Its not so different from LOD makers really. It didn't seem to have much application - would people adopt a mesh format that was half as small again as existing ones LZMA2ed models?

Answer 4

Rule 1) Only handle what you are designing for.

If you are developing a game where assets are being made by someone Other than you, then generally you will want to validate them. If they are only being made by you then it might be overkill to do upfront.

Secondly.. If you are running some sort of compression on your assets prior to use (I prefer in-memory expansion of pre-loaded data chunks because its where ya get the nice few second load times from :D), then you can have whatever it is that is compression or otherwise compiling your assets do the checks as well.

Remember Rule #1 ;) Too often people (read, programmers) try to handle every situation under the sun, because that is what we are taught.. All your application ever needs to handle is what it will run into.

As for a way to validate an overall asset set to make sure people havent screwed with it. Generate a hash value (Sha1, MD5, both?) and store it internal to your application. Then if the has value of your assets does not match what is stored, they are not running what you gave them.