I’m curious, right now a app I’m developing runs 59-62 frames per second with this method:
local fps = 1/Deltatime
text(math.ceil(fps), 20, 20)
For some reason, I feel likes that is a bit to high for an app
I’m curious, right now a app I’m developing runs 59-62 frames per second with this method:
local fps = 1/Deltatime
text(math.ceil(fps), 20, 20)
For some reason, I feel likes that is a bit to high for an app
That is high, since draw() runs at a max 60 FPS doing nothing. The math.ceil routine rounds up, so that is probably the cause.
When I use that method it hits 70 sometimes so I made a moving average which shows it normally
actually, dave, that’s spot on. While the draw() routine runs at an average of 60 fps, the actual time between frames can vary a little bit, even when Codea is sitting still. I’ve also seen the delta time be less than 1/60th of a second.
To answer your question, Prynok: 60FPS is NOT too high. That is the ideal frame rate for a game, for many reasons.
The biggest reason is that your device’s display hardware works on a 60Hz cycle. The screen on your iPad redraws itself 60 times a second, and so if your app can maintain that pace, you’re drawing your screen once for every redraw of the iPad.
However, anything over 30 will probably be acceptable for most applications. Above 30 frames a second, the Human eye loses its ability to perceive individual motions, and things blend together. The faster your redraw, the smoother the motion will look, however, and if your frame rate is somewhere below 60, it will make movement look jerky and not fluid.
So you should shoot for an ideal FPS of 60 with occasional dips below that. If you can’t maintain 60, you should still shoot to keep it above 30. If you’re writing a game, and you can’t maintain 30 FPS, you need to rethink your rendering process: either display fewer objects or find a way to optimize the scene.
@tomxp411 I was going after the math.ceil command as being the problem more than the 60 FPS. If you run the lines below, it prints 61. So if 1/DeltaTime was 60.00001, displaying 60 would be more accurate even though 61 would be the result of the calculation. I guess it all depends on how accurate someone wants the display to be.
function setup()
print(math.ceil(60.00001))
end
Gotcha.
Yeah, using math.ceil() is the wrong way to go. It should be math.floor() in this case. Regardless, I have seen the screen refresh in < 1/60th of a second, which is why you still need to use DeltaTime when calculating motion.
@tomxp411 Don’t mean to nit pick, but using math.floor is just as bad as math.ceil, except it goes in the other direction. A more accurate display would be to use string.format, setting it to the number of decimal places you want to display. See example code.
function setup()
print(math.floor(59.99999)) -- truncates down prints 59
print(string.format("%.0f",59.49999)) -- rounds down prints 59
print(string.format("%.0f",59.50001)) -- rounds up prints 60
end
Thought this might be interesting. Graph showing the FPS of the draw function.
displayMode(FULLSCREEN)
function setup()
backingMode(RETAINED)
stroke(255)
strokeWidth(2)
fill(255)
c=WIDTH
end
function draw()
c=c+1
if c>WIDTH then
c=50
background(0)
text(55,30,350)
text(60,30,400)
text(65,30,450)
line(50,350,WIDTH,350)
line(50,400,WIDTH,400)
line(50,450,WIDTH,450)
text("Draw function -- Frames per second",WIDTH/2,HEIGHT-100)
end
ellipse(c,(1/DeltaTime)*10-200,2)
end
@dave1707 You always have a way of explaining things so simply and by using concise accurate examples. I would be shocked if you have never been a tutor/instructor/teacher in the past. I would definitely endorse and recommend you as a great one of those.
Not sure who first posted it, but I’ve long been using this little snippet.
FPS = 60 * 0.9 + 0.1 / DeltaTime
text(FPS, 35, HEIGHT-15)
I aim for around 55-60Fps
@Luatee - I agree, 50-60fps is probably the acceptable range for ‘fast moving’ arcade style games. Smoothing out occasional drops in performance below this is still the main challenge.
@matthew Thanks for the comment, but I was never a tutor/instructor/teacher. I don’t think I have the patience for something like that. But I do like simple explanations/examples for things. It helps me understand what’s happening and I think a simple answer explains things easier than a complicated detailed one. After I understand what’s happening, then I like to dig into the complicated detailed answers for an exact reason.
@dave1707 your more patient than most on the forum, who else do you see firing examples off at the new comers whilst explaining it with ease, I think you could really help some people out
@Andrew_Stacey Actually, I think I grabbed it precisely because it was such an ugly little piece of code. I assumed that somewhere, in some thread I’d not been following, there had been vigorous and arcane discussions over intricacies of the screen’s innards, and this blob was the result.
On the other hand, for me it’s just a number. Since I have only an iPad 2, I know that most users will operate far more quickly. I only look at relative changes to see if something I’ve done has an impact.
@Mark but you could just use
FPS = .9*FPS + .1/DeltaTime
instead of
FPS = .9*60+ .1/DeltaTime
to get the exact value instead of just a comparison. Its just a small change. And if you just want to compare maybe, just
FPS = 1/DeltaTime
is good enough.
My opinion on this is that you need atleast 40 if you want it to run smoothly (my opinion)
I believe @Jmv38 created the .9 * FPS + 1 / DeltaTime
snippet.
One line of code to add an accurate and stable FPS watcher to your project (Put in draw):
if FPS == nil then FPS = 1 / DeltaTime parameter.watch("FPS") else FPS = FPS * 0.9 + 0.1 / DeltaTime end
(Using Jmv38’s way, just made an automatic line of code.)