http://nwn-j3d.sourceforge.net/jogl/vecmath.zip
I have taken existing Kenji Hiranabe version and added column-major setter and both row and column-major getters for Matrix* classes. This should make it easier to directly use these classes with jogl. I have deprecated plain ‘set’ methods, while they still point to setRM (set row-major) setter, it is better to explicitly state which order you want at given place.
Artur,
I was wondering why you went this route – deprecating methods and adding specific getters/setters. Did you consider these alternatives?
Leave everything the way it was but add a byte[] getOpenGLVector() method to push the correctly formatted matrix into OpenGL.
Create a singleton to store a library initialization parameter (CM or RM). Then at startup, the programmer decides the orientation.
Simply convert the classes to be CM rather than RM oriented.
It’s my opinion that opening up setCM and setRM to be executed in the same program presents the opportunity to accidently call the wrong function. The programmer should be abstracted from how the vecmath lib stores internal data. After all, the ordering of the cells in the matrix doesn’t really matter until the data is delivered to the renderer.
Just my $0.02.
As for the 1 - I wanted to stay away from any mention of opengl here - for me vecmath is independent from any API using it. As for the 2 and 3 - it would create source incompatibility with existing source using javax.vecmath. Point 2 could be possibly implemented in transparent way, but for me methods which have very different behaviour depending on some magical switch are no-no.
As for the isolating programmer - it is not possible with vecmath. All fields are public, with specific names. There is no way to encapsulate anything. By adding RM/CM get/set I just wanted a clear way to interface to non-object version of matrix - plain array.
Please note that only bulk transfer methods have any notion of column or row ‘majorness’. All the rest of api is agnostic as far as it is concerned - as it was in original. Only set method was specifically calling for row-major layout.
Yes, it is possible to make a mistake with setCM/RM. Maybe calling it setColumnMajor/setRowMajor would be better ? It is not a problem to change that.