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

[Branan R. <br...@gm...>]

A matrix stack would require re-implementing many of the matrix
functions to work on the stack variable, rather than an arbitrary
matrix. Not difficult, but still a bit of a pain

Branan

On Thu, Aug 28, 2008 at 9:08 AM,  <gl...@mo...> wrote:
>> 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.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>