|
libdonut
2.3.2
Application framework for cross-platform game development in C++20
|
Configuration options for an Application. More...
#include <donut/application/Application.hpp>
Public Attributes | |
| float | tickRate = 60.0f |
| The tick rate of the application, in hertz (ticks per second). More... | |
| float | minFrameRate = 1.0f |
| Minimum frame rate of the application, in hertz (frames per second), before tick slowdown occurs. More... | |
| float | maxFrameRate = 480.0f |
| Maximum frame rate of the application, in hertz (frames per second), before frames are delayed. More... | |
| bool | frameRateLimiterSleepEnabled = true |
| Put the thread that is running the application to sleep until the next frame is supposed to begin if the maximum frame rate is exceeded. More... | |
| std::chrono::steady_clock::duration | frameRateLimiterSleepBias = std::chrono::microseconds{100} |
| The duration offset to subtract from the requested wake-up time when frame rate limiter sleep is enabled. More... | |
Configuration options for an Application.
| float donut::application::ApplicationOptions::tickRate = 60.0f |
The tick rate of the application, in hertz (ticks per second).
This is the rate at which the application will try to trigger the processing of a tick, which is the main mechanism for providing application subsystems with updates at a fixed interval, independent from the main frame rate of the application.
Tick processing is performed on each frame of the application, which may result in anywhere from 0 to tickRate/minFrameRate ticks being processed, depending on the time since the previous frame. When not enough time has passed to process any ticks within a frame, the time is accumulated for the next frame, and so on, until enough time has passed to process more ticks. If several ticks' worth of time passed since the previous frame, multiple ticks will be processed, and any remaining time will carry over to the next frame. This results in a fixed average interval between ticks even in the event of high framerates or small frame rate drops.
If set to a non-positive value, no tick processing will occur, and tick() will never be called.
| float donut::application::ApplicationOptions::minFrameRate = 1.0f |
Minimum frame rate of the application, in hertz (frames per second), before tick slowdown occurs.
If the frame rate drops below this limit, the application will start to skip the processing of some ticks in order to avoid a spiral of death where the amount of ticks to process continues to increase faster than they can be processed, which would lead to the application becoming completely unresponsive.
If set to 0 or lower, or to a value higher than the tick rate, the maximum number of ticks per frame will be set to 1, causing slowdown to always occur whenever the frame rate goes below the tick rate. This is generally not recommended.
| float donut::application::ApplicationOptions::maxFrameRate = 480.0f |
Maximum frame rate of the application, in hertz (frames per second), before frames are delayed.
If the frame rate goes above this limit, the application will wait until enough time has passed for the next frame to begin.
Set to 0 or a negative value for no frame rate limit.
| bool donut::application::ApplicationOptions::frameRateLimiterSleepEnabled = true |
Put the thread that is running the application to sleep until the next frame is supposed to begin if the maximum frame rate is exceeded.
This helps reduce the CPU usage of the application in low-load scenarios.
| std::chrono::steady_clock::duration donut::application::ApplicationOptions::frameRateLimiterSleepBias = std::chrono::microseconds{100} |
The duration offset to subtract from the requested wake-up time when frame rate limiter sleep is enabled.
Since there is some overhead associated with waking a thread from sleep, the thread must be requested to wake up slightly before the next frame is supposed to begin to avoid missing the deadline, otherwise the actual frame rate may fluctuate and deviate from the intended target frame rate.
However, the larger this duration is, the more time will be spent busy-waiting before each frame begins, which will increase the CPU usage and limit the effectiveness of frame rate limiter sleep.
The default value is tuned to produce decent results on most harware, though it may need to be adjusted depending on application-specific requirements.
1.9.1