Mail Archives: djgpp/2000/05/11/07:45:18
Paul Cechner <paul AT ibc DOT com DOT au DOT nospam> wrote:
> Im not sure if this is off topic, because i dont really know if its c++
> specific or not... so please, minimal flaming .. :P
It's neither specific to C++, nor to DJGPP, so it's twice offtopic, here.
Anyway, just to give you a start:
> The problem comes when i consider a controling mechanism... is the best
> solution to have these things all in a large collection and call their
> animate methods
That's the simplest of all imaginable methods, but not necessarily the
right one for your task. It's main drawback is that it assumes all
objects to move equally fast, thus consuming CPU time increasing
strictly linearly with the number of objects to be animated.
A better method may well be to have every animated object inform the
central 'world animator' about its current speed of movement, given by
the time it should next be updated again, to avoid jerky movement by
more than one pixel, or a similar criterion. The central animator can
then keep a queue of animated objects sorted by next update time (a
'heap' or 'priority queue' is the technical term).
This method is more flexible, accounting slowly and rapidly movind objects,
equally. It also offers you a way to detect probable collisions or
animation bottlenecks early on, so you can possibly move some of the updates
a bit ahead in time, to reduce the impact.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -