What is the better (faster) way: to use transform matrices or to calculate transforms in my own code?

I mean when I want to rotate a primitive around Y-axis, I calculate sinf(a) and cosf(a) and recalculate x and z coordinates for new position. When I use transform matrix dx renderer does the same, but it has to mutiply some empty matrix members, which in most cases are 0's. I assume that using matrices is the most common and therefore slower method. Am I right?

I mean when I want to rotate a primitive around Y-axis, I calculate sinf(a) and cosf(a) and recalculate x and z coordinates for new position. When I use transform matrix dx renderer does the same, but it has to mutiply some empty matrix members, which in most cases are 0's. I assume that using matrices is the most common and therefore slower method. Am I right?

Afternoon, Vaxon.

I haven't done any speed tests on this, but maybe someone else has and would kindly reply here :).

I imagine you're talking about the D3DXMatrixRotationY function, compared to using the FPU?

Well...

In the end, you're still going to have to put your Y-axis calculations from the FPU into a matrice for when you call the SetTransform method for the dx device. In doing so, you're still having to set some of the matrice members to zero (whether by using one of the D3DX functions, or doing it yourself in code).

Cheers,

Scronty

Just checked an old file of Sergey Chabans', in which I'd added some extra procs.

One of the procs is for the D3DXMatrixRotationY function. This was made when I was just starting out mucking about with DX8 (i.e. before any of the include files had been done).

Quite strange that this proc uses the FPU to fill in the matrice :alright: .

I haven't done any speed tests on this, but maybe someone else has and would kindly reply here :).

I imagine you're talking about the D3DXMatrixRotationY function, compared to using the FPU?

Well...

In the end, you're still going to have to put your Y-axis calculations from the FPU into a matrice for when you call the SetTransform method for the dx device. In doing so, you're still having to set some of the matrice members to zero (whether by using one of the D3DX functions, or doing it yourself in code).

Cheers,

Scronty

Just checked an old file of Sergey Chabans', in which I'd added some extra procs.

One of the procs is for the D3DXMatrixRotationY function. This was made when I was just starting out mucking about with DX8 (i.e. before any of the include files had been done).

Quite strange that this proc uses the FPU to fill in the matrice :alright: .

```
; Build a matrix which rotates around the Y axis
```

D3DXMatrixRotationY2 PROC pMatrix:LPD3DMATRIX,theta:FLOAT

fld theta

mov edx,pMatrix

fsincos

fst [edx].D3DMATRIX._11

fstp [edx].D3DMATRIX._33

fst [edx].D3DMATRIX._31

fchs

fstp [edx].D3DMATRIX._13

fldz

fst [edx].D3DMATRIX._12

fst [edx].D3DMATRIX._14

fst [edx].D3DMATRIX._21

fst [edx].D3DMATRIX._23

fst [edx].D3DMATRIX._24

fst [edx].D3DMATRIX._32

fst [edx].D3DMATRIX._34

fst [edx].D3DMATRIX._41

fst [edx].D3DMATRIX._42

fstp [edx].D3DMATRIX._43

fld1

fst [edx].D3DMATRIX._22

fstp [edx].D3DMATRIX._44

ret

D3DXMatrixRotationY2 ENDP

The calculations seem to be faster using trig for rotation, don't they?

The truth is that if you are rotating few points, or many points but by different angles, it IS faster.

When you get into mesh models, the vertex count goes up.

It becomes a common thing to want to rotate many points by the same angle.

This is where matrix math steps in, and when it comes to hierarchical rotations (think about relative rotation), matrix math wipes the floor with trig math.

Comparing Trig Math and Matrix Math:

Trig-The bottom line is that for a regular trig rotation of a single vertex, twelve multiplications are required. That's it.

Matrices-To build a matrix yourself, sixteen multiplications are required... but then to USE it to rotate a single vertex, only nine are required.

That means for ONE vertex, Trig needs 12 muls and Matrices needs 25 muls...

!!but!! for ONE THOUSAND vertices, Trig needs 12000, and Matrices just 9016.

And this becomes more pronounced as the vertex count grows.

It took some time to convince me that matrixmath was indeed faster.

I'm not going to prove the math, you'll have to research it yourself, or just trust me on the figures I provided.

Of course, using DX, you don't need to perform these muls yourself, because you simply call the appropriate DX function (unless u think u can do it faster ;) )

The truth is that if you are rotating few points, or many points but by different angles, it IS faster.

When you get into mesh models, the vertex count goes up.

It becomes a common thing to want to rotate many points by the same angle.

This is where matrix math steps in, and when it comes to hierarchical rotations (think about relative rotation), matrix math wipes the floor with trig math.

Comparing Trig Math and Matrix Math:

Trig-The bottom line is that for a regular trig rotation of a single vertex, twelve multiplications are required. That's it.

Matrices-To build a matrix yourself, sixteen multiplications are required... but then to USE it to rotate a single vertex, only nine are required.

That means for ONE vertex, Trig needs 12 muls and Matrices needs 25 muls...

!!but!! for ONE THOUSAND vertices, Trig needs 12000, and Matrices just 9016.

And this becomes more pronounced as the vertex count grows.

It took some time to convince me that matrixmath was indeed faster.

I'm not going to prove the math, you'll have to research it yourself, or just trust me on the figures I provided.

Of course, using DX, you don't need to perform these muls yourself, because you simply call the appropriate DX function (unless u think u can do it faster ;) )