Asset Compression - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Designer's Studio (/forum-6.html)
+--- Thread: Asset Compression (/thread-7608.html)
Asset Compression - doucettecd - Aug 16, 2002 09:51 PM
I'm working on a RealBasic uDevGame entry that will involve a modest collection of graphic and audio assets - enough to make the game playable and easy on the eyes, basically. Since I hope someday to make games that have more content, though, I'm wondering if anyone can give me some pointers on compressing/encrypting assets.
Are there programs/plugins out there that take standard format graphics/audio files and somehow compress or combine them? Or is there a not-too-complicated algorithm I can use to do it myself? Ideally the format would be something inaccessible to the average downloader as well, as a way of protecting the assets from getting ripped, but that's icing on the cake.
I'm sure the problem is much more complicated than I've put it, but as it's something that must come up for every mid- to large-sized game at some point, I thought there might be some generally accepted tricks I could learn.
- Chris Doucette
Asset Compression - Josh - Aug 27, 2002 12:25 PM
Hmm... well, resource files and bundles can hold your graphics and sounds, though I am not sure that is the answer you were looking for
Asset Compression - aarku - Aug 27, 2002 01:01 PM
First off I would recommend always keeping original uncompressed versions of all your media files. This will save headaches later when you need to recompress them or switch them.
I don't know much about RealBasic, but normally I like resource forks for holding assets. The resource fork is in my opinion one of the mac os's best features. I think it is _much_ better to have say one or two files that hold all your data than say, 2000. In my opinion things with hoardes of files are just plain sloppy and slow: have you ever tried copying 1 file of 10 megabytes versus 1000 files of 10.24 kilobytes? Less files is better.
Now as far as compression for graphics goes: whichever format gives you the smallest sizes without sacrificing too much quality where you notice it while you are in-game. I've had a hard time doing this balancing act myself. My game uses a bunch of linked pictures which I store and draw as run-length-encoded (RLE) sprites which are compressed losslessly. I have settled on this after trying: jpeg, png, and pict to varying degrees of sucess. A format like png was runner-up, but in my situation loading (especially loading) and drawing RLE sprites was faster.
Sound compression: I don't know. I had speed troubles before with compressing/decompressing 'snd ' resources, but I know it's possible to do well. I just store my sounds uncompressed 22.050 khz, 16 bit and let Stuffit try and shrink them down when it comes time to package up the installer.
Encrypting your game assets: I'd just encrypt standard files with a key using something like TEA (find link on idevgames' links page). And then decrypt the files as you load them. I've had good results by doing this.