Work has been keeping me pretty busy, but I’ve managed to make some progress on Alities. Mainly, I implemented search paths for zip files, so you can install characters system-wide, or only in your own home directory. Also, I’ve set up a Fedora Core 4 as well as an Ubuntu system for compiling. This means that I’ll be putting out RPMS as well as Deb files when I’m ready to start distributing it.
Today I made some significant progress on the X11 plugin for Alities. This plugin allows Alities to detect when windows are moved around on the screen. I was really worried about the feasibility of accomplishing this task, because as Alities may run from within existing widget sets (ie, KDE/QT, Gnome/GTK, etc), I thought it would be more complicated.
The solution was to create a separate connection to the X server, register which events we are interested in (window manipulation), and then launch a separate thread to listen to those events in an infinite loop. Rather than gathering all the information about each event (which might be time-consuming), the plugin simply flags that an event occurred. When the main Alities thread requests the pending events, they get generated dynamically. This way, multiple window events can be consolidated, resulting in shorter event queues.
I consider this to be the last of several technical hurdles which I did not look forward to. Now, the rest of the code is basically just an exercise in patience
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.
Someone left a comment on my amorMD2 page, asking if I had submitted it to KDE. It was a very timely answer, because I have been working lately on a new program called Alities (as in “personAlities”). The idea behind Alities is to completely throw away the legacy amor code, and develop a complete desktop buddy engine. The advantages are as follows:
– Better Graphics
The original Amor code was limited to a certain frame rate, and a certain number of animation frames. By going to a true real time 3D engine (instead of lazily-rendered, then cached frames), the animation will be much more fluid, and more flexible. Especially when used with bone-based model animation.
– Better and Customizable Behavior
Again, the original amor code behaves pretty simply. If you switch windows, it goes to the new one. If you leave the computer alone, it goes to sleep. Otherwise, it more or less just moves back and forth on top of your current window. That’s it. With Alities, your character can decide to take pot-shots at your mouse cursor. Or, it can get bored and start wandering around your background windows. Or maybe it will decide you are working too hard, and stomp on your current window to move it down a few pixels. You might have more than one Ality on your screen at a time. Maybe they won’t get along, and will have a little war with each other until one of them is dead (IE, the process shuts down).
– Plugin model
Initially, Alities will come with plugins to support loading Quake 2 characters, listening to Window Manager events, and D-BUS messages. It will also come with several behavior models like those described above, from which you can pick and choose how you want your Ality to behave. Afterwards, I will be releasing plugins to load Quake 3 characters, Unreal Tournament (2k3 and 2k4). The next version of Alities after that will feature a binary XMLRPC interface, so you can send your alities to other people’s desktops (if they are also running Alities). Maybe they’ll act as your autonomous emissaries. Or, if you want, you can take direct control of them, and have them do whatever you want — I’ll keep what you can do a surprise for now.
Anyway, most of that is just on the drawing board today. Right now, Most of the framework and much of the MD2 plugin is complete. I have to finish some of the basic plugins for window-manager and D-BUS behavior, and then I will release Alities. With that release, I will probably submit it to KDE for inclusion, and possibly Gnome as well. Alities is written font-end agnostic. At the moment, it has a KDE front-end, but a Gnome front-end will be included with the first release. An MS Windows front-end is also possibly, being taken into account from the beginning (unlike amorMD2). Unfortunately, most detection plugins like the window manager and D-BUS won’t be effective on MS Windows, so support for that may be much farther down the line.