My Game Engine is the heart and soul of three of my games and I used @jmv38’s FPS formula to do a test on my engine and found it was running at 27 FPS, (Around 8 while recording), but the weird thing is, there is no lag. Any advice on raising FPS Or Help in understanding whats going on would be very helpful
I’d need to see the code. Are you printing at all for debug tests? That will drop fps.
Ill PM you the code bc i plan to publish if it goes well
No surprise, any FPS of 30 or more is enough, see here
http://xcorr.net/2011/11/20/whats-the-maximal-frame-rate-humans-can-perceive/
Your problem is going to be adding anything else that slows it down!
It’s very difficult to optimize code once it becomes complex. What I usually do is test what happens if I bypass different chunks of code, (eg instead of doing path finding, just walk straight ahead), and see where the delays are coming from.
@codeanoob the key for high fps is usually drawing:
- if you can draw all lines, ellipses, etc, in an image and sprite it around.
- or, if you have many similar objects, use a mesh with this image as a texture.
Jmv38’s formula for FPS is not an accurate reflection of the actual frame rate. If you look in the various threads on frame rate then you’ll find alternatives that provide a more accurate picture of the frame rate in your program.
@Andrew_Stacey - I think Jmv38’s averaging method is close enough, though, to tell you if you have problems or not. You don’t want to get any lower than 30 if you can help it.
@CodeaNoob - are you more interested in optimising your code to increase your FPS rather than better/more accurate methods of reporting the actual frame rate?
If its the former, there have been many discussions on here regarding some obvious tricks - mostly to squeeze better performance out of Lua e.g local rather than global variables etc… I’ll try and dig a list out if your interested.
@Ignatz Sure, Jmv38’s formula is clearly related to the actual FPS and is a sufficiently close approximation that it shows any large issues. But if you want to do detailed analysis of a program’s FPS then you need more careful measurements. So actually I regard @andymac3d’s question as a red herring: if you want to optimise your code to increase your FPS then you’d better have more accurate methods of reporting the actual frame rate. Otherwise, how do you know whether your optimisations are doing anything, and which optimisations are worth doing?
It’s also the case that “FPS” is a red herring in itself. We often talk of “FPS” as if it were a single thing, but it’s not. There’s the “instantaneous” FPS which we compute by 1/DeltaTime, but this usually flickers too fast to see what’s going on. So then there’s the “average” FPS of the last few frames (which is not the average of the instantaneous FPS of those frames, of course). But often the most important thing is to minimise “spikes” where the program hiccoughs. For this, you’d want the minimum FPS over the last, say, 10 frames.
The danger is to say “That’s too complicated, I’m going to use this nice simple formula” because then you’re throwing the baby out with the bath water. In truth, none of these are complicated to compute. And each tells you something different and worth knowing. Jmv38’s formula may be slightly simpler, but it doesn’t actually tell you anything directly.
@Andrew_Stacey - you’ve made a good point. Averaging FPS over a number of frames will only give you the ‘gist’ of whats going on and will not account for performance spikes. Much better perhaps to report the min/max values as well as the average? I guess(?) ensuring these values are as close as possible to the ‘average fps’ will give a better indication of whether the fps is consistent?
I think for most people who are perhaps not ‘pro game devs’ this is mostly irrelevant as the ‘average’ would mostly suffice as a rough indicator of performance.
Similarly, some simple Lua optimisations should improve the ‘average fps’ noticeably and make some noticeable difference. :-/
What type of game is it, are you using physic.body’s?
@Prynok, No, Its an Arcade style game with a D-Pad giving a sprite direction over a map, no physics is involved anywhere
This and one sprite that moves when the D-Pad is touched
for x=53,WIDTH,102 do
for y=HEIGHT-(36),1,-85 do
sprite("Planet Cute:Grass Block", x, y, 108, 176)
@CodeaNoob Ah, I see your problem, you are drawing a lot of sprites, I would suggest looking at my thread “Less lag in a building game” I had the exact same problem, now I get 57 fps with 10,000 images on the screen.
Concerning fps: i completely agree on. Average fps not good enough. This is why i usually also conpute the ‘min instantaneous fps in the last 2s’ that is more relevant for user satisfaction.
Here’s something completely accurate, I believe:
--# FPS
FPS = 0
local frames = 0
local time = 0
tween.delay(0, function()
local d = draw
draw = function()
frames = frames + 1
if math.floor(ElapsedTime) ~= math.floor(time) then
FPS = frames - 1
frames = 1
end
time = ElapsedTime
d()
end
end)
--# Main
-- True FPS
-- Use this function to perform your initial setup
function setup()
print("Hello World!")
parameter.watch("FPS")
end
-- This function gets called once every frame
function draw()
-- This sets a dark background color
background(40, 40, 50)
-- This sets the line thickness
strokeWidth(5)
-- Do your drawing here
end
You can add this as a dependency to any project and it will only create the global variable “FPS.”
The cool part is that it hooks into the draw function for computing frames and time. The first time it updates the FPS variable it’ll be a bit off, after that it should be exact.
@SkyTheCoder It’s dangerous to write “completely accurate” with a mathematician nearby!
What it looks like you are trying to compute is the number of frames that were rendered in a particular second. So you use tween.delay to modify the draw function as soon as everything is set up (this is quite neat, Codea Community uses debug.sethook to achieve the same effect with the setup function - I guess that tween.delay wouldn’t work for the setup function though). Then every whole second you record the number of frames that were rendered in that second.
I think I would go for “completely literal” rather than “completely accurate” since it answers the question “How many frames were rendered in the last whole second?” which is a basic interpretation of the term “frames per second”. It would be better to think in terms of frame rate the units of which are “frames per second”.
@Jmv38’s code in XFC is functionally the same, except that the time interval is .5s instead of 1s.
I’d certainly agree that these are certainly far, far better than the fps = .9*fps + .1/DeltaTime formula. I wouldn’t say that they are the best measurements, though. The obvious problem with them is that they work on discrete time intervals. So each frame contributes to just one measurement. That makes it easier for a frame to “hide”. For example, suppose that your average frame rate is 30fps but every now and again you get a spike and it drops to 15fps. Suppose also you sometimes get a good spike and it rises to 60fps. If both of these occur in the same second then they will cancel out and you won’t see either effect. With a rolling measurement then you would see these effects. (Not that rolling measurements don’t have their downsides either, but they are more robust against this type of error.)
@Andrew_Stacey By completely accurate, I meant it’s the actual number of frames that were rendered in the last second.
I disagree with two spikes, one bad and one good occurring in the same second canceling eachother out. It counts the amount of frames in that second, not the speed at which they were made, but the amount. Rolling measurements would detect it, but the value it returns is an estimate of your frames per second, based on the speed at which the last frames were rendered.