# Speed from delta time not correct

My game object isn't moving in correct speed calculated from deltaTime bellow. It should reach half of the screen in one second, on any device.

Devices:

• tablet A7600-F - deltaTime = 0.03355443; (res. 720x1280)
• Xperia Z3 Compact - deltaTime = 0.13421772; (res. 720x1280)

Calculation:

calc = (screenWidth / 2) * deltaTime. //I have app in landscape mode
speed = Math.round(calc);


speed on tablet - 21px per update; speed on xperia - 86px per update;

You can see these results are very different (actualy it should be something about 8px - 20px). Game object is then extreme fast on Xperia (on tablet it's just a bit faster - speed is more than half of the screen per second).

What am I missing?

• Have you tried not rounding the speed and instead rounding the position only when drawing it? Rounding the speed like you do means that the tablet only covers 625 pixels after one second (provided that all delta times are the same). – bornander Dec 6 '15 at 18:37
• It's not necessary to get perfect speed for me, because I'm just trying to get average same on all devices. Few pixels more or less shouldn't problem. – johnyX Dec 6 '15 at 19:14

The speed itself is correct. Because FPS = 1/dT. On tablet it is ~29.8FPS, and on xperia it is ~7.45 FPS. In 1 second the object travels updates count times pixels per update. That gives ~626px for tablet and ~640px on experia. The error above was caused by Math.round(calc) once in the process (="once per second"). If the position is stored as integer(rounded) the error will start to accumulate and keep growing each frame!
There is also the that fact actual number of updates per second is integer: For example with given integer speed xperia with (constant) 7.45FPS can do either 7 or 8 updates giving you either 602 px or 688 px, likewise the tablet will give either 609px or 630px. If the FPS is not constant (which is not in practice) the results can be even worse.
My suggestions:

• use higher accuracy tools (double instead of float, higher precision dT)
• postphone the rounding to the very last moment (save position as float-type and pass rounded copy to the actual drawing)

Also make sure the speed is incorrect: it can perceived incorrect while in-fact correct - for example physical dimension or the object is moving in dimension that is shorter that screenWidth.

• That sounds complicated :/ Do you have any experience with calculating speed somehow else, than with delta? (By the way, these calculations which I'm doing, is done before the player can play. Once he plays, the value is still and doesn't change). || Edit: FPS = 1/dT - that strange. Tablet maybe have ~30FPS, but Xperia has about 2x as tablet (and for that it is significantly faster than it should). – johnyX Dec 6 '15 at 19:27
• @johnyX well... it is none of my business but you really should allow people to convince you the pre-computed dT will cause many (unsolveable) problems in your game loop (if you dont do some thread.sleep()compensation like is usually done in fixed-step game loops). The 2nd suggestion is not really difficult: instead of class GameObject { int pos_x, pos_y; } have class GameObject { float pos_x, pos_y;} and have two types of getters one that rounds it and return int (used in rendering etc.) and other that return float and does not round(used when new calculating position). – wondra Dec 6 '15 at 19:30
• Okay, but although I would do this, I can't make dynamic speed because I can't change it since player plays. It would break my already drawed objects on scene. – johnyX Dec 6 '15 at 19:38
• @johnyX If it is the case, because the option to handle speed and position internally as float is not very intrusive(contrary to changing to dynamic step) I would say its the best solution to your current situation. If you have well-coded interface it will be almost no work at all. – wondra Dec 6 '15 at 20:07