Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2000:
[Freeciv-Dev] Re: Some questions
Home

[Freeciv-Dev] Re: Some questions

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Some questions
From: Daniel Burrows <Daniel_Burrows@xxxxxxxxx>
Date: Mon, 3 Jan 2000 16:34:27 -0500

On Mon, Jan 03, 2000 at 02:52:33PM -0500, Jeff Mallatt was heard to say:
> At 2000/01/02 19:28 , Daniel Zinsli wrote:
> >One thing i would like to see is unit movement "animations" ala
> >civ2. That is, instead of a unit "warping" from one cell to another,
> >some middle frames are drawn, showing the unit moving. 
> >I find it a bit confusing when alot of the enemy civ's units are warping
> >at the same time. Is this already implemented, partly implemented, on the
> >wishlist, or does someone have some pointers on how to implement it? :-)
> 
> There already is something of "smooth unit moves" implemented.  Look in 
> Game/Local Options for "Smooth unit moves", and make sure it's "Yes".
> 
> This is implemented, for at least some kinds of moves (simple moves and gotos 
> are smoothed -- I don't know about other player unit moves), by 
> move_unit_map_canvas() in client/gui-{xaw|gtk}/mapview.c.
> 
> However, this routine has a problem in that it isn't throttled.  It just 
> blasts all the intermediate positions out as fast as it can.  You can see the 
> intermediate positions if you add a small delay (I just stuck in a printf()).
> 
> However, adding a blocking delay to this would be very bad, as it would 
> interfere with other client operations.  A throttled, asynchronous queue of 
> some kind might work well, but that could get difficult.  I don't know off 
> hand.  Any other ideas?

  I think that you could do this fairly well -- in the GTK+ client at least --
using gtk+ timeouts.  Maybe, that is..what's the resolution of gtk_timeout_add?

  The real question is if these should be able to overlap -- although the
timeout routine's "data" parameter could be used nicely to handle that.  I
would prefer this; you'd just have to be sure that a piece isn't moved again
while it's moving, or at least that the Right Thing is done if it is (ie,
cancelling any timeouts..otherwise people could get a speed edge by switching
smooth unit movement off)

  Daniel

-- 
Put no trust in cryptic comments.

[Prev in Thread] Current Thread [Next in Thread]