Matrix unit

[michalis]

When I started my own vertor/matrix unit (you can see it in http://www.camelot.homedns.org/~mich...ame_engine.php,
unit VectorMath in subdir base/) I wasn't aware that there is a matrix unit in FPC. Actually, I'm not sure whether it existed then, as it was around 2002.

Then, when I first saw Matrix unit, I saw that it uses old-style TP objects... so I suspected that maybe it's some old code, not maintained. Moreover, it didn't have anything to offer me, aside from nice operator overloads that I could add to my unit at any time. My unit already had way more operations.

To enumarate everything that I expect from the vector/matrix unit, I would have to paste here the interface of my whole VectorMath unit BTW, you have complete permission to reuse any parts of my VectorMath unit for FPC Matrix unit, under FPC RTL license.

The most important information for me is that now I know that Matrix unit is supposed to stay and be maintained and improved. I'll see whether I can migrate to it --- at least reusing it's Tvector*_data and Tmatrix*_data types should be an easy and quick start.

[cragwolf]

Here is what michalis expects:

http://www.camelot.homedns.org/~mich...ectorMath.html

[grudzio]

* Are you aware that FPC has a matrix unit?

Now I am

* Do you think it suits the needs of games?

Another problem I see is the compatibility with 3D apis, OpenGL in my case . Is the column/row ordering same as in OpenGL. Is there an easy way of sending and retrievng matrices to and from OpenGL and so on. Although a good, optimised 3D math library shipped with a compiler is a nice thing to have.

* If you implemented one yourself, why did you do so?

Generaly I prefer to write my own code then made by others. I know that often it is reinventing the wheel, but it is a learning experience and it is easier to fit my own code into my projects.

[dmantione]

* Do you think it suits the needs of games?

Another problem I see is the compatibility with 3D apis, OpenGL in my case . Is the column/row ordering same as in OpenGL. Is there an easy way of sending and retrievng matrices to and from OpenGL and so on. Although a good, optimised 3D math library shipped with a compiler is a nice thing to have.

No, the row/column ordering doesn't match OpenGL. Interfacing with OpenGL is still very easy, i.e.:
[pascal]
var m:Tmatrix4_single;

begin
with m.transpose do
glLoadMatrixF(@data);
[/pascal]
I'm going to put this into the documentation.

* If you implemented one yourself, why did you do so?

Generaly I prefer to write my own code then made by others. I know that often it is reinventing the wheel, but it is a learning experience and it is easier to fit my own code into my projects.

Yes, that makes sense.

[dmantione]

To enumarate everything that I expect from the vector/matrix unit, I would have to paste here the interface of my whole VectorMath unit BTW, you have complete permission to reuse any parts of my VectorMath unit for FPC Matrix unit, under FPC RTL license.

Thanks! I've already been thinking about adding more geometry code, however, I decided to watch what the response to the matrix unit was, the FPC to do list is long as ever

[Clootie]

No, the row/column ordering doesn't match OpenGL. Interfacing with OpenGL is still very easy, ....

Wait, for a long time I was convinced by someone that both D3D & OpenGL matrices are equal if we look at _binary_ format in memory. It's just API's what tread them differently. I.e. in books matrices and vectors are printed differently (I mean row/column "visualization").

[michalis]

No, the row/column ordering doesn't match OpenGL. Interfacing with OpenGL is still very easy, i.e.:
[pascal]
var m:Tmatrix4_single;

begin
with m.transpose do
glLoadMatrixF(@data);
[/pascal]
I'm going to put this into the documentation.

Or just
[pascal]glLoadMatrixF(@m.transpose.data);[/pascal]

Actually, it would be nice to add a unit like GLMatrix that defines overloaded versions of glLoadMatrix routines that just take Tmatrix4_single/double as arguments and do the transpose inside implementation.

I even thought about doing descendants like TMatrix4_single_GL that have methods like glLoadMatrix with implementation like

[pascal]
procedure TMatrix4_single_GL.glLoadMatrix;
begin
GL.glLoadMatrix(@transpose.data);
end;
[/pascal]

... but this will not be so nice, since you will have to override some operators again for new TMatrix4_single_GL class, and if you receive your matrix instance from some non-OpenGL-related unit then it will still have normal TMatrix4_single class, not TMatrix4_single_GL. So making non-object procedures like glLoadMatrix(M: TMatrix4_single) would be more general solution to "hide" the "transpose." call from the eyes of the programmer.

[michalis]

I forgot to add that two days ago I added a program to pasdoc that works like a Pascal preprocessor, see http://pasdoc.sipsolutions.net/OtherTools. It can resolve many things, like $define, $ifdef, $include and FPC macros. The idea was to allow you to use FPC macros when developing your units, and then port them to Delphi easily by automatic convertion through this program.

Oh, and it works !

Unfortunately, it doesn't evaluale expressions inside $if constructs, and Matrix unit uses $if a lot. So to port Matrix unit to Delphi one would have to convert them to simple $ifdef with appropriate symbols. And of course the operator stuff would have to be put only inside {$ifdef FPC} --- and I agree here with Daniel that the overloaded operators stuff is one important advantage of this unit in FPC.

Anyway, if someone is really pressed into converting Matrix unit into Delphi, then you have now at least a way to automatically resolve all FPC macros for Delphi.

[dmantione]

Actually, it would be nice to add a unit like GLMatrix that defines overloaded versions of glLoadMatrix routines that just take Tmatrix4_single/double as arguments and do the transpose inside implementation.

I like this idea. It'll make OpenGL programming a bit more high level. We could also add overloads that accept open arrays of vectors, abstracting the pointer stuff that is necessary for the *v functions.

I even thought about doing descendants like TMatrix4_single_GL that have methods like glLoadMatrix with implementation like

[pascal]
procedure TMatrix4_single_GL.glLoadMatrix;
begin
GL.glLoadMatrix(@transpose.data);
end;
[/pascal]

... but this will not be so nice, since you will have to override some operators again for new TMatrix4_single_GL class, and if you receive your matrix instance from some non-OpenGL-related unit then it will still have normal TMatrix4_single class, not TMatrix4_single_GL.

Well, the multiply operator could call a virtual method to do i.e. multiplication, then it should be possible to do it with only one set of operators defined. However, I don't know wether this is desired for speed reasons.

[dmantione]

I forgot to add that two days ago I added a program to pasdoc that works like a Pascal preprocessor, see http://pasdoc.sipsolutions.net/OtherTools. It can resolve many things, like $define, $ifdef, $include and FPC macros. The idea was to allow you to use FPC macros when developing your units, and then port them to Delphi easily by automatic convertion through this program.

Oh, and it works !

Nice

Unfortunately, it doesn't evaluale expressions inside $if constructs, and Matrix unit uses $if a lot. So to port Matrix unit to Delphi one would have to convert them to simple $ifdef with appropriate symbols. And of course the operator stuff would have to be put only inside {$ifdef FPC} --- and I agree here with Daniel that the overloaded operators stuff is one important advantage of this unit in FPC.

Do you think there is a way to do the same with the new Delphi overloaded operators? If yes we could consider to write a Delphi unit that results in the same syntax for users of the library.