[Kde-games-devel] Deprecating KGameCanvas

[Matt Williams]

On Saturday 19 April 2008 08:30:08 Ian Wadham wrote:
> Hi guys,
>
> On Thu, 17 Apr 2008 11:23 pm, Matt Williams wrote:
> > Am I right in thinking that KGameCanvas and friends should be officially
> > deprecated? Maurizio posted [1] about the reasons. If it should be, is
> > the attached patch the correct way to do this?
>
> [1]http://myrizio.wordpress.com/2007/07/31/putting-kgamecanvas-to-sleep-for
>ever/
>
> Well here is a subject that is dear to my heart ... ;-)
> I am also replying to Matthew Woehlke's query of four days ago re "which
> is the best class to use for drawing unmanaged graphics".  Sorry to be a
> bit slow - I was up to my neck in annual bookkeeping and tax ... :-(
>
> Just discovered link [1] above although it was written in July last year. 
> The writer (Maurizio Monge) is of course the author of KGameCanvas and he
> ought to know ... so deprecate away Matt! ... and Matthew, don't use
> KGameCanvas because it is doomed, even though it is easy to use and I think
> it still performs the best for simple, fast-response, 2-D graphics.
>
> BTW, Matthew, AFAIK the doco is embedded in the source code, down in
> /kdegames/libkdegames, and can be extracted with Doxygen.

And in fact can be viewed at 
http://api.kde.org/4.x-api/kdegames-apidocs/libkdegames/html/index.html.

> I notice that said reference [1]'s discussion mentions re-conversion of
> KGoldrunner to QGV (who is going to do this?) and conversion of Tagua
> (formerly KBoard).  Did you convert Tagua already, Maurizio?  How did it
> go?  A quick search of http://lxr.kde.org for KGameCanvasWidget reveals
> that KBattleship, KBounce, KMahjongg and KBreakout also use KGameCanvas,
> so it is not dead yet ...  Five games, plus Tagua, use it.
>
> Also KGameCanvas has required very little maintenance lately (or ever)
> and it has served us well, so why should we deprecate it?  It just seems
> like more "module-driven maintenance" to me and I am sick to the
> gills of that personally.
>
> Why?  Well, since KGoldrunner started, in Qt1/KDE1 times, it has gone
> through six writes and re-writes of the code for the primitive graphics.
>
> Originally it had a long-lived QPainter and just erased and painted stuff
> as and when the need arose, then Trolltech changed the rules - you had
> to do everything with a short-lived QPainter in a paint event.  Then there
> was QCanvas - hailed as the greatest thing since Hannibal crossed the
> Alps and nominated as the recommended graphics system for KDE Games
> at the time (sound familiar?) - so I converted KGr to it.  It worked well.
>
> Along came KDE4, Qt4 and QGraphicsView and my heart sank into
> my boots.  Not another re-write!  And I was wanting to launch Kubrick
> two years ago, not convert KGoldrunner.  But a nice guy called Mauricio
> came and offered to take over the wheel.
>
> Uh-oh!  He converted to Q3Canvas (KGr graphics engine no. 4) and it
> was hopeless.  It just could not keep up with the game timing.
>
> So he converted to QGraphicsView and the trouble started ... luckily on
> level 2 - because only certain levels were affected.  The game would just
> pause or "hiccup" at random, ruining the timing and game play.  It took
> the two of us weeks to track down the causes and then Trolltech were
> unable to do much about them in the short term, so Mauricio switched
> to KGameCanvas, with my blessing - KGr graphics engine no. 6 and the
> most successful yet.
>
> People say that QGV has overcome the problems that beset KGr, but I do
> not believe it.  I saw a Trolltech blog or mail thread about this a few
> months back, but the usage case they were solving was not the same.
>
> Today I tried a QGV benchmark on a newer, faster machine than I was
> using two years ago.  Go to qt-copy/examples/graphicsview/portedcanvas
> and run ./portedcanvas &, hold down the Alt key and hit E and S ten or
> twenty times (that does 10 or 20 "Edit->Add Sprite" actions).  Although
> the simulated sprites do not have to move very fast, they still move
> jerkily, even on a faster machine, with Qt 4.4.0-snapshot-20080214,
> especially when the sprites are scattered around the canvas.
>
> So if some young iconoclast ever decides to drop KGameCanvas from
> the KDE Games library, I shall simply clone the code and link it into
> KGoldrunner.  I am not prepared to go to the effort of re-programming
> for QGV (KGr engine no. 7), finding out if Trolltech have really solved
> the problems Mauricio and I found and, if not, chasing versions until
> Trolltech come up with one that handles animation efficiently in all
> possible cases.  If the KDE Games team "deprecate" me cloning KGC,
> I will go back to using QPainter in KGoldrunner if I have to.

Of course, I'm not going to remove the classes from the library (I don't even 
know if we can while staying BC?). Marking it as deprecated is in no way 
saying that you should have to port your game away from it, merely as a note 
to new developers that the class is no longer necessary since there's a 
better (and maintained, constantly improving etc.) class in Qt.

In the case of KGr, I see absolutely to problem with leaving it with 
KGameCanvas. We're not going to force you to do any porting :)

> So my recommendation to Matthew Woehlke is to try QGV and if that
> fails, just use QPainter.  The problem with that is you have to queue
> and keep track of your own paint requests, so that the required pixmaps
> are re-drawn and moved when the paint event comes around.  That
> is what KGameCanvas does so well, but if it is deprecated you should
> not use it ...
>
> I would not recommend using OpenGL in 2-D mode, based on Kubrick
> experience.  Contrary to what somebody said, I think the OpenGL
> library is available with most distros and in Windows, but in Linux
> the hardware acceleration is not so widely available.  Nevertheless,
> OpenGL seems to run rings around Qt, even in software emulation
> mode.  In Kubrick, 3 cubes 6x6x6, with 152 cubies each (it does not
> draw the interior ones) and each cubie with 26 facets, can be drawn
> for every 20 msec frame (that's about 600,000 facets per second).
>
> OpenGL should be quite fast enough for any of our 2-D games.
>
> So why not use OpenGL in 2-D mode?  Well, in Matthew's case, it
> would be a bit like using a steamroller to crack a nut or cannons to shoot
> sparrows, as our German friends say.  OpenGL requires a whole different
> style of graphics programming, well-suited to 3-D work and complex
> sequences of scaling, translations and rotations, but not as good for
> handling pixmaps and text (though it can be done).  So I think it is
> just the wrong tool for the job Matthew has in mind.  It takes a while
> to learn the OpenGL style and I doubt it would be worth the effort
> in Matthew's case.
>
> This has been a long email.  Hope I have not bored you all, Ian W.


No at all! It's good to hear from you :)

Regards,
Matt Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20080419/a2cdc6d3/attachment.pgp