From: Eero Saynatkari <ruby-ml@...>
Date: 2005-11-11T14:05:34+09:00
Subject: Re: Accurate Timing in ruby

Daniel Sheppard wrote:
> You shouldn't time your game in terms of seconds - time it in terms of
> "game time" - give it a target FPS, but let it go slower.
> 
> Each 'game logic' turn should measure the start and end time, subtract
> the execution time from the target FPS and then sleep for the period of
> time to make up the difference. Instead of extrapolating the FPS from
> the time of the current frame, just keep a running count of frames, and
> reset the count once you've entered the next second.

Each cycle also known as a 'tick', if the OP wants to google around.


>>-----Original Message-----
>>From: Eric Hofreiter [mailto:erichof425@yahoo.com] 
>>Sent: Friday, 11 November 2005 3:03 PM
>>To: ruby-talk ML
>>Subject: Accurate Timing in ruby
>>
>>Believe it or not, I'm attempting to make an action-driven 
>>game with ruby.  Is there a way to get the time in 
>>milliseconds since the program started, or something similar? 
>> I've tried using Time.now.to_f, but all too often that value 
>>will be the same in two consecutive update calls, causing 
>>jumps in motion and "infinite" fps readings.
>> 
>>Also, will extending calculation-heavy classes to C up the 
>>performance enough to make a fairly sophisticated game run?  
>>I'm talking like maybe a NES sports game as far as complexity 
>>goes.  For example, a vector class has about 15-20 methods 
>>that all do a few simple computations.  Would C significantly 
>>speed that up or would the fact that ruby still has to make 
>>the calls bog it back down?

E