Pyglet engine work

One of the things that has blocked the project for so long has been a shift of the engine from Pygame, which is easy to use but relatively slow because it does its rendering in software, and furthermore doesn't play well with any Python speedup module other than Psyco, to something else that's hardware accelerated and will work with PyPy.  That something else being: pyglet.

But despite the fact that it's been around for a few years now there's not a huge amount of stuff on the web about pyglet.  Most of what I've found has been its own documentation and a presentation called Stretching pyglet's Wings.  A few months ago I did a promising graphics test that taught me a bit about how pyglet puts together its images.  Now I've gotten something like that going in a tile engine, and it looks promising.

The reason for making the switch, and also for trying out weird cellular automatic schemes, is that, under the old system, I wasn't getting the performance that I was looking for.  When you're simulating only a portion of the world instead of the whole thing each frame, some things start to act funny at the edge of the simulation frame.  For something like Life that would be deadly, but here in practice it doesn't seem to cause huge amounts of problems so long as we spend some time at the start of simulation calculating over the whole map, in order to let fluids settle.

But it does have one problem that has always bothered me greatly, and that is, we can't have running "rivers" in the simulation between two distant points, because if one of the points is outside of the simulation frame the whole flow stops.  This means that most bodies of fluid the player encounters are static, which greatly limits the utility of having a cellular engine game in the first place.

Well performance-wise pyglet looks like it's got what it takes.  It can display a whole screenful of tiles nearly instantaneously.  Pygame takes a lot more time to do stuff like that unless you use tricks like only drawing parts of the screen that have changed, which is somewhat problematic for a scrolling game, and even more problematic for one where arbitrary tiles may change each frame.

pyglet

The most annoying thing about using pyglet, by far, is that nearly all the good sources on the library are either 1. the "Pyglet Programming Guide," available on the pyglet site in PDF form which is unwieldy and concerned with getting you started with the barest basics and little more, or "Stretching pyglet's Wings," which is a bunch of presentation slides with accompanying source code archives.

Maybe something to talk about soon....

Having to deal with a maze of personal issues, there hasn't been much to talk about concerning In Profundis lately.  (Some of them have had to do with negative comments on the blog here -- please, don't berate me for the time it's taking, I already know and feel awful enough about it as it is.  But I have to keep myself fed.)  But I might have something to tell regarding the "sort algorithm" I mentioned before, that I've been thinking very hard about lately concerning modelling falling and mixing fluids.  I think the idea is genuinely novel, and so maybe some of you might get some use out of it?  At the very least it might represent a substantive step towards getting this thing finished.  I still have tests to run with it though.