[pyrrlicht-developers] Implemented irr.core

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

I'm pleased to say that I've completed implementing the irr.core module.

Well, anyway, as much as I'm going to do at this time. Actually, a few 
types remain unimplemented: array, list, string, irrAllocator, and 
irrAllocatorFast. The allocator classes have no relevance to Python and 
as such will never be implemented. The utility types array, list, and 
string may be implemented eventually in the interest of completeness, 
but given that Python provides built-in types to do what these types do, 
I don't view them as important enough to spend time on until after the 
rest of the binding is working.

This module was a bit of a bear. I've tried hard to faithfully reproduce 
the signatures of the functions, but there were three major issues that 
regularly tripped me up.

First was the C++ practice of using non-const reference parameters to 
return values. This is natural in C/C++, since you can only return a 
single type from a function and its a drag making structs and whatnot to 
get around that. Python, on the other hand, more naturally returns 
different types or tuples in the same sort of situations. For example, 
some functions returned bool and an output parameter, the bool signaling 
when there was no meaningful result. In Python we handle the same 
situation by returning the value if valid and None if not.

The second is C++ overloaded functions. Sadly this forces me to 
hand-implement the functions. Not a big deal, but it does break one's 
rhythm.

The second and much more vexing issue was the basic problems in the 
Irrlicht codebase itself. This was particularly an issue with the 
various types like vector3d that are templated and come in float and int 
flavors. Nearly every such type with non-trivial member functions 
displayed conversion warnings and sometimes outright build errors when 
instantiated with int types. Some of these problems are unavoidable, 
such as attempting to normalize most integer vectors, while some are 
just the result of poor testing. These sorts of problems led to a lot of 
ugly cursing on my part and even uglier workarounds, since I can't fix 
the issues directly in Irrlicht. But in the end, the int variants got 
implemented. A related and less common problem was the occasionally 
flubbed function signature; taking a param by value instead of the 
obviously more appropriate reference, for example.

I'm sincerely hoping that the int/float related issues will not reoccur 
throughout the rest of the library. That by far was the most troublesome 
issue. Reference parameters and overloaded functions are inconveniences, 
but at least well-solved issues. The build breakage required different 
custom workarounds unique to every situation, and were a huge time sink.

Up next: the irr.io module.

--- Kevin