Feature request: Allowing vecmath types to be provided by the user

[aganm]

I'm making an issue to open the discussion about this. I saw that vecmath allows for the user to provide his own math functions instead of the libc ones with macros. One thing I would like to do is the ability to provide my own math structures to replace the built-in ones. The reason I want this is I want to use vecmath within my existing code. And I have my own vectors and matrix types. If I was able to provide vecmath types with my own, I could use the library transparently with the rest of my existing code. It would be a lot easier to integrate the library in a foreign codebase with this feature.

[aganm]

Also, my provided types shall comply with vecmath's API. vecmath vec3_t type expects float x,y,z,w members, my types will provide float x,y,z,w members. My type will be the same as the built-in types. To provide my own type will allow for the typesystem to work with only one type everywhere, instead of having to convert between my math types and the types of the library.

[aganm]

I implemented it #79

[mattiasgustavsson]

I can see the convenience of this, but also some complications arising from it. For example, the _get/_set (accessing by index) functions assume the x/y/z/w members are in that specific order, starts at the start of the struct, and that there's no padding. If enabling VECMATH_EXT_VECTOR_TYPE, they have to be declared as float and decorated. Further, some tests assume the exact binary representation of the types. If the types had trailing elements after the required ones, like debug tags or whatever, those would be lost when new values are returned, so that makes for awkward behaviour too. So it's not really possible to use custom types, they must be declared exactly as in vecmath.h, which make me feel like their definition is probably best owned by vecmath.h.

I'm going to have to think about this for a bit, maybe try some things out. I am not sure it would be a good fit for the library, but maybe it could be. Things to ponder and consider...

[aganm]

So I tried correcting the issues you mentioned with some success.

If enabling VECMATH_EXT_VECTOR_TYPE, they have to be declared as float and decorated.

I fixed that by making custom types incompatible with VECMATH_EXT_VECTOR_TYPE. If trying to use both at the same time, an #error is thrown which informs the user that if he wishes to use custom types with clang vector types, then he must decorate his own types.

Functions assume the x/y/z/w members are in that specific order, starts at the start of the struct, and that there's no padding.

I now guarantee all of this using a static assertion that checks the offset of each type member. The static assertion per type member checks the offset of the member. If the offset is correct, it means: the first field starts at the beginning of the type, it means the fields are in the correct order, and it means there is no padding in-between each member.

If the types had trailing elements after the required ones, like debug tags or whatever, those would be lost when new values are returned, so that makes for awkward behaviour too.

I guarantee this with another set of static assertions that check for the size of the math types. If the size of the math types match, it means there is no additional hidden data into the type. It is exactly and perfectly the type that vecmath expects.

⚠️ One issue left: my static asserts fail CI on wasm and macos. Not sure why this is happening.

[mattiasgustavsson]

I think I’m going to pass on this. I feel it’s quite a niche feature, I don’t really like all the complexity it introduces for what it does - I think this would be better as a fork you maintain independently

[aganm]

Alright, I'll close this.