# backgrounds in scrolling games

This topic is 4612 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

How would you handle large backgrounds in tile based games? For example take a look at the classic, super mario game http://www.retroarcade.com/console/nintendo/supmario.gif Is the background, clouds and bushes, made of individual tiles or is it one big image? I'm either thinking of loading the image file which is very big and seems impractical or splitting the image into at least 6 sections but I don't know if this would be very fast. What do you think?

##### Share on other sites
You can safely treat the backdrop as its own image, rather than the individual clouds and trees that compose it. Your idea of dividing the backdrop into sections is sound. It's what I would do; it's what I've done.

As an aside, due to memory constraints, the original SMB probably used the technique known as "sprite multiplexing" to display the background.

##### Share on other sites
I should add that if the objects that compose your backdrop are to be animated, you might consider using a level editor to place those within the level map and display them seperately from the backdrop in your game.

Also, in SMB, I don't think the trees are rendered along with the clouds. The placement of the trees seems organic.

##### Share on other sites
I would say it is most likely as in any other sound game.

Blue background (simple clear), clouds are painted and the trees are painted and the level and stuff is painted. (of course I'm not 100% sure, but with a bit of logic that is the only way, and really, the way it should be done)

Having them put together doesn't seem very clever at all if you ask me, and would most likely just make things look more static and provide more problems. (of course if you are having a more advanced background it would be applicable to load the background image, but not SMB or such, if you have simple and in a way repetative backgrounds, then don't use a background image, either way, clouds and such would be best drawn apart from the background as they could then move independently of the background).

##### Share on other sites
Ok, then say you have a very large map (16384x16384) made with 32x32 tiles. WOuld you still load all the tiles at once or dynamically allocate/free memory depending where the player is located? I'm just thinking if loading and freeing objects from memory wouldn't be too slow.

##### Share on other sites
At 16384x16384 even if each tile is represented with a modest 1 byte of data, you are talking 270MB just to store the tiles. In this case you would definately want to set up some sort of paging system for your map. You could break the map up into smaller sections and then page the sections in and out of memory as the player moves through the world:
|---|---|---|---|---|---||   |   |   |   |   |   | ...|---|---|---|---|---|---||   |   | ? | ? | ? |   ||---|---|---|---|---|---||   |   | ? | p | ? |   ||---|---|---|---|---|---||   |   | ? | ? | ? |   ||---|---|---|---|---|---||   |   |   |   |   |   ||---|---|---|---|---|---||   |   |   |   |   |   ||---|---|---|---|---|---|  .  .  .

Say your player is in the area marked 'p'. This area might contain a number of tiles representing several visible "screens" of the world. For instance, let's just say that an area is 200x200 tiles (about 10x10 "screens" if you are running at a resolution of 640x480 with 32x32 pixel tiles). 200x200 tiles is about 40KB of tile data (assuming 1 byte tiles). This is a very reasonable amount to have in memory. The areas marked with ? are the parts of the map that are being loaded into memory in the background (in a separate thread). You only load those areas because those are the only potential areas that the player could move to. The rest of map is not in memory at all because it is not possible for the player to exist in them before moving through the other areas (assuming warping is not allowed of course). As the player enters a new area, that new area will have had time to be loaded into memory while the player was traversing the previous area. The areas surrounding the new area will immediately begin being streamed into memory while the areas not surrounding the new area are unloaded from memory.
Here is what happens when your player moves north until he reaches the next section:
|---|---|---|---|---|---||   |   | ? | ? | ? |   | ...|---|---|---|---|---|---||   |   | x | p | x |   ||---|---|---|---|---|---||   |   | x | x | x |   ||---|---|---|---|---|---||   |   | ^ | ^ | ^ |   ||---|---|---|---|---|---||   |   |   |   |   |   ||---|---|---|---|---|---||   |   |   |   |   |   ||---|---|---|---|---|---|  .  .  .

The areas marked x are already paged into memory, the area's marked ? are just starting to be paged in, and the areas marked ^ are being paged out of memory.
As you can see, at most you will only ever have 360KB (9 sections x 40KB/section) of tile data loaded into memory at any given moment. Compare that to 270MB for loading the whole thing in. Obviously, you have to decide what is a reasonable size for each section, but hopefully you get the general idea.

[Edited by - CodeMunkie on July 5, 2005 6:49:03 PM]

##### Share on other sites
Quote:
 Original post by subfloodOk, then say you have a very large map (16384x16384) made with 32x32 tiles. WOuld you still load all the tiles at once or dynamically allocate/free memory depending where the player is located? I'm just thinking if loading and freeing objects from memory wouldn't be too slow.

It certainly wouldn't prove to be any problem at all, as today, common games use this technique and they load huuge textures.

I would even say, that having a separate thread to do the loading would be needless as it should be next to instant on any computer worth mentioning.

But, as CodeMunkie point out, make sure you split the maps into sections, and then load them dynamically too when they are getting close to beeing needed, or perhaps a little farther away (if you would like to have enemies beeing able to move while outside the screen too, and such). That is if you are working with RPG top-down views, not supermario games, supermario clones should manage fine without any such sections.

##### Share on other sites
Just for fun: The original Nintendo had specialized hardware to blit 8x8 tiles to the screen. Typically, Nintendo games didn't map out the backgrounds for an entire map, but had several smaller miniature maps (for legend of zelda, I know, they where each the height of the screen and two tiles wide, for example). Then you need a much smaller map of these mini-maps. You could have as few as thirty repeating over and over again for an entire game.