[Kde-games-devel] Deprecating KGameCanvas

[Ian Wadham]

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-forever/
>
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.

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.

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.