tests should assert the returned value is equal to the expected value, and fail if otherwise. the test can be run as is or using a unit testing framework, which ever option is found to be the best fit. Any input?

Vectors with integer fields are less used, but are still usable. They won't have as many functions as the vectors with float fields, but they will have minimally the basic math operation functions.

When building a camera transform matrix, I have a quaternion for the heading and a vec3 for the camera position. I can use smat_rotation_quat() to build the rotation matrix from the quaternion, but then I need to insert the position as well. I don't see any functions for this, all mat4 translate functions appear to build a new mat4 from scratch.

For reference, I'm converting from linmath.h which had mat4x4_translate_in_place().

The functions for different vector sizes are very similar, but they are repeated in the code. This means mistakes are easy to make. I suggest using macros to define these functions, so you write the code once and use macros to define the other vector versions.

Here's some sample code for doing this kind of thing:

#include <stdio.h>

#define CAT(x, y) x##y
#define MAKE_FUNC(_num) \
void CAT(foo, _num)(void) { printf("func %d\n", _num); }

MAKE_FUNC(2)
MAKE_FUNC(3)

int main(void) {
	foo2();
	foo3();
	return 0;
}

proposal to add CI/CD tests, for example using travis ci to compile the code and run the test file. I have no problem to start working on this if it is found to be needed.

This code produces a warning when gcc/clang have warnings turned to full, or if -Wmissing-field-initializers is defined:

struct vec b_minus_a = {0};

Although this is valid C99 initialisation, should mathc aim to produce no compiler warnings? If so this needs to be replaced with say

struct vec a = {0, 0, 0, 0};
// or
struct vec a = vector2_zero();

I looked for this but couldn't find a quat_to_axis_angle. While I assume this can be obtained by applying the quaternion on a forward pointing vector and getting the angle manually, this is more cumbersome than a single call. Also, this might be me just misunderstanding things, but to me it's not obvious what sort of vector would align with the axis of a non-rotating quaternion in mathc's coordinate system since this is not specified. (Is it 0,0,-1? Or 1,0,0? ...) I might be wrong, but I think this knowledge is required to implement this manually in a way such that the quat_from_axis_angle reverses back to the same quaternion.

From what I can tell, v2 looks a lot friendlier than v1. v1 has been around a while, but v2 is listed as in development. Is it still recommended to use v1? Or is v2 ready for use in projects?

2D vectors can be simply represented as 3D vectors with z = 0.0f. However, matrices only works with 3D vectors, and it's inconvenient to convert from 2D to 3D just to use with matrices, as in this case:

cvector2 position = to_vector2(0.0f, 0.0f);
m = matrix_translation(to_vector3(position.x, position.y, 0.0f));

Working only with 3D vectors would make things simpler:

cvector3 position = to_vector3(0.0f, 0.0f, 0.0f);
m = matrix_translation(position);

The z component of 3D vectors are also useful in 2D games for z-ordering.

Functions like vector2_dot and vector2_angle will still exist, but they will only operate on the x and y components of a 3D vector:

float vector2_dot(cvector3 v);
float vector2_angle(cvector3 v);

To remove 2D vectors, react with :+1:.

To keep 2D vectors, react with :-1:.

For the sake of performance, it should be added version of functions that take the structures as pointers. The functions that take the structures as values will still exist, and the functions that take the structures as pointers will have a p prefix.

As example:

cvector2 pvector2_add(const cvector2 *a, const cvector2 *b)
{
	cvector2 result;
	result.x = a->x + b->x;
	result.y = a->y + b->y;
	return result;
}

inline cvector2 vector2_add(const cvector2 a, const cvector2 b)
{
	return pvector2_add(&a, &b);
}

Hi,

I made 2 little changes to the library.

1. Using memcpy and malloc functions seemed a bit overkilling for a simple math library like this, especially when memory size and layout is known beforehand.

2. I have fixed two bugs for mat4_rotation_axis and mat4_rotation_quat implementation.

If you think these are reasonable, here it is my pull request.

https://github.com/felselva/mathc/blob/d672725203fc80f6f79fba64533b87d51c32d714/mathc.c#L2556

Hey is this not an array overflow taking element 8 in a quartenion?

On https://github.com/felselva/mathc/blob/master/mathc.c#L5169 mat4 result is defined which is passed to mat4_rotation_x. Inside mat4_rotation_x only values at index 5,6,9, and 10 are updated. Also as per the example, in README, identity matrix was generated before passing it to mat4_rotation_x.

So shouldn't smat_rotation_* methods also set identity matrix before calling mat4_rotation_x?

E.g.

struct mat4 smat4_rotation_x(mfloat_t f)
{
	struct mat4 result = smat4_identity();
	mat4_rotation_x((mfloat_t *)&result, f);
	return result;
}

Currently in three places in the code there is an expression like: 1-cosine(subexpr). The problem with that is that it sacrifices quite a bit of precision the floating point type in use could provide. Because of the subtraction, and the fact that floating point is MUCH denser near zero than near one, 1-cosine(x) values that should be close to zero will just be truncated to exactly zero.

The added function sncs1cs is not exported.

The changes apply only if the user has not specified a custom mfloat_t.

This improves mat3_rotation_axis, mat4_rotation_axis and sine_ease_in_out. A side improvement in the former two is that the computation of sine, cosine and 1-cosine should be cheaper when computing them all at the same time than when calling a separate function for each of the three (because the majority of the code is shared between the three).

I checked that the improvements do materialize and, more importantly, at the same time searched for big regressions:

https://github.com/nsajko/numericcompfricas (see the README.md)

Basically, the results are that there are no significant differences for sin and cos (I think the accuracy only varies by one bit), but there are big improvements for 1-cos (AKA omc AKA 1cs). The repository contains the results of the check against glibc and against musl.

FriCAS (for the check) can be found here: https://github.com/fricas/fricas

Working on this library was very nice, and it seems it helped a lot of people, but also seems like I can't give it enough dedication anymore.

With that, I am looking for a new maintainer. I am looking for a maintainer that is experienced in C and is dedicated in the open-source community.

Thank you all for the support all this time!

I tried to find this function or an equivalent, but it seems to be missing: quat_look_at

I see matrix equivalents, but it would be really useful to be able to do this one with quaternions. From the internet it looks like this is commonly available in other quaternion libraries (e.g. Ogre3D's quaternions offer this) so it doesn't seem like a super arcane function either. Would be really cool if it could be added some day!