Align raymath functions with C versions

[djfinlay]

Fixes #514

I realise that there are a lot of changes here, even if they're backed up by tests. Let me know if you want anything dropped or moved to a separate PR.

Summary of changes

• Generate fuzz tests for raymath functions to compare them to C versions
• Generate unexported C bindings to test against
• Generate benchmarks to see if it's worth calling any of the C functions directly instead of reimplementing them (currently none are)
• Fix functions where they differ from C versions
• Generate methods for raymath functions

go generate runs the generator.

In addition to using go test -fuzz, fuzz tests can be run sequentially from the raylib directory by passing -fuzztime to the generator e.g. go run ./internal/cmd/genraymath -fuzztime 10s.

Some fuzz inputs are tested when calling go test, namely those specified manually via f.Add (each fuzz test has one of these) and those in the testdata directory. The inputs in testdata are ones which caused tests to fail when I was running fuzz tests.

Fixed functions

Some functions produced very different results from the C version, while others were just a little off due to float32/float64 rounding.

• MatrixDeterminant
• MatrixFrustum
• MatrixLookAt
• MatrixPerspective
• MatrixRotateX
• MatrixRotateXYZ
• MatrixRotateY
• MatrixRotateZ
• QuaternionFromMatrix
• QuaternionSlerp
• QuaternionToMatrix
• Vector2Angle
• Wrap

Vector3ToFloat was moved from rcore.go to raymath.go so it can be parsed by the generator. It also now calls through to Vector3ToFloatV like MatrixToFloat does with MatrixToFloatV.

Vector2LenSqr was removed because it's the same as Vector2LengthSqr.

Edge cases

• Mat2MultiplyVector2
• Mat2Radians
• Mat2Set
• Mat2Transpose
• MatrixNormalize
• MatrixToFloat
• Vector2Cross
• Vector3ToFloat

The above functions are not tested because they don't have equivalent C versions.

• Vector3OrthoNormalize
• QuaternionToAxisAngle
• MatrixDecompose

The above functions have more complicated signatures so I've chosen to write tests manually rather than overcomplicate the generation code. Their C bindings are still generated.

Methods

Since I'm parsing raymath.go to generate tests, generating methods is simple. Each method calls through to the non-method version though the generator supports inlining these calls. Inlining would require running go generate if any of the implementations of functions in raymath.go change but may have a small performance benefit.

Adding new raymath functions in the future

Running go generate followed by go test -fuzz "^Fuzz{function_name}$" should be sufficient to test most new functions, unless they modify arguments passed in as pointers.

[djfinlay]

I'm not sure why Vector3OrthoNormalize produces different results only on macos and I don't have a mac to test with. Any ideas?

[gen2brain]

Wow, thanks, need some time to check everything. Could we get your internal code just for generating and testing purposes, especially for new releases? I do not like the idea of adding so many files instead of just a single raymath.go as before.

[djfinlay]

All the generation code is in raylib/internal/cmd/genraymath. Almost all the code is generated from raymath.go (apart from raymath_test.go), so it remains the source of truth.

[gen2brain]

Sorry, did not have much time to test this. I will merge it and will review it later when needed. Thanks!