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'm a newbie. I'm trying to develop a 2d game (top-down view). I would like to load a standard background, a textured ground... My "world" is big, for example 3000px X 3000px. I think it is not a good idea to load a 3000px x 3000px image and move it... So, how is the best practice ? To load a single small image (64x64) and repeat it for N times ? If yes, ok, but how i can manage the "background" movement ? Thanks Bye!

share|improve this question
More specifics on the nature of your game could be helpful. For example, depending on theme and style either a single, detailed image could be fitting or a tiled one would. Heck, if it's an abstract game like geometry wars, a procedural background might work best. – Asmor Nov 3 '10 at 19:48

Use a Tiling Algorithm. Unless each pixel of your 36MB map is unique, you can break your map up into tiles. See the RPGMaker to get a feel for how it's done.

Then, you'll just need several small images, and a grid describing the map in 32x32 chunks. During a frameDraw, just draw the portion of the grid relating to what the screen around the character shows. It keeps memory down, and performance up.

share|improve this answer
Why do you say the tiles should to be 32x32? – AttackingHobo Dec 25 '10 at 5:11
@Hobo, You don't have to. It's just what a majority of the art that I find has been done in. It gives a 60x33 "tile" resolution on HD monitors, and a 40x32 resolution on a traditional monitor. – Stephen Furlani Dec 28 '10 at 13:34

It depends on your target display size.

On one end of the scale there's the "have everything on a single 3000x3000 framebuffer" approach. This is probably the fastest method (one single render call) but a framebuffer that big can cause problems.

On the other end of the scale there's the "draw every single tile individually" approach. This is memory-conservative, but requires a lot of render calls.

To me, the sweet spot is bundling the tiles on chunks that take rougthly half the size of the screen. The number of render calls is at worse 9, and the hardware should cope well with a texture size that is half the screen.

This way, for a PC screen with 1024x768 pixels, you will probably be ok with 512x512 textures, while for a mobile device with a 300x256 pixels, 256x128 should be ok.

share|improve this answer

I'd try to render images at the same size as the source image, so if that is truely the max size (and also the size of your .png or whatever) I'd render it as-is and be done with it (unless I saw noticable framerate drop by doing that).

If you do see performance problems, or you anticipate much larger imagery, you'd need to come up with a tiling scheme, which will determine which tiles of your map need to be on the screen and render them. One way to do it (maybe not the best) is to use a Tile class, then have an array[x,y] of tiles. Each Tile knows its realitive position on the screen and can react to user-input in order to move on the correct axis.

share|improve this answer

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.