Weird results with angleBetween (FlxAngle VS FlxPoint)

[Txori]

• Flixel version: git (updated today 09/02/16)
• OpenFL version: 3.6.1
• Lime version: 2.9.1
• Affected targets: I just tried Flash

---

Code snippet reproducing the issue:

package;

import flixel.FlxState;
import flixel.FlxSprite;
import flixel.math.FlxAngle;
import flixel.math.FlxPoint;

class PlayState extends FlxState
{
	override public function create():Void
	{
		var x1=10;
		var y1=400;

		var x2=600;
		var y2=20;

		// ANGLE BETWEEN TWO FLXSPRITE
		var startSprite:FlxSprite = new FlxSprite(x1, y1);
		startSprite.makeGraphic(1, 1, 0xffff0000);
		add(startSprite);
		var endSprite:FlxSprite = new FlxSprite(x2, y2);
		endSprite.makeGraphic(1, 1, 0xffff0000);
		add(endSprite);

		trace(FlxAngle.angleBetween(startSprite, endSprite, true));

		// ANGLE BETWEEN TWO FLXPOINT
		var startPoint:FlxPoint = new FlxPoint(x1, y1);
		var endPoint:FlxPoint = new FlxPoint(x2, y2);

		trace(startPoint.angleBetween(endPoint) - 90);
		// I have to substract 90° because 0 is pointing to the up direction for reasons...
	}
}

---

Observed behavior:

FlxAngle.angleBetween(SpriteA:FlxSprite, SpriteB:FlxSprite, AsDegrees:Bool = false):Float returns 32.78428086586915, which is correct.

FlxPoint.angleBetween(point:FlxPoint):Float returns 35.25773195876289, which is wrong.

Expected behavior:

I'm calculating the angle between two FlxPoint instead of two (created for the occasion) FlxSprite in order to gain some speed. I expect the results to be the same...

And by the way, I'm wondering why FlxAngle.angleBetweenPoint() gives the angle between an FlxSprite and an FlxPoint, and not between two FlxPoint... >:(

If you need more details, here's the discussion at haxeflixel forum that led me here.

[Gama11]

Regarding the "0 is pointing to the up direction" / the -90, see #956.

[Gama11]

Regarding the actual issue, FlxPoint#angleBetween() doesn't use Math.atan2(), but some approximation / optimization (which has been there since AS3 Flixel IIRC). That might be the reason. I wouldn't have expected to be off by this much though, maybe this is a particularly unfortunate example.

Would also be interesting to check if AS3 Flixel's version of this method has the same issue, IIRC we made some fixes to it at some point.

[MSGhero]

Would you rather have a fast atan2 or just the function itself? I can look into the former.

[Gama11]

I guess it depends on how much faster than atan2 the function currently really is. If there is no big performance benefit, we might as well use the more accurate version. However, I have a feeling it will make a difference.

[MSGhero]

Same kind of thing as fast sine?

[Gama11]

Not sure what you mean.

[Txori]

Maybe we can let the user to choose between both with a fast:Bool. But I would always choose the precise result, because 2.47° of error is HUGE...

[Gama11]

That would be a huge hack / not an option. We need to fix it properly. :)

[MSGhero]

Like how the fastSin function was faster than regular sin but slightly inaccurate. I think it was used in a rotation function or block of code.

[MSGhero]

I tried both of these. They're either slower or 4 percent faster, and that's without checking for edge cases such as y>x or y=x=0. With the edge cases being checked, they're like 20x slower.

Everything was tested inlined and not, cpp debug.