WaterStone Productions

Hola,

Okay, well I've been putting a lot of stuff into the engine lately, just nothing major gameplay wise yet.  I'll go over the major additions to date.

For one, as of today, there is no longer a need for the user to supply a python library to link with.  I downloaded the latest compatible python that would work with Boost.Python (2.6.1) and slowly found a way to get it to compile.  There's a lot of modules that won't work and stuff I have non compiled, but the demo code works, so it's a start.  I'm going to include everything that is needed as a built in module, since there's no dynamic module loading.  I'm also going to set the PYTHONPATH to a special directory where the python standard library will be.  So eventually no matter where you compile this, each user will be able to use the same python version.  I wanted to do 3.0, but it's too big of a change to work with Boost.  Also, I thought about stackless, but I couldn't get that compiling.  So Python 2.6.1 it is.

I've also been working on creating a collision framework that objects can use.  I imported the library ozcollide into the system, and I'm going to have basically two different types of non-physics collisions.  The first type is defining a collision tree of standard objects (backgrounds, sprites, etc).  What you do is create a spritegroup or a backgroundgroup, and add ids of the ones you want included.  After you have it build the tree, you can test a collision object against them, and it should be more efficient than having the collision object tested against every single collidable object.  However, the tradeoff is that I don't think you can update the positions (centers) of these collision objects in the tree, so it works best if you only use this for objects that won't move (like background tiles).

The other thing is just going to be a collection of overlapping and intersection tests, so that any sprite or background could be tested again any other sprite or background.  It's less efficient but it allows for people to do as they want collision wise.  I'm not going to include polygon shapes from ozcollide yet, since I think for anyone who wants that much precision in collision, would be better off just using the physics manager (box2d) which allows that easily.

All sprites and backgrounds (and eventually boxes, fonts, etc) will hold a collision object that has the ability to move/update it's position, as well as inform you if it has moved since last you checked (similar to the background method hasViewMoved).  If you're moving a sprite around and expect to be able to use it for collision testing, you need to be able to call this method.  I haven't figured out how to allow this from python yet but I'm working on it.

The demo still doesn't use the collision but it will shortly I hope

Finally, I rewrote the actor/map stuff back into python since it was getting too out of hand to work on them in C++, and the speed is still good in python.  In the future I may include some kind of pyrex thing so that even python code could be sped up.  However, I'm still on the fence as to the folder scheme/naming system.  I suppose I'll probably make user addons part of the site-packages in the built in python library, but I want to establish a naming scheme so I won't have something as simplistic as addons.rpg.etc

Oh well, more work ahead, later!