This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Animation time (was: Re: -O -g)
>On Fri, 2003-11-14 at 12:34, Hans Ronne wrote:
>> I wouldn't call it an optimization struggle as much as a human perception
>> struggle. It is possible to increase the speed of the game10-fold by simply
>> reducing the animation time, but then you can no longer grasp what is going
>> on. See the profiling data I posted last year:
>
>Might it be possible to set up Xconq in such a way that animations can
>run while other things are running? Perhaps when an explosion appears
>on the screen, Xconq would draw it, proceed to other things, but then
>erase it after the animation time has elapsed?
This was also discussed in the same thread last year. See:
http://sources.redhat.com/ml/xconq7/2002/msg00578.html
Cutting down animation times does make the game very confusing (I have
tested). Re-reading my post I see that I had some ideas, like highlighting
the attacking unit, which could make it possible to cut the animation times
with less confusion. And the animation pre-flight code from the Mac
interface could probably be ported to the tcltk interface.
As for the multi-threaded (or delayed erasure) approach, a problem is that
the kernel moves one unit at a time. This is true even if the game is
running in non-sequential mode. So weird things could happen if a unit is
hit several times, perhaps by different attackers, and therefore would have
several animations running on top of each other.
>If a lot of combat occurs in a short amount of time (most likely for
>units under AI control or directed by standing orders), the screen might
>get messy with all of the explosions appearing simultaneously, but so
>would a real battlefield.
Exactly. I think the best (or at least less confusing) way would be to
maintain a linear sequence of events, but make the animations easier to
interpret for the human brain. They could then probably be played faster
than now.
Hans