[Kde-games-devel] KGoldrunner

[Ian Wadham]

On Tue, 7 Aug 2007 06:25 pm, Luciano Montanaro wrote:
> The Grossglockner and surroundings are really beautiful, and
> I finally managed to climb the Stelvio Pass. 
>
Stelvio, huh?  Second highest in the Alps, 60 hairpin bends and the
place where Stirling Moss (old-time UK racing driver) came to grief.
Nice ride, Luciano!

> But maybe I have configuration issues, because it has problems also with
> other games: kshisenso, for example is practically unusable: The first tile
> is highlighted immediately, but after selecting the second tile of the
> pair, I have to wait for a few seconds (at least three, maybe more) before
> I see the conecting line and the tiles are removed.
>
Hmmm.  KShisen is slow for me too, but I think it is since Jeremy put in
the new move types.  I hadn't said anything till now, but is some tweaking
needed, there, Jeremy?

> Kgoldrunner is OK, apart from the fadein/fadeout animation.
>
Much blood, sweat and tears have been shed over KGr performance
in KDE4.  Ask Mauricio. :-)

I think I have a new line on the timing of the fadein/fadeout animation.
Oddly enough, it goes much faster for me if I use one of the KDE 3
themes.  I get 15-20 frames for a fade-out/fade-in sequence and quite
nice animation, but only 5-6 frames in the SVG themes.  This is all
without any graphics acceleration.

If I re-order the code in KGrGame::loadLevel so that SVG background
load is done before calling KGrCanvas::fadeIn, I get much more even
performance.  The sequence of values from the timeline is much more
consistent and the three frames each for fade-out and fade-in look like
click-click-click on a camera aperture.  Slow, but visually convincing.

BTW, I've found that drawing a rectangle with a circular hole in it is
actually slower than the gradient method, once the conflict between
gradient rendering and SVG background rendering has gone.  And it
does not look as good as the gradient method.  So I am ditching the
rectangle-with-hole approach.

I'll continue to play with these ideas, but things are definitely improving.

All the best, Ian W.

P.S.
> The good thing about QTimeLine is that it skips automatically frames,
> though. So we can have very smooth animations with fast systems, and
> whatever the system can manage otherwise.
>
This also happens with QTimer events.  Neat, isn't it?