CMatrix4 hardcoded to use vector3df - Why?

[chronologicaldot]

I wanted to use CMatrix4<f64> and discovered that all of the vector transform functions (with the exception of those that use only arrays of set-sizes) only use vector3df. Doesn't this defeat the purpose of having template<class T> ? I realize we use f32 more than f64, but it'd be nice to have the flexibility... or are we just scared of people who want to try CMatrix4<s8> (Muhahaha!)?

For now, I can change it myself and potentially watch a ton of things in the engine break.

EDIT: I managed to change all of the transform functions for vectors and it compiled successfully. I imagine this is because most things are using the template "matrix4" anyways. I also ran a demo with it and it ran successfully...

[chronologicaldot]

Addendum: I discovered this:
http://irrlicht.sourceforge.net/forum/v ... x4#p133928

... It was supposed to be changed 6 years ago.

In that case, I'll just upload my altered copy.

----------- Addendum
In order to avoid the warnings, I had to add another function in irrMath.h to account for the ambiguity from iszero().

In irrMath.h, the following needs to be added:

Code: Select all

 
template<class T>
inline bool iszeroT( const T a, const T tolerance = 0 )
{
return abs_(a) < tolerance;
}
 

The following is matrix4.h with all of the changes. I changed only those functions I thought would be useful to someone who wanted T as something other than f32, hence, functions like for creating billboards are not altered.
http://codetidy.com/6557/

[CuteAlien]

Old topic, but I just took a look at that. And after changing it I realized that using T for everything is maybe really not what makes sense. Because right now one can use higher precision in matrix and still work for example with vector3df. Which would no longer be possible when using T as paramter everywhere. So this would either need overloads (for vector3d<f64> functions) or a second template parameter I guess. So I reverted changes back and let it be as it was - sorry.

I realize that changing it all to use T would make it better in the case you desribed. And writing it from scratch that might be how I'd write it. But as the change has advantages and disadvantages which make sense depending on how you use it, I'll rather keep it unchanged which won't break the interface at least.

[chronologicaldot]

Sorry to bring this up again.
Maybe we could add an opt-in #define that allows people to use true T for the matrix class if they wanted.
I'm just throwing that out there for the record.