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'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.

Thanks

share|improve this question
1  
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. –  Jonathan Connell Oct 24 '12 at 23:30
    
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. –  user22241 Oct 25 '12 at 0:12
    
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! –  user22241 Oct 25 '12 at 1:02
add comment

1 Answer 1

up vote 1 down vote accepted

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.

UPDATE:

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
share|improve this answer
    
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! –  user22241 Oct 25 '12 at 14:22
    
@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 –  Zhen Oct 25 '12 at 18:35
    
@user22241 in 2D is more or less the same that 3D, but simplest. You can forget about matrix transformation and do the math directly. –  Zhen Oct 25 '12 at 18:38
    
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. –  user22241 Oct 25 '12 at 21:21
    
@user22241 I update the answer with an example –  Zhen Oct 26 '12 at 8:47
show 5 more comments

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.