Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2003:
[Freeciv-Dev] Re: (PR#4067) buffer the screenoutput
Home

[Freeciv-Dev] Re: (PR#4067) buffer the screenoutput

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: ue80@xxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#4067) buffer the screenoutput
From: "Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>
Date: Wed, 23 Apr 2003 15:35:02 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Wed, 23 Apr 2003, Per I. Mathisen wrote:

>
> On Wed, 23 Apr 2003, Jason Short wrote:
> > ue80@xxxxxxxxxxxxxxxxxxxxx wrote:
> > > when watching big AI-games i allways get the problem that i get
> > > reconnected because the screenupdates lags the client. What is with
> > > using a buffer like in fps-games? (And only redrawing that buffer when
> > > we need it or all x ms)
> >
> > The problem is the client "needs" to refresh every time it animates a
> > unit.If you turn the animation off, it should be much faster.
> >
> > Of course, it's not really "animation", but the concept is the same.
>
> No, I don't think that is it. The issue isn't too many screen refreshes,
> but too much work for the client in too little time.
>
> One solution is to make units move faster (local option, set delay lower).
> Another is to buffer the requests when they come in too fast. But I don't
> know how to do that - the client has no idea of how many turns ahead the
> server is. For all it knows, it could just be processing the turn-end
> results of a very, very big human vs human game.

The speed problem has always been there but lately it seems to have got
worse with the map unification. Once that is achieved we should do some
benchmarking and try to remove the bottlenecks.
Only after that should we look better at this sort of thing.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa






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