libtagaro: New in playground/games

October 19, 2010

Project Tagaro aims to bring KDE games to mobile form factors and more. (crosspost from projects.kde.org)

libkdegames, the base library for virtually all games in the kdegames module, has aged considerably. Most of its components have been designed in Qt 2/3 times, and do not take advantage of Qt 4 goodness. Project Tagaro attempts to overcome the accumulated anachronisms and, among other things, make kdegames ready for mobile form factors.

Tagaro components are already getting used in kdegames starting from the 4.6 release: KGameRenderer, a first version of Tagaro’s theming framework, has already reduced code size and increased rendering speed in many KDE games. TagaroAudio, a simple Qt-style wrapper for OpenAL which brings low latency sound output to kdegames, will likely be used in Granatier soon.

As of today, libtagaro’s Git repository has moved to the new KDE Git server. Clone from git://git.kde.org/libtagaro.git.

And just a few words on how Tagaro relates to other projects in this area: Tagaro is completely separate from the Gluon project because I do not see Gluon getting a stable and nice API soon (see this review which I sent to the kde-games-devel mailinglist). I also am opposed to a library that renders only OpenGL; I want to keep that hard dependency out of kdegames as long as possible.

On the side of mobile form factors, there is Qt Quick which I cannot use at the moment because it does not have a widget set. I am looking forward to Qt Components and will try to use it for Tagaro when it reaches a certain stability, but that will not happen soon. Plasma has a stable set of components which can be used in mobile form factors, but Plasma developers indicate that they will be moving to Qt Components as soon as this is available, so I doubt I can safely rely on them, either. when this is stable, so the best long-term solution is probably to rely on Qt Components instead.

Advertisements

3 Responses to “libtagaro: New in playground/games”

  1. Aaron Seigo Says:

    “I am looking forward to Qt Components and will try to use it for Tagaro when it reaches a certain stability, but that will not happen soon.”

    that’s sensible.

    “Plasma has a stable set of components which can be used in mobile form factors, but Plasma developers indicate that they will be moving to Qt Components as soon as this is available, so I doubt I can safely rely on them, either.”

    this, however, is not so sensible and borders on spreading FUD (“libplasma is not reliable / stable”). our goal with libplasma is to move to QtComponents when it is ready. to reach that goal we are working with the QtComponents project to help ensure it has what we all need.

    to think we’d run and jump on QtComponents before it is ready and jeopardize everything built on top of libplasma is a joke. as i noted in my blog entry on it, this is something that is probably going take a couple of *years* to complete.

    for 4.6, we’ve worked a lot on getting QML support together so that one can use libplasma from QML. QML is not required, the Plasma widgets (which are really just themed QGraphicsProxyWidgets in front of “real” QWidgets for the most part) are still there and not going anywhere (how could they, from a binary compat viewpoint?). all of libplasma remains available from C++, Python, Ruby, Javascript, with the new addition of QML in 4.6.

    you’ve mistaken “we have a long term plan, with acknowledgements of which parts may not even happen”, which is a pretty good thing for ensuring the future health of a project, with “it’s unstable, we’re ripping it all apart at the first chance possible”.

    much like the theming system in KGameRenderer, i’m afraid that you’ll end up duplicating a whole ton of code needlessly with its own oddities and benefits. neither set of projects will get the best thing it could as a result. you do seem very intent on creating your own thing, however, and i do understand the allure of that and you are absolutely free to do so. please don’t justify that, though, with “libplasma isn’t safe” statements.

    • Stefan Majewsky Says:

      ” our goal with libplasma is to move to QtComponents when it is ready”

      That is what I meant. Availability implies stability for me; sorry if that was not clear.

      “[the transition to QtComponents] is something that is probably going take a couple of *years* to complete.”

      I highly doubt that Nokia will want to wait years for QtComponents, considering how important Quick appears to be for their whole development roadmap.

      “much like the theming system in KGameRenderer, i’m afraid that you’ll end up duplicating a whole ton of code needlessly with its own oddities and benefits”

      KGameRenderer is actually a merger of rendering code that is currently spread over dozens of games. I regret that we’ve missed the opportunity to communicate our needs for SVG rendering to Plasma folks (that was before I was concerned with this kind of problems). While Plasma::Svg is tuned for a bunch of SVG files, each of which represents a single graphical element (or a small number of graphical elements), game themes are single SVG files with dozens of highly complex graphical elements.

  2. damian Says:

    “Project Tagaro aims to bring KDE games to mobile form factors and more.”
    Thank you very much for briefly explaining what your project is before explaining the whole thing, every post in planet kde about apps should have this.
    About tagaro it seems a good idea. Kde games work slowly for me, if current kgamerenderer can’t be progressively get better I guess tagaro is a good thing


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s