Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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

What is the best general approach to implement scrolling for a 2D tile based game?

I need to scroll the map with a constant speed, lets say 2 pixels every frame (like in a top down shooter).

The tiles are 32x32 and the map is quite big, lets say 10 x 300.

There are 2 layers: - first is the background layer - second is the forgeground layer with obstacles and enemies

The target plattform is android and I want to use OpenGl.

What is best practice?

a) Draw only the visible Screen all the time (every frame) b) Load complete map into memory and just move the camera

Is there a difference in performance and determining collision etc.?

Thanks for any help!

share|improve this question
Sounds like you want parallax scrolling: – thedaian Jul 27 '11 at 15:28

I can't answer specifically for Andriod as I have never done anything for it, but generally you will want to only draw the portion of the map that is visible. It requires much less memory to do it, and shouldn't mess with collision at all. In fact, you will only need to check for collision on the objects you are drawing rather than the entire map.

If you want to have the bottom layer move at a separate speed than the top, the technique is called Parallax Scrolling.

share|improve this answer
Yeah, actually my question is platform independent. Thanks for your answer. Allways draw only what you need to see. To get a smooth scrolling I guess you should generate also some offset (e.g. one additional row of tiles) - right? – Alois Schweitzer Jul 28 '11 at 7:04
Yes, I always draw an additional row/col on each side of the screen. – Joe Jul 28 '11 at 16:18

You might want to think about using delta time, that's the time taken from 1 frame to the other.

When you implemented it, it'll return you a float/double: 1 if it has taken 1 second to draw the next frame. It'll return around: 0.0166666666666667 for a nice fps of 60.

This way you can multiply your moving speed with the delta time, meaning your object will move the "moving speed" you gave it per second, but then nicely divided over all frames.

O yeah before I forget if the object moves in (example in 2d) both ways (X and Y) use Sinus and Co-sinus to calculate the real X and Y value it moves. (also in 3D).

Save it all to an Vector3 or just in some self made floats/doubles and let all object use it as a relative point, like: my position is? parent.position + my.position = my real position.

For your other questions: I think drawing separated images will be my goal, both ways will take in around the same amount of memory.

Hope this will help you further. and good luck!

share|improve this answer
-1 This answer is completely unrelated to the question. – doppelgreener Aug 21 '11 at 1:51
Also it's sine and cosine. The sinus is an organ in your head. – doppelgreener Aug 21 '11 at 2:01
Little translation fault... here in the Netherlands we call it "Sinus" (i is pronounced like the y from "candy") and it is related, he asked how to smooth it out. if he would used what he described "I need to scroll the map with a constant speed, lets say 2 pixels every frame (like in a top down shooter)." it would mean he would scroll a lot faster than meant if the fps is around 200 or so. FPS 60: 60 * 2 = 120 pixels per second, FPS 200: 200 * 2 = 400 pixels per second. I would definitely know what I would use. – Ylon Schaeffer Aug 22 '11 at 0:17

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.