Ticker

Returns the exponential moving average of the frames per second.

Gets the maximum frame rate.

Other factors also limit the FPS; see MainLoop.setSimulationTimestep for details.

See also MainLoop.setMaxAllowedFPS().

Gets how many milliseconds should be simulated by every run of update().

See MainLoop.setSimulationTimestep() for details on this value.

Returns whether the main loop is currently running.

See also MainLoop.start() and MainLoop.stop().

Reset the amount of time that has not yet been simulated to zero.

This introduces non-deterministic behavior if called after the application has started running (unless it is being reset, in which case it doesn't matter). However, this can be useful in cases where the amount of time that has not yet been simulated has grown very large (for example, when the application's tab gets put in the background and the browser throttles the timers as a result). In applications with lockstep the player would get dropped, but in other networked applications it may be necessary to snap or ease the player/user to the authoritative state and discard pending updates in the process. In non-networked applications it may also be acceptable to simply resume the application where it last left off and ignore the accumulated unsimulated time.

Sets a maximum frame rate.

See also MainLoop.getMaxAllowedFPS().

Sets how many milliseconds should be simulated by every run of update().

The perceived frames per second (FPS) is effectively capped at the multiplicative inverse of the simulation timestep. That is, if the timestep is 1000 / 60 (which is the default), then the maximum perceived FPS is effectively 60. Decreasing the timestep increases the maximum perceived FPS at the cost of running update() more times per frame at lower frame rates. Since running update() more times takes more time to process, this can actually slow down the frame rate. Additionally, if the amount of time it takes to run update() exceeds or very nearly exceeds the timestep, the application will freeze and crash in a spiral of death (unless it is rescued; see MainLoop.setEnd() for an explanation of what can be done if a spiral of death is occurring).

The exception to this is that interpolating between updates for each render can increase the perceived frame rate and reduce visual stuttering. See MainLoop.setDraw() for an explanation of how to do this.

If you are considering decreasing the simulation timestep in order to raise the maximum perceived FPS, keep in mind that most monitors can't display more than 60 FPS. Whether humans can tell the difference among high frame rates depends on the application, but for reference, film is usually displayed at 24 FPS, other videos at 30 FPS, most games are acceptable above 30 FPS, and virtual reality might require 75 FPS to feel natural. Some gaming monitors go up to 144 FPS. Setting the timestep below 1000 / 144 is discouraged and below 1000 / 240 is strongly discouraged. The default of 1000 / 60 is good in most cases.

The simulation timestep should typically only be changed at deterministic times (e.g. before the main loop starts for the first time, and not in response to user input or slow frame rates) to avoid introducing non-deterministic behavior. The update timestep should be the same for all players/users in multiplayer/multi-user applications.

See also MainLoop.getSimulationTimestep().

Starts the main loop.

Note that the application is not considered "running" immediately after this function returns; rather, it is considered "running" after the application draws its first frame. The distinction is that event handlers should remain paused until the application is running, even after MainLoop.start() is called. Check MainLoop.isRunning() for the current status. To act after the application starts, register a callback with requestAnimationFrame() after calling this function and execute the action in that callback. It is safe to call MainLoop.start() multiple times even before the application starts running and without calling MainLoop.stop() in between, although there is no reason to do this; the main loop will only start if it is not already started.

See also MainLoop.stop().

Stops the main loop.

Event handling and other background tasks should also be paused when the main loop is paused.

Note that pausing in multiplayer/multi-user applications will cause the player's/user's client to become out of sync. In this case the simulation should exit, or the player/user needs to be snapped to their updated position when the main loop is started again.

See also MainLoop.start() and MainLoop.isRunning().