Speed diff between transition.to and manual movement in delta time?

Audio and Graphics
#1

I have been working on some simple animations and noticed speed differences between devices.  

On an nvidia shield k1, the transition.to(…) works flawlessly and no choppiness, etc.  However, on a Nexus 7 2013 there was noticeable choppiness.  Both devices are running Android 6.0.1.

For testing purposes I made a manual delta time animation using event “enterFrame” and the Nexus device was smoother.  The nVidia device remained smooth.  The manual animation did the following code, based on some forum discovery (which I wrote something similar in Marmalade Quick a while back):

    local temp = system.getTimer()  -- Get current game time in ms     local dt = (temp-runtime) / (1000/30)  -- 60 fps or 30 fps as base     runtime = temp  -- Store game time

The config settings I used didn’t specify a resolution? Should that be done?  In the graphics demo of “fishes” it does specify the resolution.

There may be a performance topic or link to a webpage discussing this one.  Please share if you would.

#2

@Paul,

Sorry, but That equation isn’t right.

The dt calculation should work independently of the frame rate and should NOT incorporate 30 or 60 as part of the calculation.

Note: I’ve seen people use that equation before and I’d love to know where they are getting it because it seems to be causing some confusion.  

Correct Way To Calculate (Frame Rate Independent) Fixed Rate Movement Calcuated From Delta Time

Constraints:

  • Object should move at 100 pixels-per-second

  • Object is moving on x-axis only (for simplicity of example)

    local function enterFrame( self, event ) local curTime = system.getTimer() local dt = curTime - self.lastTime self.lastTime = curTime local dx = self.rate * dt / 1000 self.x = self.x + dx end local obj = display.newCircle( 10, 10, 10 ) obj.rate = 100 obj.lastTime = system.getTimer() obj.enterFrame = enterFrame Runtime:addEventListener( “enterFrame”, obj )  

#3

Yes, thank you.  I didn’t like the hard coded fps value myself.  Glad you chimed in.  I will go play around with the code.

#4

@Paul,

Sorry, but That equation isn’t right.

The dt calculation should work independently of the frame rate and should NOT incorporate 30 or 60 as part of the calculation.

Note: I’ve seen people use that equation before and I’d love to know where they are getting it because it seems to be causing some confusion.  

Correct Way To Calculate (Frame Rate Independent) Fixed Rate Movement Calcuated From Delta Time

Constraints:

  • Object should move at 100 pixels-per-second

  • Object is moving on x-axis only (for simplicity of example)

    local function enterFrame( self, event ) local curTime = system.getTimer() local dt = curTime - self.lastTime self.lastTime = curTime local dx = self.rate * dt / 1000 self.x = self.x + dx end local obj = display.newCircle( 10, 10, 10 ) obj.rate = 100 obj.lastTime = system.getTimer() obj.enterFrame = enterFrame Runtime:addEventListener( “enterFrame”, obj )  

#5

Yes, thank you.  I didn’t like the hard coded fps value myself.  Glad you chimed in.  I will go play around with the code.