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

[Ian Wadham]

On Wed, 17 Jun 2009 1:46:18 pm Aaron J. Seigo wrote:
> On Tuesday 16 June 2009, Alan Alpert wrote:
> > Speaking of recent features, you should consider QTimeline** (new in 4.2)
> > if you haven't already. It was designed for animations and so hopefully
> > avoids jerkiness.
>
> when it's ready, the Qt declarative UI stuff. QTimeLine and all the 
animation stuff are completely obsoleted by the new code.
>
Excuse me for re-ordering your sentence, but I rather like the sound of
this.  Reminds me of what used to be called data-driven code, which
is actually quite hard to do in C++ (I think ... can't initialize data in the
class header and it's quite difficult to initialize blocks of data, such as
rows in a lookup table).  Of course, a ui.rc file goes some of the way
towards data-driving a GUI.

However, performance (so far) is unimpressive.  DigiKam runs rings
around it for viewing photos ... and no disembodied finger ... :-)

> what people should really be looking at is the Qt Animation stuff, Kinetic,
> the state machine API (and eventually,
>
Kleag suggested this ... first reply in this thread ... so I googled on "Qt
library animation" and got:
http://labs.trolltech.com/blogs/2009/04/23/qt-animation-framework-23-is-out/a 
http://www.qtsoftware.com/products/appdev/add-on-products/catalog/4/Utilities/qtanimationframework

Frankly, it all seemed rather obscure and the example given (moving a 
button smoothly from A to B) was rather trivial and purposeless, to my
way of thinking.  And what has all that state-machine stuff got to do with
animation?  I just want a little man to run from A to B and not stumble,
but if you pile layer on layer of classes he will surely stumble.

Yours truly cut his teeth on real-time programming (in Assembly language)
circa 1968 and my boss John taught me then that the ultimate enemy of 
real-time performance is calling-sequence overhead, and of course,
in object-oriented programming it is an ever-present phenomenon.

Here's a challenge, then ... would someone like to recode KGoldrunner
as a benchmark for the new animation and state-machine classes? The
percentage of code devoted to animation in KGr is now quite small and
did not take long to write.

> that said, it _still_ probably won't be perfect for what Ian needs in
> KGoldRunner because, while it does use a shared timer system, it still has
> the "skip over frames" and no debug controls. this, really, is the key bits
> in Ian's class afaict.
>
The key feature is that it uses QTime (without an "r") to monitor timer
events in real time and compensate for late QTimer pulses by inserting
extra signals.  That keeps the game *model* spot on-time at a time scale
faster than the player's reflexes.  Skipping animation frames is optional
and is just a way to relieve pressure on the graphics library, on the
hypothesis that it is the most likely thing to be causing temporary
lateness of QTimer.

> hm... i'm going to bring those two features up with the developers of
> Kinetic and see if they think it might make for useful additions.
>
I would be honored to have contributed a small idea ... :-)

All the best, Ian W.