FrameClock: A class to track various frame time statistics.

[Lee R]

Hi,

I've made my first contribution to the SFML wiki by adding the source code of a class designed to track various frame time statistics, such as:

    * total number of frames;
    * total frame time;
    * current frame time;
    * shortest measured frame time;
    * longest measured frame time;
    * average frame time over a user specified number of frames (called sample depth);
    * frames per second;
    * lowest measured frames per second;
    * highest measured frames per second, and;
    * average frames per second over a user specified number of frames (called sample depth).

Full details at the link below:
https://github.com/SFML/SFML/wiki/Source:-FrameClock

Thanks,
Lee.

[eXpl0it3r]

Looks good!

Two things though:

• You should change the title to include a space, thus "Source: FrameClock" to have the same format as every other article. (Thus you'll have to update the links to it)
• The time spent between endFrame() and beginFrame() doesn't get recorded, right? Maybe a nicer approach would be, just to have one update function.

[Lee R]

I'll have a look into the link thing at some point.

As for your second point, I actually considered adding a 'design rationale' section in the article to explain exactly that. The short answer is that splitting the update into two separate 'begin/end' functions allows the class to be more general, i.e. can more easily be used outside of loop contexts, or to measure just a fraction of some code inside a loop.

[eXpl0it3r]

I'll have a look into the link thing at some point.

Well then, I've fixed it for you.
You'll only have to adjust the link in your first post: https://github.com/SFML/SFML/wiki/Source:-FrameClock

As for your second point, I actually considered adding a 'design rationale' section in the article to explain exactly that. The short answer is that splitting the update into two separate 'begin/end' functions allows the class to be more general, i.e. can more easily be used outside of loop contexts, or to measure just a fraction of some code inside a loop.

Yeah, I kinda thought, that this would be the reason you went with it.
You might warn people though, that the part that happens outside of the begin/end block is not recorded.

[Lee R]

Well then, I've fixed it for you. [...]

I've updated the link in my OP. Thanks

You might warn people though, that the part that happens outside of the begin/end block is not recorded.

Sorry but I'm having a hard time seeing the ambiguity. Are the words 'begin' and 'end' really not explicit enough? Also, I explicitly define a unit of measure in the article:

The time elapsed during the last sampled frame (i.e. between a beginFrame/endFrame pair) can be obtained with the member function getLastFrameTime.

The only way I can imagine this coming to someone's mind, is if they had not read the article and instead went straight to the source code, had a quick look at the implementation of 'FrameClock::endFrame', and being confused by the absence of code to reset the internal timer. But then it's just a case of Read the Fine Manual

[eXpl0it3r]

Sorry but I'm having a hard time seeing the ambiguity. Are the words 'begin' and 'end' really not explicit enough?

No it's not that, but with the example you kind of suggest, that it will capture the whole time spent on each frame, which is to a large extend true, but you'll miss the few nano-/milliseconds that is spent between begin/end.

while(true)
{
    clock.beginFrame();
    // This gets recorded
    clock.endFrame();
} // The time spent here, freeing resources or whatever doesn't get counted

I know it doesn't really matter, since the time spent there is and should be very, very low, but I just wanted to point it out. It's something one can easily miss.
A possible fix would be to write something like this:

while(true)
{
    clock.beginFrame();
    {
        // Do something
    } // Stuff gets cleaned up here
    clock.endFrame();
}

Now the only thing that can still take longer than 1-2 CPU cycle is the function which feeds the while loop's check.

Again it doesn't really matter, but one should just be aware.

[Lee R]

Ah yes I see what you mean now.

However, one of my goals was to avoid writing a rigorous treatise on proper measurement techniques. There are a number of articles already on the web dealing with the subject in much more detail than I could ever manage. But, you are free to edit the article with that kind of information if you think it would benefit people

EDIT:
Having thought about it some more, I think it would be nice to provide some kind of ScopedSample class. Again though, I really don't want to be in the business of explaining object lifetime and scoping rules in C++.