yoanlcq / vek

Generic 2D-3D math swiss army knife for game engines, with SIMD support and focus on convenience.
https://docs.rs/vek
Apache License 2.0
282 stars 32 forks source link

Conversion/Casts considerations #88

Open Patiga opened 1 year ago

Patiga commented 1 year ago

Context: I'm using vek in combination with fixed point numbers. In case you are curious, the project I'm working on is twmap (and the few other things I build on top of it).

Vec2 currently has numcast as its main method of conversion afaik. numcast relies on Numcast, which fixed doesn't implement (reasoning).

Conversion methods which I think could be added

Like last time, I'm willing to put my own time into this, but I won't stop you if you judge that it's worth your time :) I'll continue opening issues for non-trivial things, as you suggest in the README

yoanlcq commented 1 year ago

I think this time a PR would be appropriate (that would also allow you to test before changes are published).

Some guidelines:

The point is, I'd like to avoid a situation where vek "blesses" a few specific crates that are not widely used, adding to its dependencies; there's a threshold where it might be more elegant to have a separate crate (such as "vek-fixed-interop", I'm exagerrating but that's the idea)

Methods can be added as long as they are general enough (so stuff based on FromPrimitive/ToPrimitive). The az crate looks ok as a "common ground" that number types can implement, but I'm hesitating because it looks, although well-designed, quite specific and niche.

In your specific project, you might find it more convenient to have "extension traits" implemented for all vector types, where you add conversion methods as you see fit (then put the trait impl into a macro re-used for all vector types). The map() method can make this easy; there should be no need to get as "sophisticated" as the current macros in vek's internals.

If I understood correctly it's just a matter of using To/FromPrimitive to cast to f32/f64 and that's it? Then helper methods could be added to vectors as you suggest, but I'd like to avoid getting further than that.

Patiga commented 1 year ago

Would you consider adding az as an optional dependency, or would you rather avoid that as well? I do understand that optional dependencies can also kind of bloat, so I wouldn't mind if you aren't a fan of that

yoanlcq commented 1 year ago

I think I'm OK with az as an optional dependency.