600fps! 30fps is enough. :)
by Charlie Patterson · in Torque Game Builder · 07/14/2011 (2:47 pm) · 9 replies
I've noticed that TGB can run my desktop CPU at 100% in editor and in game. Using a MacBook, it also runs 100% and gets pretty hot!
Today I turn on "debug banner" for the first time and notice that it shows 600fps in my game AND in the editor. (The debug banner shows in the editor scene, not just in the final running game scene.)
So my question is, does TGB have to try and get max frame rate? I'm happy with 30fps and even prefer it. How can I set the max?
Thanks for any help!
Today I turn on "debug banner" for the first time and notice that it shows 600fps in my game AND in the editor. (The debug banner shows in the editor scene, not just in the final running game scene.)
So my question is, does TGB have to try and get max frame rate? I'm happy with 30fps and even prefer it. How can I set the max?
Thanks for any help!
#2
Ive posted about similar issues in T3D areas, in that using Vsync actually synchs the entire game slowing down in certain areas, if the same condition exists for TGB then you have potential problems with AI and physics.
I dont know about ATI, but the nvidia control panel will allow you to over-ride game settings and force vsynch on, which as far as i know doesnt meddle with the rest of the game, only a rendering throttle. (i'm pretty sure it doesnt work with opengl either or at least it didnt when i tried it cannot remember what driver version that was)
07/15/2011 (12:22 pm)
Would that not slow down *everything* though not just framerates? Ive posted about similar issues in T3D areas, in that using Vsync actually synchs the entire game slowing down in certain areas, if the same condition exists for TGB then you have potential problems with AI and physics.
I dont know about ATI, but the nvidia control panel will allow you to over-ride game settings and force vsynch on, which as far as i know doesnt meddle with the rest of the game, only a rendering throttle. (i'm pretty sure it doesnt work with opengl either or at least it didnt when i tried it cannot remember what driver version that was)
#3
This causes me to get between 30'ish and 80'ish FPS. I guess the 80'ish ones are when mouse events and stuff are used and interrupt the "wait" that is placed in the C++ rendering code. Not so bad.
07/15/2011 (1:06 pm)
@Alain: Cool! Thanks! I had attempted to find out by reading the C++ but got lost in the indirections.This causes me to get between 30'ish and 80'ish FPS. I guess the 80'ish ones are when mouse events and stuff are used and interrupt the "wait" that is placed in the C++ rendering code. Not so bad.
#4
07/15/2011 (1:11 pm)
@Bloodknight, interesting point. I think for my purposes, I'm OK. I was getting 600fps consistently, so I'm not worried about my scripts and rendering running then a pause to fill up 32ms.
#5
This is actually fairly common for games. Unlike desktop applications primarily intended to be able to work in parallel, games usually don't have to share their CPU time, so they tend to take as much "room" as they can to handle rapid load changes smoothly.
ProcessInterval should be acceptable as a qick solution, if only it counts for Macs. I suggest adding dynamic delay calculation though, and leave a bit of extra time for the engine to smooth down load peaks.
07/15/2011 (1:43 pm)
Just cutting down frames displayed won't save any CPU time. It also improbably that engine _can_ shoot out enough quads to cause noticeable load on the video card, TGB games are no graphically intensive type. CPU load is the problem.This is actually fairly common for games. Unlike desktop applications primarily intended to be able to work in parallel, games usually don't have to share their CPU time, so they tend to take as much "room" as they can to handle rapid load changes smoothly.
ProcessInterval should be acceptable as a qick solution, if only it counts for Macs. I suggest adding dynamic delay calculation though, and leave a bit of extra time for the engine to smooth down load peaks.
#6
@Bloodnight -- Vsync does work on ATI with Opengl but Charlie wanted 30fps and the Vsync option would have synced his game to the monitor's refresh rate. Which is probably going to be 60fps or greater.
@Rpahut -- In TGB, cutting down frames displayed does save CPU time. If you want to verify this just open Task Manager and take a look at the cpu load while your game is running...Try running with an without frame rate throttling and you will notice a dramatic drop in cpu load. Just make sure your game window has focus or else you will have erroneous results.
In mobile games, overloading the cpu, drains the battery...so limiting frame rate -> reduces cpu load -> helps conserve battery life.
07/15/2011 (2:32 pm)
@Charlie -- Your welcome.@Bloodnight -- Vsync does work on ATI with Opengl but Charlie wanted 30fps and the Vsync option would have synced his game to the monitor's refresh rate. Which is probably going to be 60fps or greater.
@Rpahut -- In TGB, cutting down frames displayed does save CPU time. If you want to verify this just open Task Manager and take a look at the cpu load while your game is running...Try running with an without frame rate throttling and you will notice a dramatic drop in cpu load. Just make sure your game window has focus or else you will have erroneous results.
In mobile games, overloading the cpu, drains the battery...so limiting frame rate -> reduces cpu load -> helps conserve battery life.
#7
I have done zero to optimize.* Currently, some points of my game send out dozens of pickLine's and onCollisions and onUpdates per frame with no problem.
I do plan to throttle framerate upon release b/c my user gets no benefit from 100s of fps. All they get is an overheated computer.
Finally, I think I've noticed that my game shows things I don't want to see. If I clone an object and rotate it in one method, I sometimes see it on screen before the rotation and then after rotation?! This is horrible if I'm right! It appears that the engine is drawing, as fast as it can, whatever it sees in the scene graph DURING my scripting, but the scripting should be "between frames". Yuck! Can anyone verify this?
* what with premature optimization being the root of all evil
07/15/2011 (3:59 pm)
@Rpahut and @Alain: thanks Alain. I'd add that showing 30% CPU on (1 core of) my Phenom II X4 970 3.5Ghz gives me hope that my game will run fine on 2 or 3 year old laptops. So I'm also getting some cheap perf testing.I have done zero to optimize.* Currently, some points of my game send out dozens of pickLine's and onCollisions and onUpdates per frame with no problem.
I do plan to throttle framerate upon release b/c my user gets no benefit from 100s of fps. All they get is an overheated computer.
Finally, I think I've noticed that my game shows things I don't want to see. If I clone an object and rotate it in one method, I sometimes see it on screen before the rotation and then after rotation?! This is horrible if I'm right! It appears that the engine is drawing, as fast as it can, whatever it sees in the scene graph DURING my scripting, but the scripting should be "between frames". Yuck! Can anyone verify this?
* what with premature optimization being the root of all evil
#8
Some drivers may hold a call to SwapBuffer() back I believe, until frame is displayed. Pretty much like ProcessInterval, but with less control on how much time game spends doing nothing. I say no to VSync for these reasons.
@Charlie I still wondering if game engine is a tool of choice for what you're creating there. TGB is, just like any other game engine, all about displaying (somehow) complex and smooth animations, thus the need for lots of extra power. It is not wasted in any way, it's just a reserve required to keep up to the display refresh rate with everything you can throw at it. Making something like desktop application with game engine will raise lots of tiny problems, just because it has different purpose.
07/17/2011 (2:59 pm)
@Alain I was talking about VSync there. For me it does nothing, graphics driver just drops some frames apparently, while engine keeps calculating them at the same rate.Some drivers may hold a call to SwapBuffer() back I believe, until frame is displayed. Pretty much like ProcessInterval, but with less control on how much time game spends doing nothing. I say no to VSync for these reasons.
@Charlie I still wondering if game engine is a tool of choice for what you're creating there. TGB is, just like any other game engine, all about displaying (somehow) complex and smooth animations, thus the need for lots of extra power. It is not wasted in any way, it's just a reserve required to keep up to the display refresh rate with everything you can throw at it. Making something like desktop application with game engine will raise lots of tiny problems, just because it has different purpose.
#9
In short:
@rpahut, I am indeed making a game. Tvs, movies, flight simulators: all run at 30fps because that is at the limit of what people can see. Any more is a waste of cpu cycles. Sorry for the curt answer, but I don't want to retype the 5 paragraph version. (And now I will copy this to my clipboard before posing.)
07/18/2011 (1:50 pm)
Ahhh! This damn forum threw away yet another of my lengthy and very worthwhile posts! :P LOGIN ON HERE SUCKS!In short:
@rpahut, I am indeed making a game. Tvs, movies, flight simulators: all run at 30fps because that is at the limit of what people can see. Any more is a waste of cpu cycles. Sorry for the curt answer, but I don't want to retype the 5 paragraph version. (And now I will copy this to my clipboard before posing.)
#10
The "eye" receptor does not actually work in "frames", but instead receives a continuous flow of light, to which various sensors react with different response times.
The quality of the perceived motion directly relates to the physical distance objects travel in front of the eye vs. sampling rate.
This explains why recent TVs have been including new features to compensate for their larger sizes (motion blur, image interpolation, higher refresh rate, etc.).
A "fast" object displayed at a "slow" sampling rate (slow being relative to the speed of the object in eye-space, some more signal processing references needed here...) will produce a "judder" effect.
Wikipedia links to the following applet to demonstrate the effect:
frames-per-second.appspot.com/
it lets the user experiment with framerate, motion interpolation, etc.
Anyway, my point was not to restart the eternal "30fps vs. motion perception" debate :) , but my position is that from a user experience point of view the only thing that should be capped in a real-time application is probably the physics simulation (for stability purposes)
Requirements for tools, interactive applications, non interactive ones (movies), etc. are all slightly different though.
07/22/2011 (9:45 am)
Frame rate, persistence of vision and perception of motion are different things.The "eye" receptor does not actually work in "frames", but instead receives a continuous flow of light, to which various sensors react with different response times.
The quality of the perceived motion directly relates to the physical distance objects travel in front of the eye vs. sampling rate.
This explains why recent TVs have been including new features to compensate for their larger sizes (motion blur, image interpolation, higher refresh rate, etc.).
A "fast" object displayed at a "slow" sampling rate (slow being relative to the speed of the object in eye-space, some more signal processing references needed here...) will produce a "judder" effect.
Wikipedia links to the following applet to demonstrate the effect:
frames-per-second.appspot.com/
it lets the user experiment with framerate, motion interpolation, etc.
Anyway, my point was not to restart the eternal "30fps vs. motion perception" debate :) , but my position is that from a user experience point of view the only thing that should be capped in a real-time application is probably the physics simulation (for stability purposes)
Requirements for tools, interactive applications, non interactive ones (movies), etc. are all slightly different though.
Torque Owner Alain Labrie
Ware-Wolf Games
to your preferences.