glm types always use JS Float32Arrays under the hood.

[LuisMerinoP]

Hi there. Awesome work. Thanks very much for working this out.

Noticed that no matter the type of vector built, FloatArray32 JS type is what is used under the hood.

const glmIvec = glm.ivec3(-3, 0, 0);
const glmUvec = glm.uvec3(-3, 0, 0);
const glmVec = glm.vec3(-3, 0, 0);

console.log('glmIvec', glmIvec);
console.log('glmUvec', glmUvec);
console.log('glmVec', glmVec);

I would expect that once the library takes care of the glm type specifics on the semantic side, the closest JS type array match would be used. This would be for memory efficiency also, but mainly to avoid misunderstandings/bugs when memory strides are passed into the graphics API functions.

Taking the chance to ask if PRs are welcome, maybe to fix this or for example to add typescript types to the library. Thanks.

[humbletim]

Thanks for reporting this issue and your feedback. Unfortunately, the glm-js project is currently in the process of sunsetting and is no longer actively maintained (see discussion #19 for details).

While I can't personally address this, it does sounds like a potential issue with TypedArray usage. I recall working with different TypedArrays for uvec and ivec in glm.experimental.js or glm.buffers.js, or possibly related to legacy browser sniffing code.

If you're interested in contributing, you're welcome to fork the project and share your work here for potential visibility, but keep in mind that future support for such contributions is not guaranteed.

Thanks for your interest and your understanding! Best regards, -Tim