Take the 2-minute tour ×

When writing games, I am aware that images take up a lot of space. If one has a large graphical game, they don't want problems with memory, or to give players the message "Go buy a better computer to run this game". However, loading up images everytime one needs an image and discarding it is very slow. So if a programmer has a large graphical game, how can they draw many images without sacrificing performance/memory?

share|improve this question

2 Answers 2

up vote 3 down vote accepted

1.Use scaling; make images smaller, but still having enough to get the character around. Scaling an 80x80 in to a 60x60 saves a lot of space for five hundred images, seeing as each one will be 1/4th smaller, taking up virtually 1/4th of the space.

2.Use better compressed image formats; a BMP will save more time than JPEG, and is smaller.

3.Remove images that are no longer in a visible portion of the screen to save memory. In the 8 and 16-bit world this was mandatory, as having such tight memory and slow CPUs, on top of bank switching, made the process daunting to imagine for a C/Windows programmer these days. To recover the removed image, save where it was to an 8-bit byte container, and re-load it based on these coordinates. You can't lose with this method.

4.Don't load up too many images at once; I know this one is tough to comprehend, but tons of images at once isn't absolutely vital. In fact, it's not vital at all for a beginner program (which you seem to be, no offensive if you aren't) and cutting out a few extra images here and there make a stretch, but the saved memory and speed will thank you. Working with 3-D models, lots of large data files, and rendering is memory tougher. When you get there then it's time to work smarter, but as for 2-D games like a platformer, RPG, etc., my last three prior paragraphs should do the justice for you.

share|improve this answer
1) If something is 1/4th smaller, it will take up 1/4th less space, or 3/4th of the original space. 2) BMPs can be uncompressed; also, in general there's a tradeoff between storage size and processing time (ie a table of contents in a book takes an extra page). –  Clockwork-Muse Jun 7 '13 at 20:54
On the other hand, a 256x256 RGBA image is only 256kb; in an age when memory is measured in gigabytes one has to maintain a sense of proportion - is this something that's even worth worrying about in advance of anything else? –  Darth Melkor Jun 8 '13 at 1:47
@Clockwork-Muse - correct on BMPS but not with respect to math IFF we're discussing 2D images - reducing the size of the X and Y dimensions by 1/4 will reduce the image pixel count to 56% of the original size :-) –  Mark Mullin Jun 8 '13 at 12:49
If you're going to go for image compression DXT1 and DXT5 tend to be the best options, as they will stay compressed in GPU memory and often improve rendering performance too. –  Adam Jun 8 '13 at 12:53

This probably isn't an issue you need to worry about. A typical image can be measured in KB, and few computers will choke if you're using less than 1 GB of memory, or even 2 GB. This leaves you space for hundreds or thousands of different images.

The first thing to ruin your performance will be rendering things to the screen, and until you already have something programmed and you're seeing it's too slow, that's not worth worrying about either.

I know this because it's one of my curses as well: One of the best ways to get nothing done is to worry about problems that haven't happened yet. Of course you should worry about some things (USE VERSION CONTROL / BACKUPS) but I think my intent is clear.

share|improve this answer
"One of the best ways to get nothing done is to worry about problems that haven't happened yet." Best line ever. +1 –  UnderscoreZero Jun 7 '13 at 20:13
+1 to both this answer and the comment. Worrying about memory usage without even measuring how much you're currently using and how much your target hardware can reasonably take doesn't seem like a wise approach under any concievable set of circumstances. –  Darth Melkor Jun 8 '13 at 1:43

Your Answer


