This site requires JavaScript, please enable it in your browser!
Greenfoot back

Report as inappropriate.

mjrb4 presents ...



The FPS counter can now take one of two modes, the realtime mode is how it's been working up until now. If you change the mode to average then it will update the reading every second with the number of frames that have occured in the second previous - this latter mode should be more useful / accurate than how it's been working up until now for most situations.

Mode.AVERAGE is the default, to change it just change:
public static final Mode mode = Mode.AVERAGE;
public static final Mode mode = Mode.REALTIME;

To download the source for directly, just follow the website link.

12319 views / 2116 in the last 7 days

3 votes | 0 in the last 7 days

Tags: demo with-source fps

This scenario is a member of: Reusable actors & support classes

open in greenfoot
Your browser does not support the canvas tag.
A new version of this scenario was uploaded on Wed Sep 10 22:47:21 UTC 2008


Nice idea but it would be more useful if all of the FPS code was 100% contained in the Counter actor because then it would be easier to port and use in different scenarios.


You're right there, I think I'll make a second version where it's all in the counter actor. I'll also slow the thing down, at the moment you can sometimes barely see it when it changes so quickly!


You could always implement different counters. Sometimes you want the realtime framerate which is calculated on a per frame basis (useful for when your getting spikes in the frame rate), other times you might just be interested in an average frame rate over time and I personally literally count how many frames (or more accurately acts) occured in a second and then update the value (so it only updates once every second rather then in realtime). You might even want to go further and record the FPS to disk so you can compare the change in a frame rate over time (I used to do this with a program I made that displayed given frame rates as a graph). Very useful for testing new optimisations and code that could potentially add more overhead. You could try implementing all of these and any other alternatives people might find useful when profiling their scenario. This scenario could then try to be more of a 'do-all FPS all-in-one' scenario.


Nice - I'll throw up a simple version with a couple of corrections to start with and in the future look to do something a bit more complicated like that :)
A new version of this scenario was uploaded on Fri Sep 12 12:47:12 UTC 2008
You know, i think finding the Framerate over the course of several frames would be much more accurate that using a single frame.


I think you're right actually, I'm a bit busy at the moment but I'll look at changing it in the next few days :-)
A new version of this scenario was uploaded on Mon Jul 06 13:16:15 UTC 2009

Want to leave a comment? You must first log in.

Who likes this?

dan11 SPower Builderboy2005