Class | Rubygame::Clock
In: | lib/rubygame/clock.rb
Parent: | Object

Clock provides class methods for tracking running time and delaying execution of the program for specified time periods. This is used to provide a consistent framerate, prevent the program from using all the processor time, etc.

Clock also provides instance methods to make it convenient to monitor and limit application framerate. See tick.

An in-depth tutorial on using Clock is available. See doc/managing_framerate.rdoc in the Rubygame source distribution or in the online documentation.

### Methods

calibrate delay enable_tick_events framerate frametime lifetime new runtime target_framerate target_framerate= target_frametime target_frametime= tick wait

### Attributes

granularity | [RW] | Granularity used for framerate limiting delays in tick. You can calibrate this easily with calibrate. See also tick and Clock.delay. (Non-negative integer. Default: 12.)
nice | [RW] | Whether to try to let other ruby threads run during framerate limiting delays in tick. See tick and Clock.delay. (true or false. Default: false.)
start | [R] | The runtime when the Clock was initialized.
ticks | [R] | The number of times tick has been called.

### Public Class methods

delay( time, gran=12, nice=false )

time: | The target delay time, in milliseconds. (Non-negative integer. Required.)
gran: | The assumed granularity (in ms) of the system clock. (Non-negative integer. Optional. Default: 12.)
nice: | If true, try to let other ruby threads run during the delay. (true or false. Optional. Default: false.)
Returns: | The actual delay time, in milliseconds.

Pause the program for `time` milliseconds. This function is more accurate than Clock.wait, but uses slightly more CPU time. Both this function and Clock.wait can be used to slow down the framerate so that the application doesn‘t use too much CPU time. See also Clock#tick for a good and easy way to limit the framerate.

This function uses "busy waiting" during the last part of the delay, for increased accuracy. The value of `gran` affects how many milliseconds of the delay are spent in busy waiting, and thus how much CPU it uses. A smaller `gran` value uses less CPU, but if it‘s smaller than the true system granularity, this function may delay a few milliseconds too long. The default value (12ms) is very safe, but a value of approximately 5ms would give a better balance between accuracy and CPU usage on most modern computers. A granularity of 0ms makes this method act the same as Clock.wait (i.e. no busy waiting at all, very low CPU usage).

If `nice` is true, this function will try to allow other ruby threads to run during this function. Otherwise, other ruby threads will probably also be paused. Setting `nice` to true is only useful if your application is multithreaded. It‘s safe (but pointless) to use this feature for single threaded applications.

The Rubygame timer system will be initialized when you call this function, if it has not been already. See Clock.runtime.

new() {|self if block_given?| ...}

Create a new Clock instance.

runtime()

Return the number of milliseconds since the Rubygame timer system was initialized.

The Rubygame timer system will be initialized when you call this function, if it has not been already.

wait( time, nice=false )

time: | The target wait time, in milliseconds. (Non-negative Integer. Required.)
nice: | If true, try to let other ruby threads run during the delay. (true or false. Optional.)
Returns: | The actual wait time, in milliseconds.

Pause the program for approximately `time` milliseconds. Both this function and Clock.delay can be used to slow down the framerate so that the application doesn‘t use too much CPU time. See also Clock#tick for a good and easy way to limit the framerate.

The accuracy of this function depends on processor scheduling, which varies with operating system and hardware. The actual delay time may be up to 10ms longer than `time`. If you need more accuracy use Clock.delay, which is more accurate but uses slightly more CPU time.

If `nice` is true, this function will try to allow other ruby threads to run during this function. Otherwise, other ruby threads will probably also be paused. Setting `nice` to true is only useful if your application is multithreaded. It‘s safe (but pointless) to use this feature for single threaded applications.

The Rubygame timer system will be initialized when you call this function, if it has not been already. See Clock.runtime.

### Public Instance methods

calibrate( max_time = 0.5 )

Calibrate some Clock settings to match the current computer. This improves efficiency and minimizes CPU usage without reducing accuracy.

As of Rubygame 2.5, this method calibrates @granularity. See tick and Clock.delay for more information about the effect of setting granularity. In future versions of Rubygame, this method may also calibrate additional Clock attributes.

By default, the calibration takes a maximum of 0.5 seconds to complete. You can specify a different maximum length by passing a different value for `max_time`. In future versions of Rubygame, calibration may take less than max_time, but will not take more. Also, the default max_time may be lowered in future versions, but will not be raised.

You usually only need to call this once, after you create the Clock instance at the start of your application. You should not run any other ruby threads at the same time, as doing so will skew the calibration.

enable_tick_events()

Enable tick events, so that tick will return a ClockTicked instance instead of a number of milliseconds.

This option is available starting in Rubygame 2.5, and will become the default in Rubygame 3.0.

framerate → Float

Return the actual framerate (frames per second) recorded by the Clock. See tick.

frametime → Float

Return the actual frametime (milliseconds per frame) recorded by the Clock. See tick.

lifetime → Integer

Returns time in milliseconds since this Clock instance was created.

target_framerate()

Returns the current target framerate (frames/second), or nil if there is no target.

This is another to access target_frametime. Same as: 1000.0 / target_frametime

target_framerate=( framerate )

Sets the target number of frames per second to `framerate`. If `framerate` is nil, the target is unset, and tick will no longer apply any delay.

This is another way to access target_frametime. Same as: target_frametime = 1000.0 / framerate

target_frametime()

Returns the current target frametime (milliseconds/frame), or nil if there is no target.

This is another way to access target_framerate. Same as: 1000.0 / target_framerate

target_frametime=( frametime )

Sets the target milliseconds per frame to `frametime`. If `frametime` is nil, the target is unset, and tick will no longer apply any delay.

This is another way to access target_framerate. Same as: target_framerate = 1000.0 / frametime

tick()

Returns the number of milliseconds since you last called this method. Or, if you have called enable_tick_events, this returns a ClockTicked event representing the time since you last called this method. (ClockTicked was added in Rubygame 2.5, and will become the default and only option in Rubygame 3.0.)

You must call this method once per frame (i.e. per iteration of your main loop) if you want to use the framerate monitoring and/or framerate limiting features.

Framerate monitoring allows you to check the framerate (frames per second) or frametime (milliseconds per frame) of your game.

Framerate limiting allows you to prevent the application from running too fast (and using 100% of processor time) by pausing the program very briefly each frame. The pause duration is calculated each frame to maintain a stable framerate.

Framerate limiting is only enabled if you have set the target_framerate= or target_frametime=. If you have done that, this method will automatically perform the delay each time you call it.

There are two other attributes which affect framerate limiting, granularity and nice. These are passed as parameters to Clock.delay for the brief pause each frame. See Clock.delay for the effects of those parameters on CPU usage and threading.

(Please note that no effort is made to correct a framerate which is slower than the target framerate. Clock can‘t make your code run faster, only slow it down if it is running too fast.)

[Validate]