From: Daniel Sheppard Date: 2005-11-11T13:35:00+09:00 Subject: Re: Accurate Timing in ruby 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. #####################################################################################