FPS and frame : something is strange

[latyl1]

Hi all,
I have a question about FPS : there is something I don’t understand very well.

Here it is : originally, my game run in 60 FPS (in config.lua), and i use a “enterframe” function doing the job, skipping a frame each 2 frames : the third time i enter the function then i directly exit it. So my game run in a “bastard” 40 FPS where there is not the same timerate between each frame, but it’s not very important because the game is so speed that an human don’t see any timejump between frames.

When I test my game on an iphone 7, i have the speed i need. Let’s say, speed = 5/5.
When I test it on an old android device, the same code is very slow. Let’s say, speed = 1/5.

So in this last case, i thought that there is no need to delete my “skipping” function because if the code working in a frame last more than the time of the current frame, doing a real 60 FPS will not improve the speed : while a frame is not ended, another can’t begin.

But it WORKS IN THE OPPOSITE WAY : if I delete my “skip 1 frame each 2 frames” function on an old device then i obtain a good speed, let’s say 3/5.
HOW IS IT POSSIBLE ?

[bjsorrentino]

My initial question would be, why bother? Why not let the device utilize all the power it can?

Brent

[latyl1]

Because the game is too speed and unplayable else

[carloscosta]

your test device should never be your fastest device, iphone 7 will run all code 5/5. it will spoil you. test if possible always with your slowest device when creating any project.

if your code is frame base dependence you will always have problems trying to have same speeds on different devices.

your code should be time-based dependence or time/frame dependence. time is the only “constant” you have across any device.

[roaminggamer]

I second what @carloscosta is saying.
 
You shouldn’t try to limit your game’s speed by using enterFrame gates like you’re trying to do.
 
Instead, calculate speeds based on desired target rate in pixels-per-second or (degrees-per-second for rotations) and use elapsed time to get that rate.
 
Very Simple Example
For example,  lets say you want a object to move left to right at a rate of 125 pixels-per-second  (design pixels not physical pixels * ).

local obj = display.newCircle( 0, 200, 10) obj.rate = 125 obj.lastTime = system.getTimer() obj.enterFrame = function( self ) local curT = system.getTimer() local dt = curT - self.lastTime self.lastTime = curT local dx = self.rate \* dt/1000 self.x = self.x + dx end Runtime:addEventListener( obj, "enterFrame" )

Note: Not only will this be consistent across devices, it will also be much smoother than just assuming a frame lasts for an exact and unchanging period of time as you’re doing.

Note2: Not all frames are of equal duration: 33.33, 30, 35, 40, 27, 33, …

Design Pixels vs Actual/Physical Pixels*

1. These are my terms, others will use different ones.
    
2. Design Pixels - If your config.lua is set up as 320x480, it means you’re designing as if your devices are all 320 pixels wide  by 480 pixels tall.
    
3. If you run on a device that is 640x960, then every design pixel is equal to two physical pixels.
    
4. Movements using the above will work consistently because although the scale is 2X, the entire world of objects is also scaled, so the ratio of movement to dimension is still 1 to 1.

[bjsorrentino]

My initial question would be, why bother? Why not let the device utilize all the power it can?

Brent

[latyl1]

Because the game is too speed and unplayable else

[carloscosta]

your test device should never be your fastest device, iphone 7 will run all code 5/5. it will spoil you. test if possible always with your slowest device when creating any project.

if your code is frame base dependence you will always have problems trying to have same speeds on different devices.

your code should be time-based dependence or time/frame dependence. time is the only “constant” you have across any device.

[roaminggamer]

I second what @carloscosta is saying.
 
You shouldn’t try to limit your game’s speed by using enterFrame gates like you’re trying to do.
 
Instead, calculate speeds based on desired target rate in pixels-per-second or (degrees-per-second for rotations) and use elapsed time to get that rate.
 
Very Simple Example
For example,  lets say you want a object to move left to right at a rate of 125 pixels-per-second  (design pixels not physical pixels * ).

local obj = display.newCircle( 0, 200, 10) obj.rate = 125 obj.lastTime = system.getTimer() obj.enterFrame = function( self ) local curT = system.getTimer() local dt = curT - self.lastTime self.lastTime = curT local dx = self.rate \* dt/1000 self.x = self.x + dx end Runtime:addEventListener( obj, "enterFrame" )

Note: Not only will this be consistent across devices, it will also be much smoother than just assuming a frame lasts for an exact and unchanging period of time as you’re doing.

Note2: Not all frames are of equal duration: 33.33, 30, 35, 40, 27, 33, …

Design Pixels vs Actual/Physical Pixels*

1. These are my terms, others will use different ones.
    
2. Design Pixels - If your config.lua is set up as 320x480, it means you’re designing as if your devices are all 320 pixels wide  by 480 pixels tall.
    
3. If you run on a device that is 640x960, then every design pixel is equal to two physical pixels.
    
4. Movements using the above will work consistently because although the scale is 2X, the entire world of objects is also scaled, so the ratio of movement to dimension is still 1 to 1.