Also corrected some code style guide, and changed `nullptr` to `GLM_NULLPTR` for better compatibility.
Tests are now executed in blocks of related tests, and only inbetween blocks the tests will exit.
`acos` domain is in range [-1.0, 1.0]. Due to inaccuracies the value `angleCos` may be slightly outside that range for a correct matrix and `acos(angleCos)` produces `NaN` in that case.
The fix is we check `angleCos` value and return `acos(1)` for `angleCos > 1` and `acos(-1)` for `angleCos < -1`.
The original code checked only for `angleCos` close to `1.0` and returned an incorrect value for `acos(1)`, which is `0`, not `pi/4`.
string_cast.hpp merely detects whether the current compiler is NVCC (originally based on `if defined(__CUDACC__)` in glm/simd/platform.h) and throws an error if it is. This means string_cast.hpp cannot be included in any header which might ever be used in a CUDA project.
Of course, glm::to_string can't be used in device (GPU) code. However, the current approach to stop this is both incorrect and unnecessary. __CUDACC__ will be defined in both host and device code compilation, and glm::to_string can obviously be used in host code. The correct define is __CUDA_ARCH__ (will be defined only if compiling device code). However, there's no problem if glm::to_string is defined (the header is included) while compiling device code, as long as it's not actually used in the device code. So, throwing an error if __CUDA_ARCH__ is defined would still prevent string_cast.hpp from being included in CUDA projects.
There's actually no need for any manual check to see if glm::to_string is being used in device code, because the compiler will already check for that. It returns a std::string, which itself can't be used in device code, so it's unlikely a developer would try. And if they did, there would be errors that both glm::to_string and all the needed std::string constructors, stream operators, etc. are host-only functions.
This is a new warning in clang which will be available in clang 10
onwards
Fixes
error: implicit conversion from 'const int' to 'float' may lose precision [-Werror,-Wimplicit-int-float-conversion]
