Game Development Community

Any faster ways to get angle between 2 points?

by Ezra · in Torque Game Builder · 01/22/2006 (1:09 pm) · 1 replies

%angle = mRadToDeg( mAtan( %mxpos-%px, %py-%mypos ) );

I'm wondering if there are any faster ways to get the angle between 2 points, or if I should make a specific function in c++ to do this rather than doing it in TorqueScript (if that will make any difference).
I'm using this on sometimes 50+ objects each update scene, to get the angle between tank turrets and the player, it's a little bit of a performance hit and there might be a smarter way to do it that I don't know of.

*edit*
well, i've just made it so the tanks don't update their angle each update scene, they do it every 2 seconds now based on their own ticker that compares itself with the SceneTime, so if the player doesn't move at all they will rotate to where he is.

I'm still curious if there are any better ways to getting an angle though..

#1
01/25/2006 (8:25 pm)
There's "t2dAngleBetween()" that takes two t2dVectors. That's probably as fast as you're going to get calling through script. I use schedules a lot for this sort of thing. Another thing you can do is offset the schedules so that they aren't always lumped close together. If your units are getting created incrementally, then this should happen automatically.

In other words, I'd avoid a big loop that iterates through all the objects and calls new schedules all at once. Better to do this when an object is created, so that they aren't all updating themselves at once. There is also a new method on t2dSceneObject called "setTimerOn()" that works like schedule, but you can set it per object.

On the C++ side, you could write something like the "rotateTo" method that's already on t2dSceneObject, but more like a "lookAt" that takes a ref to another t2dSceneObject. That shouldn't be too hard actually. That would keep all the calls from going through the script interface.

As you've found, calling tons of functions every frame is bad news. T2D is good this way in that it has a lot of tools for setting forces or behaviors that do their thing over time, so you're not having to set values constantly.

In your case, you should be able to do your calculations more often than every two seconds, especially if they are offset. 33ms would be 30 fps update, and still gives a lot of time for the engine to do its stuff. That would be plenty fast. I've done look-at script functions that update 66-100ms range and it looks completely smooth.