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

[Parker Coates]

On Thu, Jul 9, 2009 at 7:21 AM, Ian Wadham wrote:
> 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?

Yes, Fela is still the maintainer, but it seems his availability is
quite low lately. Only one group of three commits in the last 6
months.

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

I'm surprised anyone plays with the keyboard as the paddle speed is so
low. It's almost impossible to quickly sneak off to grab a gift when
things get hairy. I guess maybe it makes sense for those with motor
control issues or for those playing on a cell phone.

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

I definitely agree (and am always glad that Killbots isn't a realtime
game when issues like this come up). Maybe it would be ideal to
rewrite all of KBr to use a single instance of your new timer, but
that would likely be a pretty significant change that would certainly
require input from Fela.

I suggested trying it out on the keyboard paddle controls only because
I fixed a bug in that code a few weeks back and notices that the
performance wasn't very stellar. The logic in question is confined to
a few methods in a single class, so it seems like a good candidate to
write up a quick patch and post it to ReviewBoard. Of course, I'm sure
your busy with KGr right now, and I currently don't have time to look
into it. I just had the thought and I wanted to make it public before
I forgot all about it.