• Major overhaul of the instance matching routines.  They are now much faster and more accurate.
• Added mouse sensitivity and acceleration options.
• Fixed some problems with memory in the Image Manager.
• Dragging the mouse (with a mouse button down) now behaves as expected.
• 1024×600 is now a valid resolution to run FIFE
• PyChan widgets can now be shown/hidden even if they are not the top container widget.
• Editor icons have been replaced with free ones

Thanks to everyone who contributed to this release!

In other news we are planning on changing our release strategy a little bit.  We want to avoid having to release these “fix” releases.  The plan is to release a “release candidate” sometime before we actually release 0.3.4 to allow for more testing to be done.  Hopefully this prevents us from having to re-release a few weeks after.

Special thanks go out to the Unknown Horizons team for making this release possible.  We were fortunate enough to get a student for GSoC this year through them so we are all very grateful.  The summer of code turned out to be very successful and our student (kozmo) made some huge performance improvments in the OpenGL renderer and added a lot of great features.  Thanks Kozmo!

There was so many changes to FIFE in this release so I’m not going to list them all.  Here is a quick summary of all the key improvements:

• Many optimizations/improvements to the OpenGL renderer
• Colour overlays have been optimized
• Can now draw/modify images
• Resource pools have been completely re-written from the ground up
• Clients can now specify the colour to use when clearing the screen
• Some changes/optimizations to the light renderer
• Initial support for C++ map/object/animation loaders
• Image Atlas support and Atlas editor
• Optimizations to the Guichan graphics renderer

Its been a while since we last updated the blog, and boy have a lot of things have happened in that time! I’ll try and outline what we’ve accomplished in the past few weeks below.

Moving On Up (to Assembla Source Hosting)

The single biggest change we’ve made is that we now use Assembla (http://assembla.com) as our source repository host. Although Codesion, our previous host, has done a lot for us over the years we decided that it was time to update to a distributed version control system and Codesion’s offerings in that area simply did not meet our requirements. However, we will continue to use our Trac page for bug tracking and keep our old svn repository online, at least for the foreseeable future.

One of the really neat things about Assembla is that it is built with Agile Programming methods in mind. Our Assembla workspaces provide tools for asynchronous communication, posting progress reports, viewing repository changesets and managing milestones and backlog items. Although we’re still getting used to Agile methodology, I think that most of us would agree that it has significantly improved our communication and collaboration habits. Overall, we’ve been very impressed with Assembla’s free hosting. It is by far the most professional free host we’ve seen, and has tons of features that we haven’t even figured out how to use yet!

Feel free to explore our Assembla pages at http://parpg.assembla.com and get a feel for how it all works.

Through the Looking Glass: From Subversion to Mercurial

One of our primary reasons for changing source hosts was that we wanted to migrate to a distributed version control system (DVCS). Subversion simply wasn’t scaling well enough for us, since we often had two, three or even more developers working in parallel. Add in the fact that each of those developers was working on some experimental changes and… well you get the idea.

So we said good bye to subversion (well, sort of – see below) and migrated our codebase to Mercurial. We narrowed down the field to either GIT or Mercurial, and most of the developers agreed that the learning curve of GIT was too steep compared with Mercurial’s subversion-like behavior and commands.

There have been a few stumbling blocks to implementing and using the new Mercurial repositories, but we’re starting to get used to the new workflow. So far the extra flexibility of Mercurial has been very useful, at least to the programmers.

Three Repositories Are Better Than One

As if changing our source host and VCS wasn’t enough, we also split up our codebase into three separate (but related) repositories: parpg-core, parpg-assets and parpg-tools.

The parpg-core repository contains the core code framework which makes up the PARPG application, and as such contains the majority of our Python source code.

The parpg-assets repository contains all of our game data – object definitions, sprites, maps, dialogs, music and sound fx, etc. Unlike the other two repositories, which are Mercurial repositories, parpg-assets is a subversion repository (the reason for this is explained below).

Finally, the parpg-tools repository contains the source code and supporting assets of the various tools and utilities we’ve developed over the years to help us create game content.

Our justification for splitting up the code like this was that the binary asset files don’t change very often and yet comprise the bulk of the storage space (more than 200MB in all), which would have significantly slowed down clones of the repository (DVCSs copy all history in their “check-outs”). Compounding this problem was the fact that Mercurial (and most other DVCSs, actually) don’t handle changes to binary files well and tends to create a lot of bloat with each commit. To solve this issue, we moved most of the binary files into parpg-assets – a subversion repository which is able to handle changes to binary files much more gracefully.

To prevent parpg-core from drifting apart from parpg-assets and parpg-tools, we made parpg-assets and parpg-tools subrepositories of parpg-core. What this means in practice is that any time you clone parpg-core, you will also clone/checkout parpg-tools and parpg-assets, respectively. This is a feature of Mercurial that was really fleshed out in the 1.7 branch, so you’ll probably want the most recent version of Mercurial clone parpg-core.

Distutils, SCons and (now) WAF, oh my!

Just to make things as confusing as possible we also changed our build system (twice). Originally we used Python’s distutils installer to build and install everything, but unfortunately as the project grew more complex we discovered that distutils was very difficult to extend and was really starting to slow down development. To be fair the distutils module was developed to build, maintain and install Python libraries, not games with thousands of assets and dozens of tools.

SCons seemed like the natural replacement for distutils, since FIFE (our rendering engine and game framework) uses SCons as its build system. But right from the start we ran into problems with SCons. First, SCons didn’t like our Python code and we had to write a custom extension to get it to correctly install and optionally compile our Python code. Then SCons didn’t like our 8,000+ asset files and we had to write ANOTHER extension to get it to correctly copy our assets (and very, very SLOWLY at that). Then SCons had issues verifying which files had changed between the build/installation directory and the source, which required YET ANOTHER extension (you can see where this is going…).

In the end, we abandoned SCons in favor of its bastard child, WAF. WAF is an old fork of SCons that was developed by a couple of KDE developers. Although much less mature than SCons, WAF has proven to be more than stable enough for our purposes. So far, WAF has been very easy to work with: our current build script is a fraction of the size of our previous SCons buildscript, and yet does everything that SCons could do and more. WAF is also many times faster than SCons, which makes development a lot quicker. Finally, WAF comes as a self-contained script, which means that we distribute WAF along with PARPG – eliminating any issues with users using an outdated or incompatible version of the build software.

Our WAF build system is still being tested, but it should be in the main parpg-core repository soon!

The Times They Are A-Changing

We have even bigger changes planned in the weeks and months ahead, so stay tuned!

Kozmo’s major work in improving the OpenGL renderer is broken down into several smaller tasks.  He has reviewed our code and has begun refining some of the OpenGL calls to be more efficient.  This includes keeping track of OpenGL states in the engine rather than querying it directly which saves time and also saves redundant calls.  We are also moving to a newer version of OpenGL that gives us access to a lot more OpenGL features including vertex buffers and non power of 2 textures.    Some other tasks he is working on right now is to add texture atlas support to minimize the texture changes in OpenGL.  This would allow us to potentially render an entire layer in one call!  Kozmo already has a working prototype of this and he has seen some major improvement in framerates.  Good work Kozmo!

As always if you have any questions feel free to stop by in our IRC channel or drop us a line in our Forums.