Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I am working on an android game with a top down style view similar to the original GTA's or a scrolling version of Legend of Zelda.

I have recently begun designing some prototype levels for the game which vary between a corridor style dungeon similar to diablo or an open area with obstacles similar to Zelda. My question is would it be better to have one large background image and draw it once or a relatively small one (size of or less than the view) and draw it multiple times.

My concerns are the memory required to load/store a large background image vs the performance boost of only drawing one image.

Any input would be appreciated.

share|improve this question
add comment

2 Answers

up vote 0 down vote accepted

I would also go for loading multiple smaller images in the next way: split your image (5000 x 5000px) into files of 100x100 px for example,

lets say when the game starts the player is in the middle of the map (x: 2500, y:2500) first thing you do is load the tile that matches these coordinates, next you also load the 8 tiles next to the center tile so you now have loaded 9 tiles in a 3x3 layout (the player is on the center tile) When a player is moving to the tile above, you just have to load the 3 next tiles the player could reach when he's still travelling up. The 3 bottom tiles can be unloaded since the player is never going to be able to reach these at the moment.

Is the player moving to the right, you can load these 3 tiles (aligned vertically) and unload the left 3 tiles.

This way, only the tiles the player can reach have to be loaded. I don't know what resolution of device you are targeting, but if you use 100x100 px the entire loaded field has a resolution of 300x300, so you might want to use bigger tiles, or just load a few more

share|improve this answer
    
Yes this was the approach I am currently using, although atm I am using a very simple 'scrolling background' approach where the same bg image is just being redrawn at its edges. There are not clearly defined 'tiles' like in Zelda. Still, I think this is the way to go for my game. Thanks. –  Justin Jan 22 '12 at 5:26
add comment

I'd go with drawing smaller ones.

Just one large image drawbacks:

You might draw something that you're not even seeing.

Ok, you can cut the image and just draw the part you're seeing, but that may be hard to code, and might also be costly to do(depends in your implementation). If you go with smaller ones, just test the object if its position is inside your screen.

It will get a lot of memory.

Pretend you have a 512x512 map and this map is just 256 32x32 images. If you load this entire map as a 8bpp bitmap, you'll end using 2.097.152 bytes, that is, 2MB.

Well, if you just load a 8bpp 32x32 image you will end up with 8.192 bytes loaded, that is, 8KB. But of course, you have to have the positions stored somewhere, so pretend this is the object structure:

struct object { sprite* image; // 4bytes int x; // 4 bytes int y; // 4 bytes }

that is, 12 bytes on the structure. As you have 256 objects, 3.072 bytes, that is 3KB.

summing everything, 11KB. Do you prefer to waste 2MB or 11KB? And I'm guessing low, try to use 32bpp images and the difference gets a lot higher! (If i made any wrong calculation, some one can edit please?)

Collision will be a mess.

You'll have to have one file for each level telling were is collidable, where isn't. This can also get a great memory. Without saying that you'll have to calculate it for every level, it will be a pain.

For our friends smaller images, you just define which sprites are collidable and check the character against them.

Harder to edit.

Lets say you shipped your game. And oh, there's a object that is in the wrong place on the level X, you'll have to edit the image, the collision file, and update the two big files for the people who already got your game.

in the counterpart, you would just edit the x and the y of your object, and update the smaller file to the people.

There are a lot of more drawbacks, I just cited some.

If you're looking for a way to do with smaller images, here is some guidance:

Make a file to store your types. It could be something simple, if you dont understand binary structures, try to look at google.

struct SpriteTypeIndex
{
    byte typecount;
    SpriteType types[typecount];
}
struct SpriteType
{
    byte id;
    char filename[32]; //the image name
}

To store the objects in a file, you could use some structure like this:

struct object
{
    byte type; //The id of the SpriteType
    char name[8]; //just to identify it (optional)
    int x;
    int y;
}

Easy huh? Ah, these assume you're not making more than 256 sprite types, and your image names have all less than 32 characters.

Hope it helps you (:

share|improve this answer
    
Ideally, you would use a tiled approach (eg. small images), but pack the images in a big image (sprite-sheet) for batch-drawing. –  bummzack Jan 15 '12 at 14:01
    
The game already uses many smaller images which get drawn over the background much as you described. I was asking more so about the pros/cons of having a large background image vs a smaller repeating one. That being said, the points you make are still valid. –  Justin Jan 22 '12 at 5:24
    
Ah, understood. But if you think, yeah, it stills valid (: –  Gustavo Maciel Jan 22 '12 at 5:37
add comment

Your Answer

 
discard

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.