How to stay at 60 fps, not go higher?

#1 In TimeManager::process() in winWindow.cpp:

// The number of frames per second to target in the 
// frame rate limiter in TimeManager::process().
static S32 smFrameLimiter = 60;
 
void TimeManager::process()
{
   // Note: This is a simple frame rate limiter which 
   // sleeps off excess milliseconds when the elapsed 
   // time is less than 1/60th of a second.
   //
   // This is critical on single core CPUs which need
   // the free cycles to process the other threads that
   // are active in your game.
   //
   // It can be disabled by setting smFrameLimiter to a
   // high rate like 1000 fps when you need to do 
   // rendering performance testing, but it should not 
   // be removed.
   //
   #ifndef TORQUE_NVPERFHUD
 
      smFrameLimiter = getMax( 1, smFrameLimiter );
      S32 sleepTime = ( 1000 / smFrameLimiter ) - gTimer.getElapsedMS();
      if ( sleepTime >= 0 )
         Platform::sleep( sleepTime );
 
   #endif
 
   TimeEvent tEvent;
   tEvent.elapsedTime = gTimer.getElapsedMS();
   // etc.

... you can also optionally add this to Platform::init() to expose the setting to script:

// For frame rate limiting in TimeManager::process().
   Con::addVariable( "$Platform::frameLimiter", TypeS32, &smFrameLimiter );

#2 Great, thanks so much Tom! Much appreciated.

#3 Hi Tom, I appreciated the reply, but I'm afraid I still need some help, if you may lend your brain again :).

The above function "process()" is not available in winWindow.cpp. I only found it in X86UNIXWindow.cpp, and it looks quite different.

Next problem was that gTimer is an undeclared variable. PlatformTimer.h has a pointer for the TimeManager called "mTimer"

Did you implement this yourself? Any ideas on how to integrate this, only to affect the draw call, would be really helpful.

Thanks much

#4 I appologize that code was for a pre-Torque 1.7 code base.

Looking in TGEA 1.8 beta (but probably also in 1.7) it seems like it already has this feature in TimeManager::_updateTime().

You need to adjust mForegroundThreshold to 16 which gives you about 60fps limiting of frame rate. mBackgroundThreshold is for when the game does not have focus and is in the background.

These values are not exposed to script... probably something lost in the merge from TGB (which is where i think this code came from).

#5 Worked like a charm ;).

Thanks Tom

#6 Out of curiosity, what's the benefit of capping FPS?

#7 If you free up CPU time spent in wasted rendering (arguably anything over 60fps is a waste) you have given yourself more cycles for other threaded tasks like physics, AI path finding, skinning, etc.

#8 Yes, that was my intention, as Tom explained. If you ever work on a 360 title, the rule/goal is 60 fps. Older games were usually 30 fps. Taking that movie film is 24 fps, and TV is traditionally 30 fps. The eye reacts a certain way to framerates. 60 is a very pleasing fps.

On the other hand, that theory isn't holding up practically for me right now! In my top-down view game, when I limit to 60fps, it looks rather jarring. I'm not sure if it is graphical artifacts, or periodic delays per second.

Everything is fine in first person view. I'll post a video soon, its really weird.