pyrrlicht-developers

[Kevin B. <kev...@gm...>]

With a sigh of relief, I have completed implementation of the last of 
the float/int irr.core class templates, triangle3d<T>. Most of these 
types, including but not limited to triangle3d, have very significant 
problems when T is an integer type. A number of member functions 
actually generate compiler errors, usually due to ambiguous overloads of 
stdlib math functions like fabs(); they're overloaded on float types, so 
when an int type comes along all the overloads are equally attractive, 
and the compiler is forced to ask for clarification. Considerably more 
member functions generate ugly conversion warnings; converting a signed 
int either to or from a float generates a warning, and often 
ill-considered typecasts littered throughout the Irrlicht code makes the 
problem even worse. Many member methods, like the intersection tests or 
normalization, really can't sensibly work with integer instantiations at 
all. I generally had those either return float types or raise 
exceptions. Lastly, a number of methods generate bogus results, even if 
they compile cleanly. For example, there are a number of places where 
you see code doing a divide by 2 like so: x = y * (T)0.5; Of course, if 
T happens to be int, 0.5 immediately truncates down to zero, and so the 
expression will always return zero. Those had to be completely 
reimplemented inside Pyrrlicht.

Since I don't want to maintain a custom version of Irrlicht, I've made 
workarounds for all these problems without touching the Irrlicht source. 
This ended up making the wrapper code for these types significantly 
messier than it ought to have been. For the triangle3d types, as an 
example, I had to hand-code fully half of the member functions due to 
various issues with the Irrlicht codebase. I wouldn't have done it, 
except for the existence of explicit typedefs for irr::s32 versions of 
most of these class templates like irr::core::triangle3di. It's pretty 
clear, though, that if Niko has ever used the int versions at all, its 
been only very superficially.

So, the moral of this story is, if you have a choice you probably 
shouldn't try to use most of the irr::core class templates with integer 
types. It's ugly.

--- Kevin