-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion for the next major release (2.0.0) #17
Comments
Hi, Some ideas:
Just a thought. Regards, |
Thanks for the ideas, Tony. I started the development of the version 2 on the branch |
Please add struct types back again. |
I think it's still possible to use any type of vector struct (with correct struct alignment) outside mathc, but you have to cast it to pointer at the edge between your program and mathc. Eg. vec v;
foo((mfloat_t*)&v); |
@cxong I agree with you The reason I decided using arrays (which I forgot to explain) is because it makes easier to pass data to OpenGL buffers that way: mfloat_t mat[MAT4_SIZE];
mfloat_t vertices[] = {
// Position Texture
0.0f, 1.0, 0.0, 0.5, 0.0,
-1.0f, -1.0, 0.0, 0.0, 1.0,
1.0f, -1.0, 0.0, 1.0, 1.0
...
}
mat4_translation(mat, position);
vec3_multiply_mat4(&vertices[0], &vertices[0], mat);
vec3_multiply_mat4(&vertices[5], &vertices[5], mat);
vec3_multiply_mat4(&vertices[10], &vertices[10], mat);
...
/* Push `vertices` to OpenGL */ |
If C11 can be used, then anonymous unions are perfect:
But if we stick with C99, I would prefer mathc to use structs and only cast to float array when needed, like when passing to OpenGL. |
what's the problem with C99? typedef union vec4 {
struct { float x, y, z, w; };
float v[4];
} vec4;
#include <stdio.h>
int main() {
vec4 v = { 1,2,3,4 };
printf("%f %f %f %f\n", v.x, v.y, v.z, v.w);
printf("%f %f %f %f\n", v.v[0], v.v[1], v.v[2], v.v[3]);
} |
I think anonymous unions is available only on C11, @r-lyeh. On C99, it's available only via extensions. @cxong, I added that struct layout Just for information: the issue with casting a structure composed of struct triangle {
struct vec3 a_pos;
/* Padding might happen here */
struct vec2 a_color;
/* Padding might happen here */
struct vec3 b_pos;
/* Padding might happen here */
struct vec2 b_color;
/* Padding might happen here */
struct vec3 c_pos;
/* Padding might happen here */
struct vec2 c_color;
}; Casting the structure above when passing to OpenGL is error-prone. While padding won't happen if this "mesh" is made with an array: mfloat_t triangle[5 * 3]; /* No padding between elements */ |
Padding is unlikely because the members are all the same size. But still you can use |
@cxong I saw you are using the functions that take structures as values on CDogs, so I also added back, as optional, the functions that take structure as values. To use structures, it's needed to define To use functions that take structures as value, define To use functions that take structures as pointer, define These functions are inlined, since what they do is call the functions that take Thoughts? |
Why not define those functions by default? Their names are different so there's no harm. |
No problem. I made them between
So they will be enabled by default, but can be disabled. I want to keep the possibility to disable, also because the anonymous unions are not available on C99. Edit: |
I think keeping C99 would be preferable. Using packed structs + macros, the API can be easy to use even without the anonymous unions, e.g.
|
I removed the unions to keep compatible with C99. I tested what you mentioned earlier about the packing. I thought the padding would happen with nested structures, but I tried
Though it's possible to change the |
|
@Ankush-p True. I will work on something tonight, but I'm also accepting contributions. I will leave this for reference: |
I have come up with a function to convert from a Quaternion to a vec3 Euler. I also needed to add a new definition for mfloat_t *vec3_quat_to_euler(mfloat_t *result, mfloat_t *a)
{
/* Assume normalized a */
/* test for singularity */
mfloat_t test = a[0] * a[1] + a[2] * a[3];
/* X axis */
mfloat_t sinX = MFLOAT_C(2.) * (a[3] * a[0] + a[1] * a[2]);
mfloat_t cosX = MFLOAT_C(1.) - (MFLOAT_C(2.) * (a[0] * a[0] + a[1] * a[1]));
/* Y axis */
mfloat_t sinY = MFLOAT_C(2.) * (a[3] * a[1] - a[2] * a[0]);
/* Z axis */
mfloat_t sinZ = MFLOAT_C(2.) * (a[3] * a[2] + a[0] * a[1]);
mfloat_t cosZ = MFLOAT_C(1.) - (MFLOAT_C(2.) * (a[1] * a[1] + a[2] * a[2]));
if (test > MFLOAT_C(0.499)) {
result[0] = MFLOAT_C(2.) * MATAN2(a[2], a[3]);
result[1] = MPI / 2;
result[3] = 0;
return result;
}
if (test < MFLOAT_C(-0.499)) {
result[0] = MFLOAT_C(-2.) * MATAN2(a[2], a[3]);
result[1] = -MPI / 2;
result[3] = 0;
return result;
}
result[0] = MATAN2(sinX, cosX);
result[1] = MASIN(sinY);
result[2] = MATAN2(sinZ, cosZ);
return result;
} MATHC_INLINE static struct vec3 *psvec3_quat_to_euler(struct vec3 *result, struct quat *a)
{
vec3_quat_to_euler((mfloat_t *)&result, (mfloat_t *)&a);
return result;
} MATHC_INLINE struct vec3 svec3_quat_to_euler(struct quat a)
{
struct vec3 result;
vec3_quat_to_euler((mfloat_t *)&result, (mfloat_t *)&a);
return result;
} |
The library reached a point where there are more additions made than deletions, so I made the first major release (1.0.0). This means until the next release (2.0.0), the library will not break backwards compatibility, but new features, such as functions, can be added with no problem.
This is issue is for discussion of what interesting changes could be made for the next stable (2.0.0) and that break compatibility with the current release, such as modifications in function arguments and structures. Feel free to comment or open issues with suggestions that could affect the entire compatibility.
Update:
The development of version 2 started on the branch
mathc2
.The text was updated successfully, but these errors were encountered: