Script math too slow
by John Olsen · in Torque Game Builder · 01/05/2007 (9:11 pm) · 6 replies
I've been tinkering with an 8x8 array of sprites, and everything updates really nicely on a 16 ms timer (60 hz). That is, until I start doing math inside the timer callback. mSin, mCos, or any similar function call suddenly drag the application to its knees. I think it gets to the point that the timer is going off again on the next round before every object's callback has been run, then things stop working.
Am I just expecting too much, running 64 sprite updates at 60 hz? I can do all that and a lot more with direct c++ or c# code and not run out of processor, but in script it just seems too slow.
John
Am I just expecting too much, running 64 sprite updates at 60 hz? I can do all that and a lot more with direct c++ or c# code and not run out of processor, but in script it just seems too slow.
John
#2
Is there an easier way than SetTimerOn() to get something to run either once per tick or once per frame? It may be that the overhead of having timers set up on all 64 objects is eating up too much time as well. I can update all objects from a single callback if there's an easy way to hook in.
John
01/05/2007 (9:39 pm)
I've backed my timer off to 32 ms, which gives it more time, but I'll still have to avoid serious math.Is there an easier way than SetTimerOn() to get something to run either once per tick or once per frame? It may be that the overhead of having timers set up on all 64 objects is eating up too much time as well. I can update all objects from a single callback if there's an easy way to hook in.
John
#3
Depending on the amount you do, this would even give you an easy point to do your C++ coding by simply coding the needed function in C++ and call it with your simset in the callback.
01/06/2007 (1:39 am)
Yupp there actually is. You could use t2dSceneGraph::onUpdateScene() callback and use a SimSet which holds all "updateable" sprites you have and then call the needed function on those sprites or depending on what you actually want to do perhaps perform the calculation even in the update scene callback.Depending on the amount you do, this would even give you an easy point to do your C++ coding by simply coding the needed function in C++ and call it with your simset in the callback.
#4
T.
01/06/2007 (1:49 am)
You don't need to use onUpdateScene() ... just stick everything in a SimSet, write a custom ITickable object that uses it and do all your timing/expensive processing in C++. You don't need to drop into script at all other then for managing the objects in the set. Calling into script and then calling back into C++ for this is just a waste of CPU cycles that can be better spent doing other things.T.
#5
I don't know if that'd cause other overheads in TGB (memory/speed of grabbing from a big array), but I'm pretty sure it was a way that old-skool programmers used to squeeze a little more speed out of code when mhz processors were a dream...
Minty
01/06/2007 (2:28 am)
I'm new to TGB and kind of shooting from the hip here, but if you don't need really granular trig functions (eg: you only need them to the nearest degree), you might find things faster with a lookup table. That is, precalculate sin and cos of the angles and store them in a big array. I don't know if that'd cause other overheads in TGB (memory/speed of grabbing from a big array), but I'm pretty sure it was a way that old-skool programmers used to squeeze a little more speed out of code when mhz processors were a dream...
Minty
#6
Depending on if you have a source code license (Pro license) or not, that is a quite excellent suggestion--and he's right: lookup tables were used (and in some cases still are) for pre-calculating all sorts of high performance requirement calculations--and you don't really need to limit yourself to degrees. I could see a rather large but easily useable table of functions down to the tenth.
Of course, if you do have a source code license, you should certainly follow Tom's recommendations and do your highly intensive calculations in c++.
01/06/2007 (11:55 am)
Quote:
I'm new to TGB and kind of shooting from the hip here, but if you don't need really granular trig functions (eg: you only need them to the nearest degree), you might find things faster with a lookup table. That is, precalculate sin and cos of the angles and store them in a big array.
I don't know if that'd cause other overheads in TGB (memory/speed of grabbing from a big array), but I'm pretty sure it was a way that old-skool programmers used to squeeze a little more speed out of code when mhz processors were a dream...
Minty
Depending on if you have a source code license (Pro license) or not, that is a quite excellent suggestion--and he's right: lookup tables were used (and in some cases still are) for pre-calculating all sorts of high performance requirement calculations--and you don't really need to limit yourself to degrees. I could see a rather large but easily useable table of functions down to the tenth.
Of course, if you do have a source code license, you should certainly follow Tom's recommendations and do your highly intensive calculations in c++.
Torque 3D Owner Tom Bampton
Script is fast, but it was not intended for time critical code. You are basically doing a ton of really heavy processing twice every tick. Thus you are likely overrunning the tick and causing the aforementioned really bad things to happen.
Furthermore, schedules only get checked once every tick. That is part of the processing Torque must do during a tick. Using schedule() for very short durations is a really bad idea. Using schedule() for durations less then 1 tick is an extremely bad idea. The only exception to that is specifying zero for the time, which will cause the schedule to execute on the next tick or thereabouts. Note that if you have multiple short duration schedules, you're in for even more hell.
If you really need such time critical stuff then you should be doing it in C++. You can use ITickable to get decent timing. There's a TDN article on ITickable, I suggest you read it. Once you've read that page, you can use processTick() and interpolateTick() to do what you need. You should probably also aggregate as much of the processing as you reasonably can.
T.