6/16/2005 @ 2:47 pm by Daniel Eisner
I’ve decided to start blogging about the progress of Alities. Partially, this is because I think that I will make progress much faster if I think that anyone else other than me cares about it. This is somewhat backed up by the fact that my previous posts has quickly become one of the highest hits on the site.
Unlike AmorMD2, Alities is broken down into a very discreet structure. This is to support a plugin model. The core of Alities is nothing more than a plugin-loader, and some basic event queue logic. Behavior of the Alities, ability to detect event on the computer or network, and even the rendering code is provided by plugins. For the first release, I am targeting similar functionality to AmorMD2. This will consist of 3 plugins:
1. An MD2 Renderer
2. An X11 Window Event Detector
3. An “Amor” behavior plugin
So far, the main framework is mostly done. The MD2 Renderer plugin is about half complete, and it can generate graphics which are better than amorMD2 could — you’ll notice in this screenshot that it is correctly rendering the model’s weapon (optionally), with correct texture mapping.

I am just getting started on the X11 Window Event Detector, and I expect that that will be the only remaining complication. Basically, Alities only cares about a small subset of X events; it wants to know when windows are moved, resized, or reordered. It wants to know when focus is switched, and also it needs to be able to grab a global state of the windows on the screen. This last one especially is not as simple as it would seem at first. Both QT and GTK have facilities for grabbing the global state, but they seem limited to only the current application. Let me know if anyone has done this sort of project before, or if there’s a good example out there. In the meantime, I am going to look at the approach ‘pagers’ use, and see how difficult it would be to duplicate that.





