Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

[SOLVED] Frames Per Second variable

edited September 2013 in Suggestions Posts: 49

[SOLVED] It would be nice for debugging purposes if there was some sort of constant or variable that kept track of the fps. Sometimes it's hard to tell the difference between 60fps and 40fps, but this difference could potentially be a big difference in a well oiled app. If there are any "work arounds" for the time being that anyone knows of, that would help me a lot!

Comments

  • IgnatzIgnatz Mod
    edited September 2013 Posts: 5,396

    This is one we commonly use.

    In setup, put: FPS=60

    In draw, put: FPS = FPS * 0.9 + 0.1 / DeltaTime

    This creates a smoothed running average. DeltaTime is the time since the last redraw.

    Credit - as far as I know, @Jmv38 made this one.

  • Jmv38Jmv38 Mod
    Posts: 3,295

    Yup, thanks for the credit.
    It is also very important to keep track of the smallest instantaneous fps value 1/deltatime during the, say, last 2s, if you want a 'well oiled app': 1 single frame drop at 3 FPS is very painful for the user (app freeze).

  • Posts: 2,161

    What you do depends on what you want to measure. As @Jmv38 says, it might be that a blip is really noticeable so you want the minimum over the last time period. "Instantaneous" FPS is given by 1/DeltaTime but that is very hard to see as (unless the FPS is very low) it changes too fast. It can help to round the answer to the nearest integer, or nearest 5. So I sometimes have:

    parameter.watch("2*math.floor(.5/DeltaTime)")
    

    Or 5 and .2 instead of 2 and .5.

    For a running average, here it depends on what you want. Do you want the average FPS over the last, say, ten draws? Or do you want the average frames over the last ten seconds? It's a different formula for each.

    My usual code is to have a table with the last ten DeltaTimes in it, then to add these up to get the total time taken by the last ten frames, call this TenTime, and then compute 10/TenTime. This gives me a more readable FPS, but it isn't affected by memory (in that a blip from more than 10 frames ago has no effect on the current reading).

    I seem to remember something of a discussion when Jmv38 introduced the "smoothed running average" formula. If you're really interested, look it up. I'll say that it's not my choice as it's not really clear exactly what it measures, so it gives only an indication of the frame rate.

  • IgnatzIgnatz Mod
    Posts: 5,396

    @Andrew_Stacey - I gave @Jmv38's smoothed formula above. I like it because it doesn't require holding 10 past values. It is simple and relatively stable, and I think it is a good solution for most users.

  • edited September 2013 Posts: 49

    Thanks everyone! I'm now using Jmv38's method, but with math.floor to give a more readable answer.

    Now I can tell that my game is running at 55fps on an ipad2. I think that is acceptable. I'll try it on my iPad 1 later

Sign In or Register to comment.