faster calculations with new Corona build?

Audio and Graphics
#1

I have some missile movement in my game which is calculated by adding a value a current position using a delta-time variable.

With the new build I have noticed the missiles are a lot faster and I wonder if there where some changes made to the calculations regarding the positions, like missile.x=missile.x+1 ?

(Delta time not shown here!)

#2

We’ve not made any changes that should impact performance.

rob

#3

That’s strange. Thanks for the info!

#4

Show us how you are determining delta time.
 
For example, where I read what you wrote I think something like this:

local getTimer = system.getTimer local obj = display.new... whatever obj.speed = 100 -- pixels per second function obj.enterFrame( self ) local curT = getTimer() local dt = curT - (self.lastTime or 0) self.lastTime = curTime if( dt \> 0 ) then self.x = self.x + self.speed \* dt/1000 end end Runtime:addEventListener( "enterFrame", obj )
#5

The following is the deltatime function I’m using for multiply the value I add to the position of the missile in the missile update code:

local runtime = 0 local getDeltaTime=function () local temp = system.getTimer() -- Get current game time in ms local dt = (temp-runtime) / (1000/60) -- 60 fps or 30 fps as base runtime = temp -- Store game time return dt end
#6

That’s not right.  You’re doing a delta-frame calculation which is not what you want.
 
You don’t need to incorporate anything for FPS.
 
Delta time calcs do not care about the FPS setting in config.lua
 
Time is time regardless of how your config.lua file  is set up.
 
This is what you want:

local runtime = system.getTimer() local getDeltaTime=function () local temp = system.getTimer() local dt = (temp - runtime) / 1000 runtime = temp return dt end

To be ABSOLUTELY clear, all rates should be in terms of pixels-per-second when using delta-time calculations.

Thus 100 is 100 pixels-per-second in my example towards the top.

Those ‘pixels’ are design pixels. So, if your config.lua file specifies 320x480, then moving 100 pixels horizontally per second means moving approximatly 1/3 of the way across the screen per second, regardless of the actual pixel density of the screen.  (Assuming you’re using letterbox scaling).

PS - Delta-frame calculations will result in rate variations which I believe is what you are seeing. You’ve added a dependency in your calculation that should not be there.

#7

Thank you so much for your help! I will implement this asap!

Much appreciated!

#8

We’ve not made any changes that should impact performance.

rob

#9

That’s strange. Thanks for the info!

#10

Show us how you are determining delta time.
 
For example, where I read what you wrote I think something like this:

local getTimer = system.getTimer local obj = display.new... whatever obj.speed = 100 -- pixels per second function obj.enterFrame( self ) local curT = getTimer() local dt = curT - (self.lastTime or 0) self.lastTime = curTime if( dt \> 0 ) then self.x = self.x + self.speed \* dt/1000 end end Runtime:addEventListener( "enterFrame", obj )
#11

The following is the deltatime function I’m using for multiply the value I add to the position of the missile in the missile update code:

local runtime = 0 local getDeltaTime=function () local temp = system.getTimer() -- Get current game time in ms local dt = (temp-runtime) / (1000/60) -- 60 fps or 30 fps as base runtime = temp -- Store game time return dt end
#12

That’s not right.  You’re doing a delta-frame calculation which is not what you want.
 
You don’t need to incorporate anything for FPS.
 
Delta time calcs do not care about the FPS setting in config.lua
 
Time is time regardless of how your config.lua file  is set up.
 
This is what you want:

local runtime = system.getTimer() local getDeltaTime=function () local temp = system.getTimer() local dt = (temp - runtime) / 1000 runtime = temp return dt end

To be ABSOLUTELY clear, all rates should be in terms of pixels-per-second when using delta-time calculations.

Thus 100 is 100 pixels-per-second in my example towards the top.

Those ‘pixels’ are design pixels. So, if your config.lua file specifies 320x480, then moving 100 pixels horizontally per second means moving approximatly 1/3 of the way across the screen per second, regardless of the actual pixel density of the screen.  (Assuming you’re using letterbox scaling).

PS - Delta-frame calculations will result in rate variations which I believe is what you are seeing. You’ve added a dependency in your calculation that should not be there.

#13

Thank you so much for your help! I will implement this asap!

Much appreciated!