[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] QCanvasSprite + QObject
From:       "Felix E. Klee" <felix.klee () inka ! de>
Date:       2001-12-21 7:56:05
[Download RAW message or body]

thomas.friedrichsmeier@ruhr-uni-bochum.de wrote:
> > How about setting the advance time to the larges common divisor.
> >
> > E.g: sprites move with 150ms tick, animationas are 100ms tick ->
> > base tick 50ms.
> > Animations change every two ticks, sprites move every 3 ticks.
>
> Of course, in principle, this would be a solution. It's just a little more
complicated than
> that:
> - The Canvas-AdvancePeriod is run-time configurable in a range of 1fps
(ridiculous of
> course, but something like 20fps should be within the range) to 100fps.
> - The "Taxi"-class is the only Sprite which is currently set to animated. It
is entirely
> configurable by configuration files, and may have a (theoretically) unlimited
number of
> animations, each with an individual frame-rate (only two can ever be active at
a given
> time).
> - The "Passenger"-class is not set to animated because a) Whenever the
passenger
> moves, it moves to a given destination, so I have to check, whether it got
there,
> anyway b) It may sit on a moving ground, so setting velocities would not be
that easy c)
> Passegengers may differ in "impatience", which means they move faster or
slower,
> which of course affects not only walking-speed, but also speed to the
respective
> animation d) same as for the taxi, for each of the different animations (could
be
> hundreds) you can specify an individual frame-rate in the configuration files,
although
> only one may ever run at a time.
> - Moving objects move on pretty complex paths specified in
configuration-files. It'd truly
> be hard to adjust velocity and acceleration parameters whenever the global
> AdvancePeriod changes, so the actual path/velocity would remain the same -
therefore
> their advancement-rate is fixed. Of course their animation-rates are
configurable.
>
> I'm not going to tire you with more details than that, but I think you see,
that using
> separate timers is the most intuitive approach, if I want to keep this
functionality (which
> I do). Of course it could be rewritten to your approach, but it'd be rather
hard to do - so
> the question is again: How expensive are timers / QObjects? I wouldn't rewrite
the
> code for say 1 percent more performance, but for 50%, I guess I would.

About two month ago I was writing a sprite based game for KDE and hope to
continue working on soon. There, I derived my own canvas class from QCanvas with
a function to adjust the frame rate. Each sprite is read from an XML-file that
contains a description about its animation and the frame rate. Now, when the
canvas is advanced, each sprite reads the FPS-number from the canvas class and
advances its animation accordingly. I believe this is a very fast and elegant
approach. One further advantage (that I haven't implemented yet) is that the
game might adjust the frame rate automatically when the load on the system
changes.

Felix



_______________________________________________
kde-games-devel mailing list
kde-games-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-games-devel
[prev in list] [next in list] [prev in thread] [next in thread]