Pyrrlicht / News: Recent posts

I'm pleased to say that I've (practically) completed implementing the irr.io module. The only exception is a few methods of the hideous irr.io.IAttributes type, namely the methods dealing with binary and enum types. I could do them, but I don't feel like it right now. I also see that there are very substantial additions to that class API waiting in Irrlicht SVN, so I'll have to revisit it for the next release anyway. It can wait. I want to move on to more immediately useful types. Like, for example, irr.video, which I thought I was going to do first but ended up needing to do irr.io instead.... read more

I'm pleased to say that I've (practically) completed implementing the 'irr' module. Not the entire package, just the module. The only exception is a few IrrlichtDevice get*() methods which return types implemented by other modules which haven't been created yet; but backfilling those will be trivial once the types are available.

This module was much easier than irr.core. In part this is because the extension wrappers are more mature, and also because the types in this namespace were just much less quirky than the core types. Hopefully this trend will continue.... read more

Finally, after weeks and weeks of groundwork and plumbing, I'm finally ready to start implementing IrrlichtDevice, arguably the singularity at the heart of the Irrlicht black hole. Maybe before long, I'll actually be able to create a real window. I'm all tingly with anticipation.

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.... read more

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.... read more

The decision to drop MSVC 6.0 is already bearing fruit. I've been able to implement templates (using partial specialization, which 6.0 doesn't support) to eliminate a huge amount of boilerplate for implementing Python type method and property wrappers. See python_convert.hpp, python_property.hpp and python_method.hpp if you're interested.

Now, don't get me wrong: this isn't the world's most elegant code. It's downright kludgy compared to something like Boost.Python that is able to autodetect method signatures more or less automatically. I ended up writing lots of overloads and even more specializations to handle that problem.... read more

After spending a few weeks wrangling with MSVC 6.0, and having it reject pretty much all code that would cleverly eliminate a lot of boilerplate, I've decided enough is enough. MSVC 6.0 is holding back the project.

So, I've decided to dump it. As of now, Pyrrlicht will not support build on MSVC 6.0. Good riddance.

As a side effect of this decision, I am also officially deprecating support for Python 2.2 and 2.3. Those versions were built using MSVC 6.0, and while I think a .pyd built using, say MSVC 7.1 would work fine with those versions, it's not "officially" supported. I won't deliberately break build with pre-2.4 Pythons like I am with MSVC 6.0, but neither am I going to support attempts to build for those Pythons.... read more

Well, I was wrong; PyCXX isn't worth it after all. While I was working with PyCXX, I've came to realize that the major difficulty with direct use of the Python API is mainly correct ref-counting, particularly in the face of error conditions.

Having implemented a py_handle<> class template to take care of that, the rest of the PyCXX Object API suddenly seemed like a lot of syntactic sugar; a fairly superficial mapping of the API to C++-style object tree. Nice if you're not familiar with the Python API, but I am. I think it will be no more difficult to just use that, now that ref-counting is automated.... read more

I'm still working on PyCXX. I just spent several days heavily revising what I've done so far on the Object API so that MSVC 6.0 will swallow it. Having finally succeeded in that effort after much tearing of hair, I just want to say that MSVC 6.0 should have been called MSVC 666, because it is clearly the anti-compiler.

Oh, I also made the code compile on MinGW GCC 3.2.3. That took about 90 minutes, 45 minutes of which I spent eating lunch. It was quite refreshing to be fixing things that were actual boneheaded errors on my part which MSVC completely failed to notice, as opposed to obfuscating perfectly good standards-compliant code so as to coax MSVC 6.0 into accepting it.

Right now I'm on a (hopefully brief) diversion into PyCXX. PyCXX has the potential to substantially improve coding safety and productivity for Pyrrlicht, without the considerable overhead (both runtime and development-time) introduced by other tools like SWIG or Boost.Python.

Unfortunately its type extensions are still pre-Python-2.2 in nature and can't really support binding Irrlicht very well. So, I'm doing a very substantial rewrite of the lib to bring it up to date. I think it will pay off in the long run.

The Pyrrlicht project is born. Let's see where it leads...