[Kde-games-devel] best class to use for game graphics (was: Deprecating KGameCanvas)

[Matthew Woehlke]

Ian Wadham wrote:
> 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.
> [snip]
> 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.

That's the conversation I remember. I admit I'm currently just 
spectating w.r.t. this subject, but I'd ask the same question; why 
deprecate something that does a particular job better, especially if it 
isn't a time sink? QGV still seems to me more GUI-orientated than what 
many games (mostly console-like games, e.g. Kapman, KGr, KBreakout... 
i.e. games where the interaction is more akin to using a gamepad than 
point-and-click) need.

That said, I'm going to spend the rest of this message arguing for 
OpenGL, so...

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

Well... about half those arguments fall flat on their face :-). At least 
the last one, about learning OpenGL, because I already know OpenGL (in 
fact, I've previously written OpenGL games on Windows).

About using Qt vs. not, I guess I could say that it used to be that no 
one in their right mind would use WinGDI to do a game with any real sort 
of animation; you'd use DirectDraw. A few years back, no one would have 
considered that overkill. Personally I found DirectX to be more 
complicated than OpenGL, which is why I learned the latter (this was 
before I knew to care about portability; now of course portability is 
another *huge* reason to not use DirectX).

QPainter doesn't sound like an ideal solution, and now it's sounding 
like QGV isn't so great either (nevermind that I'm somewhat trying to 
avoid all those data/view classes), which leaves KGC (if it fills a 
niche better, why deprecate it?) or OpenGL. Given that I know the 
latter, and that now Ian is saying that even software GL is likely to 
perform well, I'm inclined to stick with what I know, and the known 
advantages it provides. (And I think I recall that text with Qt+OpenGL 
is actually not hard at all.)

And, if Qt/OpenGL outperforms QGV/KGC/QPainter, then I would argue that 
makes it very much the /right/ tool for the job ;-). I'm not sure where 
the myth that OpenGL is only for 3D comes from, but I certainly don't 
subscribe to it. OpenGL is for *fast* graphics; it makes 3D very easy, 
certainly, but that doesn't mean it's somehow "bad" for 2D. (I've even 
seen GUI's in OpenGL, though I'll draw the line there that you shouldn't 
use it for generic GUI's without reason.)

And I must admit I like that typically /there is no scene management/ in 
OpenGL; you just draw everything :-). (The small number of textured 
triangles required for most 2D games, even with full-scene repaints 
every frame, is hardly even worth modern hardware acceleration.)

Yes, trying to run an OpenGL game remotely is going to be painful if not 
outright impossible, but I suspect that's going to be true of games in 
general. Playing *any* console-like game remotely is going to be out of 
the question except on very fast pipes, because any update lag will make 
such games unplayable.

-- 
Matthew
"What, more work?" -- Peasants (Warcraft II)