Accurate Timing in ruby

ruby-talk
1

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.

···

-----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?

---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.

#####################################################################################
This email has been scanned by MailMarshal, an email content filter.
#####################################################################################

2

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

3

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.

Here's a pretty mundane implememtation of that idea, which has been
useful to me in some quasi-real time work. Hope it helps somebody.

http://redshift.sourceforge.net/timer/timer.rb

On a 1.7GHz Pentium, running linux 2.6.10, the timer can keep fairly
good time with a period of 50 microseconds, as long as you aren't doing
much else. It starts slipping as you get close to 10 microsec (running
as nice -n -20). I guess that gives a rough estimate of the overhead.

require 'timer'

count = 0
period_usec = 50.0 # microsec
period = period_usec / 1_000_000
duration = 10.0

Timer.every period, duration do
  count += 1
end

p count
p duration/period

···

--
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407