pyrrlicht-developers Mailing List for Pyrrlicht
Status: Pre-Alpha
Brought to you by:
kbluck
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Kevin B. <kev...@gm...> - 2007-01-26 01:11:13
|
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. This module was also much easier than irr.core. There were some wrinkles due to Unicode issues and void* buffer parameters, but nothing that proved extremely difficult. IAttributes was the worst due to the large number of member functions and overloads. Up next: the irr.video module. Really. Soon, I'll actually be able to draw something. Really. I mean it this time. --- Kevin |
From: Kevin B. <kev...@gm...> - 2007-01-16 18:51:35
|
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. Up next: the irr.video module. Soon, I'll actually be able to draw something.... --- Kevin |
From: Kevin B. <kev...@gm...> - 2007-01-10 19:54:46
|
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. --- Kevin |
From: Kevin B. <kev...@gm...> - 2006-12-15 22:51:48
|
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 |
From: Kevin B. <kev...@gm...> - 2006-12-13 19:37:00
|
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 |
From: Kevin B. <kev...@gm...> - 2006-12-08 04:16:37
|
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. But while this stuff clearly is not as elegant as the Boost solution, its implementation is also not nearly as complicated and way easier to understand... and I've got it working in a few hours. My thought is that this isn't intended to be a general binding library like Boost.Python, so time invested in getting it to that level of generality wouldn't be well spent. In the meantime, what I have here should serve quite well to eliminate boilerplate. Now I'll have to look into using it for implementing __init__() methods, and how to work it into "overload" implementations. --- Kevin |
From: Kevin B. <kev...@gm...> - 2006-12-08 04:15:16
|
After spending a few weeks wrangling with MSVC 6.0, and having it reject pretty much all code that would usefully 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. --- Kevin |
From: Kevin B. <kev...@gm...> - 2006-12-08 04:13:43
|
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. As for the PyCXX Extensions API, I'd hardly even touched that. I can see that as of now it doesn't do a whole lot of things I'm going to want to do, and what it does do it does in a rather antique way dating back to Python 1.5.2. Bringing it up to the post-Python 2.2 state of the art in type extension is going to be a very significant project all by itself. I flat-out underestimated the scope of the changes I would have to make. So, farewell PyCXX. It's now banished from trunk and relegated back to its own vendor branch; I'll decide what to do with the incomplete refactoring work later. Probably I'll finish what I was doing with the Object API and hand it over to the PyCXX project to do with what they will. --- Kevin |
From: Kevin B. <kev...@gm...> - 2006-12-08 04:12:32
|
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. --- Kevin |
From: Kevin B. <kev...@gm...> - 2006-12-08 04:11:39
|
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. --- Kevin |
From: Kevin B. <kev...@gm...> - 2006-12-08 04:04:25
|
The Pyrrlicht project is born. Let's see where it leads... --- Kevin |