[Freeciv-Dev] Re: (PR#7860) smoother unit "animation"

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7860 >

James Canete wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7860 >
> 
> I don't really like busy-waiting animation as a whole.
> 
> How hard would it be to set up a list of active animations, and animate
> them for a single frame during the main loop of the client?  
> 
> Something like this:
> 
> static time lasttime;
> if (currenttime-lasttime > 20ms)
>    lasttime=currenttime
>    foreach(animation in list)
>      update&draw(animation)
>      if done(animation)
>         remove(list, animation)
> 
> This would also facilitate tile animations and simultaneous animations.
>  Also, we could add a "bail out" inside the for loop, in case the
> animations are taking too long.

This is possible.  However when you bring GUI updates into it even 
computers with reasonable speed may end up lagging behind.  So here it 
becomes even more important to do the animation in real-time rather than 
discrete 20ms increments.

Consider what happens in the above algorithm if the GUI update takes 
30ms, for instance.

> This does raise a few hard questions though.  Do we lock the controls
> when a unit movement animation is occurring, to prevent strange
> paradoxes from happening?  And wouldn't this force a refresh of the
> mapview every 20 ms?

Some controls should be locked.  Most likely this can be handled by a 
slight change to can_client_issue_orders().

The bigger problems are in the network code.  If we return control to 
the GUI it will check the network socket and is likely to call the 
network handler again.  This is problematic if, say, the new packet 
causes us to start another animation that involves recentering the 
mapview when we haven't finished the current animation yet.  And we 
can't easily ignore this new packet because then data may sit on the 
network and the GUI will thrash while repeatedly calling the network 
handler function.

These problems are solvable but not easy.  I've tried to do this exact 
same thing in another project, and it is very tricky.

jason