Loading assets

Flattr this!

Right, I’ve been working on loading assets for a while now. Preloading (caching) assets was very easy to do – the problem was that the original system for loading assets had flaws in it.

It relied on using the outdated packingslips.dat archive for figuring out where assets were located, which was causing issues with files that had complicated paths.

Therefore I’m now working on a tool, Mr. Shipper, that can generate XML files for the assets that are currently being used, as well as corresponding C# files with structures containing the IDs for these assets.

The process was going swimmingly, but then we were once again stumped by Maxis’ unique development practices. We assumed that since an unsigned integer can hold 4,294,967,295 unique values, it would be enough to map each asset in the game. And it would! The game contains a little over 35,000 assets.

That is but a few percent of the total amount of assets one would need to fill a uint’s total range. But somehow, the geniouses at Maxis decided to reuse FileIDs for different files, so that a FileID has to be combined with its TypeID (which is also an unsigned integer) to be unique. That means that to map an asset to a unique ID in the game, you need an unsigned long, which is 8 bytes rather than 4. In other words, each ID for each asset takes twice as much memory for no particular reason at all!