Square root calls are computationally expensive. In this case, they can be avoided. Instead of checking distance<RadA+RadB, check distance squared against (RadA+RadB) squared. The dot product of Vector3Subtract(B,A) with itself gives distance squared, so I used this code instead of an element-by-element computation of distance squared. The only downside is that your geometric code is very readable, whereas this is less so.
They not only result in discrepancies between different compiler,
but trigger undefined behavior. Avoid them by having them break
the CMake build and CI.
CI is failing because we still test with GLFW 3.2, while
the internal GLFW is 3.3. To avoid such breakages in future,
build and install our own GLFW instead of relying on an external
Debian package.
We were doing this before, but it was deleted during the
last GLFW update. Readd it to fix the associated macOS CI failure.
Fixes: cd934c9f6 ("Update GLFW to 3.3.1")
The example requires pthreads and now C11 <stdatomic.h>, thus skip it
if either isn't available.
This also fixes the current Travis CI build failure for the
Windows configuration.
A plain variable is insuffecient for inter-thread communication. Both the
compiler and the processor may reorder accesses. The compiler could even
cache dataLoaded with the result that STATE_FINISHED becomes unreachable.
Fix this by using C11 atomic_bool, which guarantees sequential consistency.
This fixes#827.
Added guards to not redefine it if the user is using it with raylib.h
also added an 'f' at the end of the define to keep compliant with raylib's PI define