Moving sprites based on Delta time - consistent movement across all devices with different resolutions

Question

This is the formula I am currently using to move my sprites across the screen:

Examples below only deal with X coordinates to keeps things as short as possible.

Initial variable declarations:

float frames_per_second = 30;         //Set this to target frames per second, 30 for this example.
float dt = 1/frames_per_second;       //Delta
float spriteXGrid;                    //Sprite's position on a grid (grid can be any explicit value, I use something simple like 800 x 600)                             
float spriteXScreen;                  //Sprite's actual final position in screen coordinates                             
float spriteXTime=5;                  //Time variable.  This is in seconds and is the amount of time the sprite should take to traverse the screen
float spriteXVel=1/spriteXTime;       //Velocity value used in conjunction with time value to calculate new position    

To set my sprite's initial position I simply do this:

spriteXGrid = (pos/800);           //Where pos is the position on the grid (0-800) and 800 is the grid size that I chose to work with.
spriteXScreen=spriteXGrid*width;  //To convert to actual screen coordinates - where width is the actual width of the device currently running on. 

Then to move my sprite, I do this:

spriteXGrid = spriteXGrid + (spriteXVel * dt);  //Update sprite's position on the grid              
spriteXScreen=spriteXGrid*width;                //And convert to screen coordinates (again, width is the screen width of the current device)

Then I just use the spriteXScreen variable to plot the sprite, something like:

sprite.drawSprite(spriteXScreen,0);            //this is from a custom class I wrote that takes in sprite's x and y coordinate and draws it there.

My question is, is there an easier way I can do this?! It's a nightmare to manage when it comes to collision detection etc.... because, you have 2 different coordinates, the 'screen' one (which I would describe as 'superficial'), and the 'grid' one which is needed for all the good stuff, and is a nightmare to actually work out and work with.

is there anyway I can just do something like:

spriteXScreen+='some value'

Which would allow my sprite to move across the screen in the same amount of time on all devices?

(I mean I can't just say move it by 1 pixel, because if I move 400 pixels in say 5 seconds on a 400 pixel wide screen, the sprite will have passed the whole screen in those 5 seconds, but on an 800 pixel wide screen it would have only passed halfway in the same amount of time).

The whole business of have a 'grid' coordinate and having to convert it to a 'screen' coordinate is extremely irritating and I'm wondering if I'm doing this all wrong....?

Suggestions and solutions would be very welcome

Answer 1

You are essentially creating 3 coordinate systems when you only need 2. The coordinate system for your grid is 0 to 800. Your "real" space is a normalized position from 0 to 1.0. And your "screen" space is measured from 0 to whatever your pixel width is.

You will always need to convert between some kind of world coordinate system and screen space in order to properly position your sprites.

The units for the math you are doing are basically:

grid     real     screen      screen
----  *  ----  *  ----     =  ----
 1       grid     real         1

or  ( objectX / 1 ) * ( 1 / 800 ) * ( width / 1 )

If you calculate the ratio between your screen resolution and your grid space, then you can multiply by that ratio to know where to render your sprite, without involving your "real" coordinates.

grid    screen     screen    
---- *  ----    =  ----  
 1      grid        1

or ( objectX / 1 ) * ( width / 800 )  == spriteXScreen (in pixels)
or objectX * ( width / 800 )

You can write all your game logic to only deal with grid space coordinates, and then when you're ready to draw everything, loop through all your objects, multiply x and y by the ratios you've computed, and draw at those pixels.

You will need to specify your velocity in terms of "grid" units instead of "real" units, in this case. But it should simplify things somewhat for you.