[Kde-games-devel] Animated sprites in KDE Games (was Granatier)

[Ian Wadham]

On Sat, 12 Sep 2009 3:31:16 am Arturo Silva wrote:
> I still don't know why few of the KDE games use animated
> sprites (KGoldRunner is the only one that comes to mind, because even
> KSpaceDuel just moves shapes around which is different), and I worry
> the reason is technical since this will limit the ability to make
> really eye-catching games.  Not to say we can't work with a static
> environment, but if at all possible this really should be something to
> look at seriously.  Granatier has many places where animation can be
> used to make the gameplay more lively and exciting (and I've already
> mentioned a few to you).  As I look into contributing some artwork to
> this, I'll see if maybe I can help discover the mystery behind
> animated sprites in QT4.  ;)
>
Apologies for hijacking this thread, but you are new here, Arturo,
and you *did* ask ... :-)

By animated sprites I presume you mean those that change shape
as they move, as in walking, running, swimming or bird flight.
Basically I think the reasons are both technical and cultural.

On the technical side, there are both performance and artwork
problems.  Let's take artwork first.  Blender (a 3-D modeler) has
good support for animation art.  You can give a figure a skeleton
(called an armature, for some reason).  You then "pose" the figure
in a few stages of its animation cycle and Blender generates all the
frames in between, including movements of joints, etc. The SVG
standard includes animation and Inkscape had some plans for
implementing something like the Blender scheme in 2D, but
AFAIK nothing eventuated.

So, if you want animated sprites in SVG the artist must draw every
frame individually.  KGoldrunner has fewer frames than it should
but each theme has 108 SVG elements.  36 each for the hero, the
enemies and gold-carrying enemies.  Mauricio Piacentini, Eugene
Trounev and Luciano Montanaro put a LOT of work into them!

Re performance, KGoldrunner ran fine in KDE 1 and 2 using just
QPainter.  Then along came QCanvas in Qt 3, billed as the greatest
thing since Hannibal crossed the Alps, so I rewrote the graphics to
use QCanvas and it still ran fine.  The graphics in that version were
pretty crude --- 16x16 pixmaps, drawn a pixel at a time, using an ancient
program called KIconEdit, which was restricted to the 48 KDE 2 colors.

With Qt 4, Trolltech abandoned QCanvas, replacing it with QGraphicsView,
which was billed as an even greater thing than Hannibal, etc.  Mauricio
kindly offered to port KGr into Qt 4 and KDE 4.  Little did he know what
he was taking on.  Altogether he rewrote the KGr graphics *3 times*:
Q3Canvas (compatibility) was far too slow, QGraphicsView was OK
most of the time but sometimes it hiccupped for major parts of a second,
temporarily freezing the animation and making the game unplayable,
Finally he settled on KGameCanvas (which was written by Maurizio
Monge), now in the KDE Games library, but unsupported.  However
it never seems to go wrong and gives us much faster animations than
QGraphicsView for those games that need them.

Re the cultural reasons: KDE Games is part of KDE and so uses KDE
and Qt libraries and various standard GUI approaches.  Also, we did
a survey a few years ago and found that there was a demand for small
games that would run in a window on a desktop, as opposed to the
kind of game that goes full-screen and stays there and has its own GUI.
The users also demanded better graphics, so we have gone in the
direction of SVG and themeing in our KDE 4 offerings.

Strictly speaking, for a program to be a KDE game it must be a KDE
application and include the standard KDE application framework.  And
make no mistake, that has worked out well so far.  Most KDE Games run
well in the KDE/Qt framework.  Unfortunately, real-time games with fast
action and sounds do not fit the mould so well.  Maybe it is time for us
to loosen up a little.

All the best, Ian W.
KGoldrunner author.