Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been doing some research and I found that the game RollerCoaster Tycoon uses .dat files to store all the animations/images for each ride. Basically we're talking hundreds of images (per ride even), that are separate .bmp files inside this .dat file. This goes against the preaching of always using spritesheets... or maybe I misunderstand how the .dat file is being used? Using spritesheets are nice when the images and animation frames are all the same size, but when they vary so much (like varying ride sizes), it would be nice to use individual images. From my understanding, there's limits on image counts, and generally bad things when using tons of individual images... but ancient RoolerCoaster Tycoon seems to do just that with its .dat files.

What am I missing? What is the best way to store a massive amount of images?

share|improve this question
I imagine they have some optimization in their engine that would cause many different images within a .dat file to run more efficiently than a large .bmp file. – UnderscoreZero Aug 16 '13 at 15:39
up vote 2 down vote accepted

There's an overarching theme to this question because there's more to it than just storing images separately vs. packed in a custom file format. I'll go through this theme, then I'll circle back to spritesheets.

On older systems, the ones that Roller Coaster Tycoon was made for, reducing hard drive latency was one of the big things that developers had to watch out for. Disks were relatively slow. It's still the case, and today the canonical term is "cooked". The assets are said to be "cooked" when they are packed and compressed for a specific processor and storage medium (think PC, PS3, Xbox, and so on).

The advantage of doing this is to reduce the seek-time of hard drive by making the assets as close to each other on the disk as possible. This is achieved by placing them all in one file. There's often a process that's involved in figuring out how often one asset is accessed relative to another, and the assets are placed in this file accordingly.

Back to the question, I haven't taken a look at the RCT .dat file, but it sounds like it takes several .bmp files and places them inside of one .dat file. This is essentially a spritesheet, just that instead of having all the sprites inside of one .bmp, all the .bmp files are inside of one .dat.

Most games employ some kind of a compression technique to store a lot of spritesheets into reasonable sizes. There's a tradeoff between how good the sprites themselves look (ie. do you use 256-colors lookup table, or do you go with a full 32-bit RGBA sprite), and the compression technique used across the entire file where your individual spritesheets are packed into (.zip, .7z, .mpq, etc...)

share|improve this answer
Thanks for the answer! So what I could do is extract all the images from a .dat file and pack them into a Texture2D? (I'm using Monogame). That wouldn't cause any optimization problems with the GPU, right? That's essentially like a spritesheet like you said. Forgive me for any misunderstandings, I'm still learning. – Joe Aug 16 '13 at 16:58
No - it won't cause any issues. What you are describing is commonly called a Texture Atlas, often used with fonts and sprites. You can also fit more sprites inside of a texture atlas than you can inside of a sprite sheet (see… for more details about this, and for a hardcore atlas packing algorithm). – Jovan Aug 16 '13 at 17:07
Fantastic! This is exactly what I need, thank you. :-) – Joe Aug 16 '13 at 17:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.