[MMF2] Pick Closest/Nearest Object?

[Asuma]

I have a basic homing code. How it seems to home in for the last object place. Is there a way to pick the nearest object?

[Streak Thunderstorm]

Have the enemy run a distance calculator code. Whichever enemy has the lowest distance calc and is ahead of Sonic's current direction, pick one.

Sqr((Xpos( "Enemy" )-FloatX( "Player_MovementValues" )) pow 2+(YPos( "Enemy" )-FloatY( "Player_MovementValues" )) pow 2)

[LarkSS]

Just make sure that you run a fastloop through every enemy testing distance and returning the ID/Fixed value of the enemy who has the least distance. If instead you calculate the distance in an enemy's alterable value and try to avoid the fastloop, you'll have no effective way to select the literal closest object, but can at least limit the target to a certain range, and if like Streak said, you check its position in comparison with Sonic's direction, you can pretty much get away with a good target selection 95% of the time.

[Asuma]

Ah. I put this in the compare general values?

[LarkSS]

This is how I did closest distance checking for super flickies in Sonic Worlds Delta. I did infact use a two general values comparison for the actual distance check; just make sure that if you use a fastloop, to check the ID of the enemy with the index of the fastloop first.

[DimensionWarped]

Calculating the square root at the end is costly and unnecessary. it stands to reason that if (dx1^2 + dy1^2) > (dx2^2 + dy2^2) that sqrt(dx1^2 + dy1^2) > sqrt(dx2^2 + dy2^2)

Likewise, if you have a maximum distance you want to check against, just square it before making the check. You don't really want to be checking dozens of square root functions in a single frame.

You can also save a decent number of calculations by storing the distance value into a temporary variable before doing the check. That way each time you need to swap the distance into the lowest distance position, you won't have to recalculate it. In the worst case scenario of swapping every time, you'll be able to cut half of the calculations.

[LarkSS]

If you're removing the square root, you might as well remove the squaring procedure for each distance calculation too, and just compare the sum of the absolute X distance and the absolute Y distance.

You can also save a decent number of calculations by storing the distance value into a temporary variable before doing the check. That way each time you need to swap the distance into the lowest distance position, you won't have to recalculate it. In the worst case scenario of swapping every time, you'll be able to cut half of the calculations.

I was lazy, and figured for the most part you would not get anywhere near that worst case scenario. =] I should probably be unlazy though and tidy things up sometime.

Speaking of enhancements, I was actually thinking that I could toggle a flag of the attackable if it's within a range to perform a distance calc, and then in the iteration loop, only do the distance check if the enemy's flag is togged. In the worst case scenario that all enemies are in the screen, this would slow things down, but in the standard case, a great deal of distance calculations would be reduced.

[DimensionWarped]

You could, but squaring is cheap. Dirt cheap. It's just a single multiplication. Also, unlike with the square root, it could change the result.

[LarkSS]

It just changes the distance comparison into a diamond instead of a circle; good enough, hahah.

[DimensionWarped]

Yes, but is it a good enough function to rescue the President?

[LarkSS]

=[ You had to go there, didn't you.