I am assuming your update_graphics
method is based on a fixed delta time of FRAME_PERIOD
.
The problem is your while (sleepTime < 0 && framesSkipped < MAX_FRAME_SKIPS)
catch-up loop does not account for the time left over when it finishes catching up the model.
For example:
Your FRAME_PERIOD
is currently 20ms. Suppose the Galaxy Mini takes 2ms to run update_graphics
and 19ms to run render_graphics
. Now it will enter the catch-up loop with sleepTime=-1ms
, so it will run update_graphics
once. Then on the next time the while loop continues, it calls update_graphics
and render_graphics
again in your try block. By the time render_graphics
finishes drawing this second time, it has been 23ms since the last time it finished, but update_graphics
has been called twice. Therefore, it appears that 40ms of game time have passed in the space of 23ms, so your game would appear to be running 40/23 or 173% of the intended speed.
Meanwhile, on a fast device where sleep time is always positive, the game will always appear correct.
Also note, that the speed difference between Galaxy Mini and Galaxy S3 could have gone in the other direction (with S3 appearing faster) depending on relative times it takes for the update and render methods and their ratio to the FRAME_PERIOD
.
But aside from the above simplified situation (which ignores Vsync), sleep time is never going to be applied exactly by the OS--it will vary plus or minus a few ms each time.
For a simple game that doesn't have a physics simulation, it is a simpler solution to use a variable delta time in your update method.
If you have a fixed delta time (which you may need for a game with physics, or for your game which is already using fixed delta time), this site presents a clear explanation of how to implement it.