PR #1/5 Astolfo feature/builtin-scalar

[RealAstolfo]

No description provided.

[RealAstolfo]

apologies for the mistake with the previous pr. this implements the scalar functions needed for Vector2,3 etc.

[ttencate]

Even in a precision=single build, the float type in Godot is still 64-bits. So most/all of these functions should probably work on f64.

[Bromeon]

Even in a precision=single build, the float type in Godot is still 64-bits. So most/all of these functions should probably work on f64.

Correct, f64 is also the type we use for FFI (Godot <-> Rust parameters and return types).

[Bromeon]

On the other hand, in gdnative we also use f32, so we might start with this.

Certain functions like lerp() will likely get their own trait over time, as they can be implemented for lots of different types (vectors, transforms, etc). So that would allow polymorphism on them.

For others, I'm not sure. I'm a bit hesitant to provide two versions of each function, so sticking to f64 might be better. Thoughts?

bors try

[bors]

try

Build failed:

• full-ci

[Bromeon]

CI passed except for the license-guard:

ERROR the following files don't have a valid license header:
godot-core/src/builtin/math.rs

Once you fix this, we can merge this PR.

There are almost certainly going to be API changes later, but it's good to have a starting version that powers the geometric types 👍

[ttencate]

For others, I'm not sure. I'm a bit hesitant to provide two versions of each function, so sticking to f64 might be better. Thoughts?

I would say, when in doubt, do as the engine does. Hunting down precision issues introduced by a port from GDScript to Rust does not sound like fun.

[Bromeon]

I would say, when in doubt, do as the engine does. Hunting down precision issues introduced by a port from GDScript to Rust does not sound like fun.

Generally I agree, however we also need to consider ergonomics. If 95% of calls look like func(arg as f64) as f32, we're not doing ourselves a favor. Traits might possibly help, functions like lerp() are useful for other types, too.

For now I would like to merge this to unblock the dependent PRs. There's anyway a lot to be done as follow-up for this functionality, for example:

• Align with gdnative::globalscope
• Proper testing
• Documentation
• Consider ..= ranges in arguments
• ...

bors r+

[bors]

Build succeeded:

• full-ci

[Bromeon]

@RealAstolfo First PR merged, thank you! 🙂