I'm trying to find the answer to a question that I've had for a long time, but am having trouble finding it! I hope someone can help :-)

I'm trying to find information on how to scale sprite velocity / movement / co-ordinates.

What I mean by this is how do I get a sprite to move at the same speed relative to the screen size / DPI so that it takes the same amount of real-time to get from one side of the screen to the other?

All of the posts pertaining to sprite scaling that I can find on the various forums relate to the size of the sprite, but this part of it I'm OK with so far, it's just that when I move a sprite, it kind of gets there at different speed depending on the dpi / resolution of the device. I hope I'm making sense.

This is the code I have so far, instead of using explicit amounts, like 1, I'm using something like the following:

platSpeedFloat= (1 * (dpi/160)); //Use '1' so on an MDPI screen, the sprite will move by 1 physical pixel

Then basically what I'm doing is something like this: (all varialble previously declared)

platSpeedSave+=platSpeedFloat; //Add the platSpeedFloat value to the current platSpeedSave value

platSpeed=(int) platSpeedSave; //Cast to int so it can be checked in the following statement

if (platSpeed==platSpeedSave) //Check the casted int value to float value stored previoiusly

{floorY=floorY-platSpeed; //If they match then change the Y value

platSpeedSave=0;} //Reset

Would be grateful if someone could assists - hope I'm making sense. The above doesn't seems to work the sprite moves 'faster' on lower DPI screens.


  • 1
    \$\begingroup\$ With lower dpi your platSpeedFloat gets smaller and smaller. Im not sur on Java rounding, but I guess that casting that to an int will result in 0 whenever the DPI is lower than 80. This means that platSpeed is always equal to platSpeedSave. \$\endgroup\$ Oct 24, 2012 at 23:30
  • \$\begingroup\$ Hi Jonathan - thanks for the comment - you are correct, I believe any DPI lower than 160 will result in a number < 1 which will be cast initially as 0, however I've also tried this adding a 0.5f to the float value before it's cast (as they say one should do in Android) - but it makes no difference - they still move at different speeds. (The platSpeedSave value contains the accumulating values and isn't reset until a match is made, so it shoud at some point be larger than 0 even without adding the 0.5f if I've got that right!!) Thanks again for any advise. \$\endgroup\$ Oct 25, 2012 at 0:12
  • \$\begingroup\$ One more, thing, am I missing something? I ask because all the Android game tutorials / examples that I keep seeing use explicit values for velocity (x=x+1 for example) - this doesn't work surely, as on lower res screens, it would appear to move much faster?! Have I got this completely wrong?! Thanks! \$\endgroup\$ Oct 25, 2012 at 1:02

1 Answer 1


You want to move the ball from side to side of the screen in the same amount of time. You can convert the screen resolution to [0.0, 1.0] (sometimes called screen coordinates to world coordinates conversion). Then you calculate the speed using that,

E.g: with one coordinates, you should expand it to use X and Y. You want the ball move from left to right on 10 second so:

vel = 1.0 / 10
pos = pos + vel * dt
pos_in_screen = pos * SCREEN_SIZE

And work with that.

Other thing to have in mind, your shorter screen size should be [0.0, 1.0] but the other dimension will be [0.0, 1.X] depending on the screen ratio.


dt: delta time in seconds, time between frames. E.g: with 30fps, dt=1/30

Example with X coords. If your sprite start in pos 0 (left side of the screen), with a screen with 10x10 pixels, the update should be:

vel = 1.0 / 10 (it could remains the same between frames)
pos = pos + vel * dt = 0 + (1.0/10) * (1.0/30) = 1/300
pos_in_screen = pos * SCREEN_SIZE = 1/300 * 10 = 1/30

With a screen of 100x100 you only change the last sentence:

pos_in_screen = pos * SCREEN_SIZE = 1/300 * 100 = 1/3
  • \$\begingroup\$ Hi Zhen, yes this is exactly what I was after doing (moving the sprite in the same amount of real time) Thank you. What is the value dt? I've read through a few times and I'm still not understanding it fully :-( Is there anywhere that you know of where I can read in detail how this conversion works? I've tried Googling but all the 'world to screen' explanations that I've found seem to relate to 3D graphics and not 2D - any further help you could offer would really be appreciated - thanks again! \$\endgroup\$ Oct 25, 2012 at 14:22
  • \$\begingroup\$ @user22241 The value dt is delta time, the time between last frame and current one. This is one to learn about it gafferongames.com/game-physics/fix-your-timestep \$\endgroup\$
    – Zhen
    Oct 25, 2012 at 18:35
  • \$\begingroup\$ @user22241 in 2D is more or less the same that 3D, but simplest. You can forget about matrix transformation and do the math directly. \$\endgroup\$
    – Zhen
    Oct 25, 2012 at 18:38
  • \$\begingroup\$ Hi, I've already implemented code so the game runs at 30fps (if the device is faster it should slow it to 30fps and if it's too slow it will skip frames) Is this different to what you are talking about? My app still runs at different speeds on different screen res - well, more accurately, when sprites move, they don't move at the same speed relative to the screen size. Ex, if theoretically, we had a screen of 10 x 10 and a screen of 100 x 100, if the sprite moved my 1 pixel each time, then after 10 moves, it would be across the first screen but only 1/10 the way across the latter? Thanks. \$\endgroup\$ Oct 25, 2012 at 21:21
  • \$\begingroup\$ @user22241 I update the answer with an example \$\endgroup\$
    – Zhen
    Oct 26, 2012 at 8:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .