For example:
The circle drawn is drawn with a radius of 224 pixels. If you were to use bounds_dist(), the squirrel in the picture would be considered "in range". However, in my game I am using exact distances. Using just a few lines of code and the distance formula, this can be accomplished quite easily:
proc/Accurate_bounds_dist(atom/movable/A,atom/movable/B)
var/X_difference=(32*A.x+A.step_x)-(32*B.x+B.step_x)
var/Y_difference=(32*A.y+A.step_y)-(32*B.y+B.step_y)
return sqrt(X_difference**2+Y_difference**2)
This proc takes a value for the bottom left pixel of each atom (taking into account pixel steps) and finds the distance between the two. It can be further shortened to two lines:
proc/Accurate_bounds_dist(atom/movable/A,atom/movable/B)
return sqrt(((32*A.x+A.step_x)-(32*B.x+B.step_x))**2+((32*A.y+A.step_y)-(32*B.y+B.step_y))**2)
With just a small modification, you could have this proc find the distance from the center of each atom instead of the southwest corner.
Enjoy!
bounds_dist(), on the other hand, reports the actual steps required to move two atoms next to each other. It assumes that a step in a diagonal direction is the same as two steps along the matching cardinal directions (so you can get to the squirrel in your example by stepping SOUTHEAST 224 pixels)
Of course, the above assumption isn't true for all games, in which case your snippet may be preferable.
Also, you should avoid using the exponent operator, as it is generalized for fractional exponents and is considerably slower than simply multiplying a value by itself.
Anywho, welcome back. I enjoyed a lot of your games back in the day. I look forward to seeing what you do with pixel movement :)