-
Axmol has a feature to display the FPS counter over the UI via 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. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 11 replies
-
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
In that case, have you tried using listeners for events that are dispatched from the mainLoop? Specifically, these events:
A combination of them should provide the timings you are after. Refer to the |
Beta Was this translation helpful? Give feedback.
In that case, have you tried using listeners for events that are dispatched from the mainLoop? Specifically, these events:
A combination of them should provide the timings you are after. Refer to the
mainLoop
implementation to see when each event is dispatched.