redundant function "overlapBoxes"

[GoogleCodeExporter]

inline bool overlapBoxes(const float* amin, const float* amax, const float* 
bmin, const float* bmax)

This function is redundant - because you already have the dtOverlapBounds 
function.

Would the function not be faster if you have multiple returns? i.e.

inline bool dtOverlapBounds(const float* amin, const float* amax, const float* 
bmin, const float* bmax)
{
    if (amin[0] > bmax[0] || amax[0] < bmin[0]) return false;
    if (amin[1] > bmax[1] || amax[1] < bmin[1]) return false;
    if (amin[2] > bmax[2] || amax[2] < bmin[2]) return false;
    return true;
}

I don't generally like multiple returns - but in this case (with such a small 
function) it seems ok.

Original issue reported on code.google.com by armstron...@gmail.com on 23 Aug 2010 at 3:02

[GoogleCodeExporter]

I think the code was lifted from Bullet source once upon a time. I have not 
tested if multiple exists is faster.

http://code.google.com/p/bullet/source/browse/trunk/src/LinearMath/btAabbUtil2.h
#214

I shall remove the dupe.

Original comment by memono...@gmail.com on 23 Aug 2010 at 3:07

[GoogleCodeExporter]

BTW: The company I work for builds all code using "Unity" files (I think 
they're also called FastBuild??). Anyway, they basically have a master CPP file 
that includes a lot of other CPP files. Any duplicate code causes the compiler 
to barf. The function "opposite" is also defined twice. 

I appreciate that we could build the code as separate CPP files - so I will 
understand if you won't fix it...however it is just these two functions that 
are causing the problem: overlapBoxes & opposite.

Original comment by armstron...@gmail.com on 23 Aug 2010 at 4:59

[GoogleCodeExporter]

Fixed in R202.

Original comment by memono...@gmail.com on 23 Aug 2010 at 5:41

• Changed state: Fixed

[GoogleCodeExporter]

I did a test of the multiple exits - and it's no faster. I guess the compiler 
does a good job of optimising the function. The branchless select in Bullet 
would be good to use...it's just a case of providing a platform independent 
implementation (otherwise known as a macro).

Anyway - I doubt it's a bottleneck.

Original comment by armstron...@gmail.com on 24 Aug 2010 at 3:44