Duration of the last update

[j-jorge]

Axmol has a feature to display the FPS counter over the UI via ax::Director::setStatsDisplay(). I would like this function to also display the duration of the last update. Ideally I would like to be able to retrieve this duration too, so I can plot them.

The problem I would like to solve with this is the following. If I add a processing that turns my update from 2 ms to 15 ms, it is a very expensive processing, but I won't see it because the FPS counter would still be at 60. It's only when I'll introduce the next feature that would costs 2 ms (for example) that I would see a drop. Unfortunately it would be quite late.

[rh101]

I would like this function to also display the duration of the last update.

Isn't this the value you're after:

That is the duration of the update. Isn't it displaying the correct value for you?

To read the value, use Director::getSecondsPerFrame().

[j-jorge]

This is not what I'm looking for :) If I tracked this value correctly this is based on _deltaTime, which is computed in calculateDeltaTime() as the time since the last call. Consequently it includes the call to sleep() that happened in between. What I'm looking for is the time it took to go from the opening brace of mainLoop() to the closing brace.

[rh101]

In that case, have you tried using listeners for events that are dispatched from the mainLoop? Specifically, these events:

const char* Director::EVENT_AFTER_DRAW            = "director_after_draw";
const char* Director::EVENT_AFTER_VISIT           = "director_after_visit";
const char* Director::EVENT_BEFORE_UPDATE         = "director_before_update";
const char* Director::EVENT_AFTER_UPDATE          = "director_after_update";
const char* Director::EVENT_BEFORE_DRAW           = "director_before_draw";

A combination of them should provide the timings you are after. Refer to the mainLoop implementation to see when each event is dispatched.

[j-jorge]

calculateDeltaTime() factors the mainLoop but also the delay between the calls, thus also the this_thread::sleep_for(...) which rhythms the updates. So it is not representative of the workload.

Displaying the value of the last update may not be good enough, because it changes too quickly. The only way you would notice a difference is if the update duration stayed the same for long enough to notice the spikes. It would make more sense to have a live plot of the updates over a period of time, because then the differences in the duration of the update would be obvious. That may actually be really handy information to have.

Indeed when I tried to trace the duration with the events it was oscillating a lot! A plot would be awesome but isn't it a bit out of scope? I am personally considering Tracy for my game, I think it will work well to plot the data, as long as I have a value to pass.

[rh101]

I've never come across Tracy Profiler before, so thanks for the link.

With the existing events, adding something to a project is relatively trivial, but it would actually be nice to have small graph on the bottom left with the rest of the stats that shows abnormal spikes in the duration of the update. Displaying the minimum, average, and maximum values on the Y axis of the graph would also give a clearer picture of what is going on in the app. I've got an idea in my mind about how it would look, so if I get some free time I'll see if I can create a demo to gauge its usefulness.

[aismann]

Why not using the internal (axmol/cocos2dx) profiler?

[j-jorge]

Why not using the internal (axmol/cocos2dx) profiler?

Where is it? I've never heard of it.

[aismann]

Look: