This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]