Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2003:
[Freeciv-Dev] Re: (PR#6815) Balancing Battle Response Time for Different
Home

[Freeciv-Dev] Re: (PR#6815) Balancing Battle Response Time for Different

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rt-guest@xxxxxxxxxxx
Cc: tomcatkev0@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#6815) Balancing Battle Response Time for Different Client CPU/Network connection
From: "Christian Knoke" <chrisk@xxxxxxxxx>
Date: Tue, 11 Nov 2003 08:36:17 -0800
Reply-to: rt@xxxxxxxxxxx

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

On Tue, Nov 11, 2003 at 07:54:00AM -0800, Thomas Strub wrote:
> 
> For a fast game you need:
> 
> Low ping (round trip time)
> High bandwith (big information chunks during reconnect or after end of
> turn)

I'm a bit in doubt about this one. At turn done, civserver may be
responsible as well.  Do you have numbers (KB)?

> Fast computer (to draw unitmovement, update CMA ...)

Actually my computer (ebay ~ 50 EUR) is fast enough with GTK 1.2 - with the
exception of the special cases I listed recently on this list.

> (A fast player ...)

A fair chance ...

> (A non gtk2-client ... horrible slow unitmovement in the cvs version)

Never tried - that's bad.

> So people will allways complain about there situation when they have a
> system where one point isn't fulfilled.

Connection is a hard point - most people don't have a choice.

> But i like the current situation where i have a game where i have no lag
> when i want to move a unit on civserver.

Some things like fast focus patch have improved that. And I agree fully that
more efforts should be taken in that direction. I wonder why we don't put
the information retrival local. With modem, it can even hurt to open
demography report and such. We could mirror these things locally.

Christian

-- 
Christian Knoke            * * *            http://cknoke.de
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.




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