Complete.Org: Mailing Lists: Archives: freeciv-dev: January 2000:
[Freeciv-Dev] Re: smooth unit moves (was Re: Some questions)
Home

[Freeciv-Dev] Re: smooth unit moves (was Re: Some questions)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: smooth unit moves (was Re: Some questions)
From: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Date: Tue, 04 Jan 2000 09:59:33 -0500

At 2000/01/03 22:05 , David Pfitzner wrote:
>Jeff Mallatt wrote:
>> 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?
>
>The best idea once before when this came up was to have a "slider"
>control in the client, so the user can set the speed.
>
>I don't think "blocking" is a problem.  Even with the current method,
>turning on "smooth unit moves" will make the client "block" slightly
>longer than with it off -- too bad, the client will catch up
>eventually.  If the player loses some small advantage, thats their
>fault for having the moves set so slow :-)   The people who want
>smoother moves probably _want_ the move displays to block, so they 
>can be sure to folllow each move made by AI players etc.

Hum.  I'm not fond of the idea...  But, the best way to tell how much of an 
impact it has is to implement it!  (For testing its impact, we don't even need 
the fancy UI -- just read the parameter value from a file.)

For the parameter, 0 could mean what there is now when smooth_unit_moves is 
off.  Larger numbers indicate the number of "steps" to take.  Thus, 1 is very 
similar to 0, except we could add an XSync() to make sure the unit icon gets 
drawn.  2 means it takes 2 steps to go all the way (first is half-way, second 
is in final position), with fixed delays between the steps.  Etc.

I did some testing with a myusleep() tossed into the loop.  One thing I noticed 
was that on my machine (an Intel box running Linux) calling myusleep() with any 
argument less than about 10000 was the same as calling it with 10000.  (Which 
makes me suspect that the existing few calls to myusleep(100) should be changed 
to myusleep(10000), and everything scaled accordingly.)  And, I noticed that 
while units are moving, nothing in the UI works.  This does not seem good.  Is 
there another implementation you were thinking of?

jjm


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