Not sure if that counts as “simple”, but I’m using an iterative way for replacing arctan2 in Escarmouche:
here
You have an angle ANGLE, relative to the world’s angle (so 0 means you look to the right, 180 to the left, 90 to the top. Might be different depending on your coordinate system, especially with Y sign)
You have a target vector (from Dest to Target, DEST_TO_TARGET)
You get the ANGLE’s vector, using fast cos/sin, ANGLE_VECTOR (if ANGLE is 0, you’ll get 1, 0)
You calculate the 2D cross product of ANGLE_VECTOR with DEST_TO_TARGET, assign to LATERAL_DEVIATION : ANGLE_VECTOR.x * DEST_TO_VECTOR.y - ANGLE_VECTOR.y * DEST_TO_VECTOR.x
Now, it gets very interesting:
if LATERAL_DEVIATION is 0, both ANGLE_VECTOR and DEST_TO_TARGET are perfectly aligned.
If LATERAL_DEVIATION is negative, (for instance, DEST_TO_VECTOR is 1, 0, and ANGLE_VECTOR is 0.9, 0.1), that means your ANGLE_VECTOR is actually to far on the left.
So you subtract an increment for your angle.
If LATERAL_DEVIATION is positive, (for instance, DEST_TO_VECTOR is 1, 0, and ANGLE_VECTOR is 0.9, -0.1), that means your ANGLE_VECTOR is actually to far on the right.
So you add an increment for your angle.
All of these only use a lookup table (cos/sin), 2 multiplications, some addition/substraction, comparisons and PoT divisions (but not necessarily if you’re clever enough).
With only an additional multiplication+comparison involving LATERAL_DEVIATION, you can know if the angle between both vectors is greater or lower than a given angle - because it’s then a ratio.
I use it to make the units rotate slower when they need to “aim”.
Also, units don’t move “toward” if their not “facing enough” their target. This to avoid the “waltz bug” where everyone rotate around each others
It’s excellent for rotating once or twice per frame. Getting an exact angle can be done with this too, but a direct lookup table might be best.
(btw, you can also use the dot product to know if you’re looking toward or away from a target!)
Think of it as a robot following a line using with 2 color sensors.
Because it’s iterative, it’s excellent for Escarmouche - units rotate slowly toward their target then seek it. With a few iterations it can completely replace a proper arctan2, but lookup tables might be more interesting for you
I briefly looked into some of the more complicated functions when implementing my fixed points library, but I didn’t look at arctan/atan.
I had a quick look around and it looks like there’s a decent handful of identities you can use to simplify matters.
I found some source code for a floating point implementation of atan2 written in C by SunSoft in 1993, and there’s a list of special cases from which it’s possible to derive some special cases that would be valid for fixed point arithmetic.
(The original mentions negative zero, NaN and both forms of infinity, which naturally aren’t relevant for fixed points.)
atan2(0, x) is 0
atan2(0, -x) is pi
atan2(nonzero, 0) is pi/2
atan2(-nonzero, 0) is -pi/2
I’m having to make a bit of a leap of logic with these though. The original lists the first argument and the result with ±, which doesn’t make it clear whether a negative input forms a negative result (and vice versa) or whether a negative input forms a positive result (and vice versa).
The file’s quite small, so I’ll leave a copy here in case you find it useful: e_atan2.c (3.6 KB)
Your entry looks really great!
Probably the javelin should already be at a starting angle and not horizontal while running.
Will be possibile to adjust the trowing angle like in Track and Fields?
The more you keep presse the trowing button the more the angle rise…
