[Kde-games-devel] A timer class for games

[Ian Wadham]

On Wed, 8 Jul 2009 10:11:21 pm Parker Coates wrote:
> On Fri, Jun 12, 2009 at 3:15 AM, Ian Wadham wrote:
> > During the re-write of KGoldrunner I have developed a timer
> > class that gives greater reliability to animation-timing and a
> > smoother overall animation effect.  I am wondering if it is worth
> > generalizing it into a KDE Games Library class for KDE 4.4,
> > i.e. whether other games could find it useful.
> > 
> You might want to take a look at whether your new timer makes sense
> for KBreakout, particularly the keyboard controls. The current
> keyboard control system is pretty primitive, and as a result it's not
> very smooth at all. Seems like this might be an ideal opportunity for
> your new class. The code in question is also quite simple so you
> should be able to tell whether it's a good fit or not without too much
> effort.
>
Does Fela Winkelmolen still maintain KBreakout?

I had a look at the relevant code, mainly in "canvaswidget.cpp".
It is driven by keyPressEvents or a timer slot that reads the mouse
position.  Either way, a direction for the bar to move is established
and the bar's pixmap is moved in timed steps by the game engine.

KGoldrunner is somewhat similar, except that KActions handle keystrokes,
there is just one timer now (which drives both the game engine and
the canvas) and the time interval is always 20 msec.  It times something
like 65 msec as a pattern of 60, 60, 80, 60 ... which works (amazingly).

I think the Qt event-queue system may prefer a single timer to several
timers (as in KBreakout or old KGoldrunner).  I also think intervals 8 msec,
16 msec and 13 msec, used by KBreakout, might be stressing Qt to an
unnecessary extent.

Both KBr and KGr see a keystroke and do something about it at the next
timer slot execution, so either could be adversely affected by keystrokes
being delayed in the event queue.  Dunno, I do not play keystroke mode
much, except for (very) basic testing.  I do not have the reflexes ... ;-)

In KGr though, the animation is independent of the game engine, which just
tells the canvas to move an object in a certain way from A to B in a given
time and leaves the canvas to decide the number of steps, the pixels per
step and when to change the animation frame.  In KBr the equivalent
might be for the game engine to set a relative velocity for the bar and
order it when to start and stop.

The big difference in KGr is that the game engine stays on-time over
periods of several seconds, even if individual QTimer signals are late,
early or missed.  Also, if a signal has been missed, the canvas calculates
the pixel-move for it but skips the painting (hoping to relieve the pressure
on Qt).

This approach might well make the KBr bar move more smoothly and
predictably, even if it seemed sometimes to blink a little.

During testing, I saw a dramatic illustration of all this.  Without pausing
KGoldrunner, I switched to the Egyptian theme, which takes a second
or two to be loaded and rendered.  When the picture reappeared, the
sprites had moved exactly to where my mental clock expected them to be.

I think the possibility to anticipate a fast-moving game precisely is vital.

All the best, Ian W.