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

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] QCanvasSprite + QObject
From:       thomas.friedrichsmeier () ruhr-uni-bochum ! de
Date:       2001-12-20 12:28:11
[Download RAW message or body]

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

Thomas
_______________________________________________
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]