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

[Eugene Trounev]

And don't forget KDiamonds, and KLines which too use animations quite a lot. 
And yes, those two also require frame-by-frame work. But then isn't that the 
way classic animation goes in the real world? (I am aware of the *new* 
techniques, but I can't really call those Flash generated, poorly timed, and 
repetitive vectoresque atrocities - animation :) )
Real artists don't use shortcuts :D :P

On Saturday 12 September 2009 07:14:46 Ian Wadham wrote:
> 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.
> 
> 
> 
> 
> 
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
>