How expensive is the onUpdate function?
by Eric Bakutis · in Torque Game Builder · 06/11/2011 (8:31 pm) · 3 replies
Just hoping for some wisdom from those who have been working with TorqueGameBuilder longer than myself. I'm fairly familiar with Torquescript, but not with its little idiosyncrasies.
I'm playing with a standard top down shooter. For player movement, I'm using the onUpdate callback because it makes things silky smooth, and I want to make sure the player ship movement is responsive. Thus far, I've steered away from using it on anything else (since it is disabled by default, I assume it is fairly expensive).
That said, I'm curious if anyone has had experience seeing how far they can push onUpdate in a scene. I figure I'll have anywhere from 5-20 objects on screen at any time, including the player. How much could I get away with in using onUpdate to make enemy ships track player movement? 1? 2? 5?
Finally, how does onUpdate compare to other functions, such as onTimer? I'm assuming onTimer is less expensive, but if you start calling it fairly often (say, 500 ms) I'm wondering how much performance you get in comparison to onUpdate.
Anyway, I'd love it if anyone can provide some general information (or just point me to a post) talking about what sort of behavior I can expect if I start using it for more than the player. Thanks!
I'm playing with a standard top down shooter. For player movement, I'm using the onUpdate callback because it makes things silky smooth, and I want to make sure the player ship movement is responsive. Thus far, I've steered away from using it on anything else (since it is disabled by default, I assume it is fairly expensive).
That said, I'm curious if anyone has had experience seeing how far they can push onUpdate in a scene. I figure I'll have anywhere from 5-20 objects on screen at any time, including the player. How much could I get away with in using onUpdate to make enemy ships track player movement? 1? 2? 5?
Finally, how does onUpdate compare to other functions, such as onTimer? I'm assuming onTimer is less expensive, but if you start calling it fairly often (say, 500 ms) I'm wondering how much performance you get in comparison to onUpdate.
Anyway, I'd love it if anyone can provide some general information (or just point me to a post) talking about what sort of behavior I can expect if I start using it for more than the player. Thanks!
About the author
#2
06/19/2011 (3:16 pm)
Thanks for the reply! I've been experimenting with both onUpdate and onTimer, and I think I've found a good balance for now. I'm making fairly good progress with my little 2D shooter. I guess the real test will come when I try to run the game on a computer that doesn't have nice specs. :) 
#3
06/20/2011 (7:58 am)
Like smally said. Something you could look up is the discussion on use of the onHeartbeat() function in Neverwinter Nights scripting. It has a similar issue with potential impact on performance. The more objects you use this callback for each frame the more processing that goes into each frame. Moving and colliding already use up a given amount of processor time each frame per object and anything else you do per frame just adds to it. 
Torque Owner smally
TBD
onTimer can be a decent approach to solving some issues in a game. Just try to remember, you can weigh down any function with big loops and massive logic inside them.
This could cause a major issue inside of an OnTimer function just as easily as it could onUpdate.
If you start slowing down or loosing performance, take a look over your algorithms and see what you can speed up or, possibly, remove completely. If you've hit that wall of "I can't possibly make this any better" in the script, it's about time that you move the major time consuming pieces of the code into C++ and compile it. 5-20 enemies though, I can't imagine you having any slowdowns w/ decent to the point script code in either onUpdate or onTimer.
It's not a don't believe it's horrible advice either. Doing this, you should be just fine ;)