Limiting FPS
by Garrett Brown · in Torque Game Builder · 05/22/2006 (7:40 am) · 7 replies
Hello!
I'm getting close to finishing up my first game, tentatively title Gendale. It's been a bit of a long road, but it's a great experience using TGB.
Before I get to release status, however, I want to limit the FPS of the game to 60 fps so that it will perform the same or similar across all different types of machines. As of right now, a high end PC will cause the game to run way too fast. At first, I tried a basic way of doing this:
in T2D/game/main.cc, line 342
Thanks,
-G
I'm getting close to finishing up my first game, tentatively title Gendale. It's been a bit of a long road, but it's a great experience using TGB.
Before I get to release status, however, I want to limit the FPS of the game to 60 fps so that it will perform the same or similar across all different types of machines. As of right now, a high end PC will cause the game to run way too fast. At first, I tried a basic way of doing this:
in T2D/game/main.cc, line 342
while(Game->isRunning())
{
// My Change
S32 start = Platform::getRealMilliseconds();
// end My Change
PROFILE_START(MainLoop);
PROFILE_START(JournalMain);
Game->journalProcess();
PROFILE_END();
PROFILE_START(NetProcessMain);
Net::process(); // read in all events
PROFILE_END();
PROFILE_START(PlatformProcessMain);
Platform::process(); // keys, etc.
PROFILE_END();
PROFILE_START(TelconsoleProcessMain);
TelConsole->process();
PROFILE_END();
PROFILE_START(TelDebuggerProcessMain);
TelDebugger->process();
PROFILE_END();
PROFILE_START(TimeManagerProcessMain);
TimeManager::process(); // guaranteed to produce an event
PROFILE_END();
PROFILE_START(GameProcessEvents);
Game->processEvents(); // process all non-sim posted events.
PROFILE_END();
PROFILE_END();
// My Change
while ((Platform::getRealMilliseconds() - start) < 15){}
// end My Change
}I knew it wouldn't be the most effecient thing, but I thought it was worth a try. While it does limit the FPS, it also takes valuable ticks away from the Physics, making my ColHit% around 30%. I need a lot of ticks for Physics because I'm doing rigid body so I'm stuck here. I'm not sure how to limit the FPS and still allow the physics to do it's "thing". Can anybody help?Thanks,
-G
About the author
I work at n-Space, located in Orlando, FL as a designer. When I'm not there, I work on side projects, generally using TGB. Side projects I've finished are Oddictive, Klockotock, and AstroDriller3020
#2
05/22/2006 (2:57 pm)
Yeah, the cause of the problem is that the while loop I put in there is doing absolutely nothing for a certain amount of time (specified by the 15). You could probably get away with something like that in a game that is not as intensive as mine, but I need all the extra ticks I can get for physics, meanwhile limiting the FPS on everything else.
#3
05/22/2006 (3:11 pm)
Actually I meant the root cause of why your simulation isn't working right and you feel it necessary to limit the FPS. Ideally TGB would run the highest FPS possible and your game would also run consistently on all platforms. I guess this is implicit to your question or has been covered in other forum threads. Just thinking out loud I guess . Thanks
#4
I don't know too much about physics. It performs best at a small and constant intervall. Maybe set it to 100, 150 or 200. Something that can be reached by all of your target systems. Maybe you can achieve something like an controlled underrun with a combination of $Pref::timeManagerProcessInterval (which will affect everything in the engine, not only TGB physics) and the t2dSceneGraph::setScenePhysicsFpsActive() commands. So that if you do something like this:
As the actual fps of the game is limited by $Pref::timeManagerProcessInterval it will always be smaller than physics limit of the scenegraph. This causes the physics system to split every frame into 2 frames (only for the physics system). So your physics will run at double frame-rate all the time.
I have not tried this though. It may work or not.
-Michael
05/22/2006 (3:41 pm)
You don't need to hack the engine to get the effect above. Just set $Pref::timeManagerProcessInterval to 15. That will do essentially the same. I don't know too much about physics. It performs best at a small and constant intervall. Maybe set it to 100, 150 or 200. Something that can be reached by all of your target systems. Maybe you can achieve something like an controlled underrun with a combination of $Pref::timeManagerProcessInterval (which will affect everything in the engine, not only TGB physics) and the t2dSceneGraph::setScenePhysicsFpsActive() commands. So that if you do something like this:
// set the whole engine to 60 fps $Pref::timeManagerProcessInterval = 15; //tell the scenegraph to iterate when under 119 fps $yourSceneGraph.setScenePhysicsLimitFPS( 119 ); //set the target fps for the physics to 120 $yourSceneGraph.setScenePhysicsTargetFps(120); //set max iterations 2 $yourSceneGraph.setScenePhysicsMaxIterations( 2 );
As the actual fps of the game is limited by $Pref::timeManagerProcessInterval it will always be smaller than physics limit of the scenegraph. This causes the physics system to split every frame into 2 frames (only for the physics system). So your physics will run at double frame-rate all the time.
I have not tried this though. It may work or not.
-Michael
#5
Woops, I misunderstood you. To answer your question, no, I don't really understand why it runs so differently across different machines. I was guessing it should, but it seems that my objects just weren't getting updated as fast on slower machines as they were on fast machines. This is usually an issue with the physics not being timed based, but it certainly seems that TGB's physics are, and I was just missing something. Thanks for the help though!
@Michael:
This is seeming to work out for me. For the past 3 hours, I've been toying with those functions, but not really understanding what they are doing. I guess I should look into what iterations are and what they mean. I had no idea about the timeManagerProcessInterval, and I thank you for pointing me toward it. I'll be tweaking a little bit here and there, but this is definetly a step in the right direction. Thanks again!
-G
05/23/2006 (8:42 am)
@ Alex:Woops, I misunderstood you. To answer your question, no, I don't really understand why it runs so differently across different machines. I was guessing it should, but it seems that my objects just weren't getting updated as fast on slower machines as they were on fast machines. This is usually an issue with the physics not being timed based, but it certainly seems that TGB's physics are, and I was just missing something. Thanks for the help though!
@Michael:
This is seeming to work out for me. For the past 3 hours, I've been toying with those functions, but not really understanding what they are doing. I guess I should look into what iterations are and what they mean. I had no idea about the timeManagerProcessInterval, and I thank you for pointing me toward it. I'll be tweaking a little bit here and there, but this is definetly a step in the right direction. Thanks again!
-G
#6
Your results may be interesting for others too. Be sure to post them here :)
05/23/2006 (11:41 am)
@GarrettYour results may be interesting for others too. Be sure to post them here :)
#7
05/23/2006 (4:13 pm)
tdn.garagegames.com/wiki/T2D/FAQ/Physics/Timing_issues saysQuote:You should have consistency, independent of OS or timings as long as the relative FPS differences are not too extreme. Although, even then, the differences shouldnt be that noticable.
Torque Owner Alex Rice
Default Studio Name