[Kde-games-devel] KGoldrunner

[Luciano Montanaro]

Il Tuesday 07 August 2007 02:14:41 Mauricio Piacentini ha scritto:
> Ian Wadham wrote:
> > Hey Luciano!
> >
> > Welcome back!  Did you have a good trip?
> >
> > On Mon, 6 Aug 2007 05:55 pm, Luciano Montanaro wrote:
> >> How slow is it? If you start kgoldrunner from the command line, it
> >> writes one line each time one frame of the animation is drawn. How many
> >> frames does it draw?
> >
> > I didn't want to tell you this before you went away but the level-change
> > animation (fade out - fade in) is very slow for me.  That's because I
> > have a graphics card but it is not enabled in Linux.  However that has
> > not been any disadvantage up till now (my CPU is a 2.4 GHz Pentium 4).
> >
> > I am getting just 2 or 3 frames on the fade out and about the same on the
> > fade in.  I have put a timer into the messages and the frames are taking
> > about 0.5 sec to paint, after control goes back to the event loop.  It's
> > sad really ... that particular animation used to be really smooth on the
> > Apple II.
> >
> > I've figured out (finally) how to draw a black rectangle with a
> > transparent circular hole in it, but it seems to take nearly as long to
> > draw that, save it as a pixmap and get KGameCanvas to paint it on top of
> > the play area. Due to other work and lack of time, I have not
> > investigated further.
> >
> > BTW, I think 10 msec timeline interval is too short and would not work in
> > Windows with any hardware.  There's a warning in Qt doco about that.
>
> I like the animation, it fits well with the theme of the game! It runs
> decently on my machine, and I think some of the slowdown can be
> attributed to the debug information being displayed in the console while
> the animation is playing. 

I don't think that is too significant, especially for the system where the 
animation is slow. However, the debug output is there just now to help me 
tweak the animation performance; I'll remove (or comment it out) before 
release. Or not; after all release builds should optimize away debug 
statements.

> It displays 70 frames in my system. 
> But maybe you could try keeping the total time of the animation as it is
> now, but use less frames (maybe 1/3 or 1/4 of what is currently being
> used.) This should make it friendlier for slower systems. I would
> experiment with a 40ms interval at minimum (25 fps), but possibly even
> half of it (12 fps, a 80ms interval). It is good enough specially in
> case of animations like this, where the outcome is predictable and our
> brains can do the interpolation :)
>

That is an option; but is it needed? I mean, QTimeLine only emits its signals 
when it has the time, that is, when the drawing is over. So with a 20ms 
seconds interval it would simply skip frames when the system can't keep up.

But also 12 frames per second would be OK, I think.

Luciano