KDE Commit-Digest
Hi, my name is Dan or Leinir, depending on who you ask. I've long been a member of the Amarok team, but lately i'm also one of the guys behind the Gluon project. Roger asked me to do a bit of a run-down of recent developments in the Gluon project, which has been somewhat more quiet than what was indicated last fall and early this spring, where we were running the hype engines at full blow - sorry about that, people, I hope nobody's toes were stepped on too hard! The reason we have been so quiet is that we have been hard at work on numerous developments
Thanks to Shantanu Tushar Jha's work for Google Summer of Code on the Plasma-based Gluon Player application and accompanying library, we now have a client which will download and play games, as well as comment on them directly from your desktop through the Open Collaboration Services, interacting with the GamingFreedom.org test website at test.gamingfreedom.org. This is made possible by using libattica, which has recently also been marked as a part of the core of the MeeGo platform, and by the gracious donation of hosting space and software by Frank Karlitschek of openDesktop.org fame.
The new scripting engine, which is much more powerful than the very simplistic old one, was merged in and is ready for testing out. Just like the old one it is based on QtScript, but uses a monolithic engine as opposed to the multi-engine system the old one uses. The result of this is that you can now call functions across script-object borders. While this seems an obvious thing, the old system simply did not allow for that to be achieved. So, while we were at it, we also implemented a system by which the single core hands out instances of classes as opposed to copying code in and running it, which also turns out much more efficient at runtime - both memory and CPU. So, all in all a much more performant QtScript-based engine has surfaced. All is not roses, however, and this engine still needs a lot of work - including the fact that we would like to use the JSmoke-based QtScript bindings, which it is understood still needs some work. We therefore invite anybody who has experience with QtScript to join us both in #gluon and #kde-bindings to work on this.
The shiny new GluonGraphics refactor has been merged in as well. This is the culmunation of around half a year's worth of work by Arjen Hiemstra, who has been busy replacing the old fixed pipeline based codepath with a modern programmable pipeline based one. The rewrite has now reached feature parity with the old engine, and has been merged in. It may seem silly to redo everything like this, but the reason is simple: The old GluonGraphics code was stuck in a corner and could not move, where the new is much more flexible. The upshot of this is that two days after receiving an N900 from Nokia, Arjen had a simple, laggy and unoptimized, but still running version of GluonGraphics on Maemo5. Two days.
On top of this, the new materials system lays the basis for implementing a powerful Shader-based graphics effect system, which will be exposed in our game creation tool Gluon Creator in a graphical manner. Eyecreate, one of our Google Summer of Code students, has created a generic node editing system, based on the powerful Rocs codebase, which allows you to piece bits of pre-existing logic together. In essence, Lego-style programming (except more granular ;)). So, combine those two and you have a node-based graphics effects editing tool.
Finally, the most recent developments are that Papp "djszapi" Laszlo has offered to extend and improve the GluonInput system, which has needed this work done to it - some may remember that some unpleasant permissions editing need to be done for GluonInput to be able to handle keyboard input, and he is currently working on that, as well as touch input. So, GluonInput will very shortly support Harmattan, the software which will most likely run on Nokia's upcoming rumoured N9 device, as well as on MeeGo.
Finally, at the time of writing, Giulio Camuffo has begun working on a tilemap system for terrain. He is wanting to build an RTS on top of Gluon, and has offered to implement this system directly into GluonEngine in a generic manner, so as to help others who may have similar needs in the future.
The future is, in short, sparkly and bright, with lots of flashy and shiny effects all over your of course super-nifty, self-made and socially distributed games!
