Followers 0

Distance formula in c++

10 posts in this topic

Hello all,

I have recently came very very close to making the gameplay style I want but I stumbled into a small problem. I need the distance between two objects counted by the pixel. At first it seemed easy but I soon realized I didn't know what I was doing. Does anyone know how to do the distant formula in c++. I need the distance between two separate objects for my collision detection to work to my liking. The objects are the size of pixels by the way.

I tried using a for loop to figure out the distance but the second object of the 2 moves around and the for loop only activate  when the second object triggers it moving away from the first object. If it get closer after activating the for loop the distance will not be checked.

Edited by LAURENT*
0

Share on other sites

I was ready to include cmath and do some calculation but what I forgot and didn't realized was how simple getting the distance was addition/subtraction. Alright thanks for the refresher this thread is done. You made this a little simplier than the youtube video I watched.

0

Share on other sites

Nice to know about hypot() too! I was hoping to find one for 3 dimensions as well (its easy enough to implement oneself, of course), but no dice.

0

Share on other sites

My favorite method for calculating approximate distance:

u32 approx_distance( s32 dx, s32 dy )
{
u32 min, max, approx;

if ( dx < 0 ) dx = -dx;
if ( dy < 0 ) dy = -dy;

if ( dx < dy )
{
min = dx;
max = dy;
} else {
min = dy;
max = dx;
}

approx = ( max * 1007 ) + ( min * 441 );
if ( max < ( min << 4 ))
approx -= ( max * 40 );

// add 512 for proper rounding
return (( approx + 512 ) >> 10 );
}


http://www.flipcode.com/archives/Fast_Approximate_Distance_Functions.shtml

Its useful for pathfinding and AI.. though it might be weird for collision. I recommend storing everything collide-able inside of an array and iterating through them while checking to see if the edges of the objects over lap with each other via box collision or separating axis theorem.

Box Collision:

bool DoBoxesIntersect(Box a, Box b) {
return (abs(a.x - b.x) * 2 < (a.width + b.width)) &&
(abs(a.y - b.y) * 2 < (a.height + b.height));
}


http://gamedev.stackexchange.com/questions/586/what-is-the-fastest-way-to-work-out-2d-bounding-box-intersection

Separating Axis Theorem:

http://www.metanetsoftware.com/technique/tutorialA.html

Edited by Isaac Paul
2

Share on other sites

Somehow I feel the strange urge to actually profile this against a straightforward implementation using a modern compiler on modern hardware, just to see if all this obscure trickery is still worthwhile.

0

Share on other sites

fast diamond 2d distance: dx+dy

fast BBox 2d distance: greater of dx and dy

fast 2d distance comparison: dx*dx+dy*dy      (paythag w/o sqrt, as mentioned above).

true 2d distance: sqrt(dx*dx+dy*dy)            (true pythag, as mentioned above).

0

Share on other sites

Somehow I feel the strange urge to actually profile this against a straightforward implementation using a modern compiler on modern hardware, just to see if all this obscure trickery is still worthwhile.

Me too.

For distance comparisons, the naive computation leaving out square-root is definitely faster ( can count 3 multiplies here, plus all the other instructions, vs. 4 multiplies and an add for the naive) and totally accurate to boot.

For true distance, it probably depends entirely on how fast your hardware can do square root. The branches above gave me pause at first, but they look like they can be compiled into conditional moves to eliminate branch misprediction and potential stalls. But on even a 45nm Core 2 CPU, sqrt takes between 6 and 20 clock cycles only. I would hazard a guess that the above fast approximation is little if any faster on a modern CPU than the naive implementation. That might not be true if you can only have one sqrt instruction in flight but many multiplies/shifts/additions, though.

But on a CPU with slow square root, or gods forbid -- software emulation of square root, the above approximation will certainly be faster.

Edited by Ravyne
0

Create an account

Register a new account