it is a really easy one,

take this picture:

^

| a|b|c

y ------

d|e|f

------

g|h|i

x-->

**e** represents the box

it checks if the coordinate is within one of the surrounding areas (

**a , b , c , d , f , g , h , i **).

I.e. when its in

**d** the shortest distance would be just the x difference to the left side of

**e**If the point is in

**i** the shortest distance would always be calculated to the bottom right corner point of

**e** ( in the code these are the cases where the distance is calculated using an x and y part )

When it is inside

**e** the distance is zero and no multiplication is done at all.

It simply uses different coordinate Systems each time it does this,

in the example the box is viewed in an X Y coordinate system

the Algorythm will also look at the box using an X Z Coordinate System and an Z Y Coordinate System.

It could be that the algorythm uses one more iteration than it actually needs in some cases.

And it would be better to check the cases using the GLBASIC SELECT method.

But I think it is far more efficient than splitting the box surface into single points and calculate the distance to the points,

when you use large objects in relation to your collision size,

because you need more and more points when your object gets larger.

I use it in my game to calculate the distance to the camera point position on some larger objects to avoid

this object from fading out to early and I had no noteable framerate drop with this on the pandora when tested with 50 Objects

which used this every frame, in my test case.