Re: [Glsdk-devel] Commentary on the math library

[<gl...@mo...>]

> For point #3, a solution may be to create two versions of many of the
> matrix
> functions:
>
> *GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x, GLfloat y);
> GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLMmat3f *in, GLfloat x,
> GLfloat
> y);*

I don't think we're doing any function overriding :)

*IF* we're going to have both, then my proposal would be:
1.
glmMatTranslate - creates matrix
glmMulMatTranslate - translates (multiplies by translation matrix)

2.
glmMatOfTranslation | glmMatTranslation (confusing) | glmTranslationMat
Last one is nice, but in conflict with our current naming convention.

glmMatTranslate - translates matrix


I thought glm<type><action> naming convention is nice. Now I have my
doubts :P - glmTranslateMat and glmTranslationMat seem pretty distinct,
while having "Mat" at beginning requires some gymnastics later.



> As for the matrix stack, it almost seems like it needs a separate library

Perspective, LookAt, etc. functions should be in GLU (and they are), since
they're related to graphics.

Matrix stack is not related to graphics actually. We have similar stack in
FPU, but FPU needed it because it was separate from CPU. With OpenGL we
have similar case (it can't access matrices stored in system memory - it
has it's own storage).

Actually, for SDK we don't really need matrix stack :) Just think of it -
each function in the program has it's own local variables (so local
matrices, too). If we could design our examples in a way that matrix stack
matches function stack... :)
Yeah, I know - I'm a heretic ;)

I didn't give it any serious thought - tus idea just popped up a moment
ago. Perhaps it's a good design pattern, perhaps it's not.