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
This change could break things. So, I created SUPPORT_HIGH_DPI flag to enable it (disabled by default).
Basically, it detects HighDPI display and scales all drawing (and mouse input) appropiately to match the equivalent "standardDPI" screen size on highDPI. It uses screenScaling matrix to do that.
This scaling comes with some undesired effects, like aliasing on default font text (keep in mind that font is pixel-perfect, not intended for any non-rounded scale factor).
The only solution for this aliasing would be some AA postpro filter or implementing the highDPI scaling in a different way: rendering to a texture and scaling it with FILTER_BILINEAR, check `core_window_scale_letterbox.c` example for reference.
Use at your own risk.
