Smoothing the Renderer
by Jason Gossiaux · in Torque Game Engine · 12/01/2007 (2:08 am) · 1 replies
I have been having some difficulty understanding how the engine goes about the rendering process. Specifically with regards to the framerate. I wanted to know what methods might exist for smoothing out the framerate while processing things in other parts of your code.
For example I've been starting to experiement with AI and pathfinding routines. Unfortunately some of my functions can take 20-30ms to do a complex calculation. During this time the renderer obviously isn't running, and so the user sees a small hiccup. This can get quite annoying if it happens too often and makes the game unplayable.
So one option is to reduce the calculation time or break it up into parts, say 3 runs at 10ms each. Maybe if I use global variables and only perform part of the calculation at a time it will be more manageable. The problem is that seems somewhat obtuse. It would become a burden to split up every single time consuming task and to maintain some semblance of run order.
The other option would be to write these routines in Torquescript. My concern there is the script itself is a level removed and therfore slower. I am also not sure if the Torquescript is threaded, or runs outside of the renderer. Will a long pause there be as noticeable?
Lastly, I think slowing down the render speed might help. 30fps is 1 frame rendered every 33ms, wheras 150fps is 1 frame rendered every 6ms. It is harder to detect 1 dropped frame than it is to detect 5. So if I could clamp the framerate to a maximum that might help.
In what ways do people get around this issue? I've seen many games and demos that run at low framerates (which indicates they are doing a lot of things in the background) but no noticeable hiccuping. There must be something I'm missing...
Thanks in advance for any help you can give me.
For example I've been starting to experiement with AI and pathfinding routines. Unfortunately some of my functions can take 20-30ms to do a complex calculation. During this time the renderer obviously isn't running, and so the user sees a small hiccup. This can get quite annoying if it happens too often and makes the game unplayable.
So one option is to reduce the calculation time or break it up into parts, say 3 runs at 10ms each. Maybe if I use global variables and only perform part of the calculation at a time it will be more manageable. The problem is that seems somewhat obtuse. It would become a burden to split up every single time consuming task and to maintain some semblance of run order.
The other option would be to write these routines in Torquescript. My concern there is the script itself is a level removed and therfore slower. I am also not sure if the Torquescript is threaded, or runs outside of the renderer. Will a long pause there be as noticeable?
Lastly, I think slowing down the render speed might help. 30fps is 1 frame rendered every 33ms, wheras 150fps is 1 frame rendered every 6ms. It is harder to detect 1 dropped frame than it is to detect 5. So if I could clamp the framerate to a maximum that might help.
In what ways do people get around this issue? I've seen many games and demos that run at low framerates (which indicates they are doing a lot of things in the background) but no noticeable hiccuping. There must be something I'm missing...
Thanks in advance for any help you can give me.
About the author
Torque Owner Michael Bacon
Default Studio Name
The other approach is to figure out why your complex calculations are taking so long in the first place. If your calculating THAT much information you should be getting alot more bang for your buck than just a couple of AIs running around.
Finally, writing it in Torque Script isn't going to help at all because the Torque Game Engine is single threaded by nature and doesn't run script in a thread either.
Split split split. Its not obtuse its the proper way to do things. Oh, and don't use globals either. Save your state information each frame and pickup where you left off.
Oh and if you need to perform the same time consuming calculation for every bot, make sure they don't all do it on the same frame.