[Freeciv-Dev] Re: client goto & patrol v2
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Sun, 24 Sep 2000 02:33:07 Gaute B Strokkenes wrote:
> Gaute B Strokkenes <gs234@xxxxxxxxx> writes:
>
> > Thue <thue@xxxxxxx> writes:
> >
> > What limitations? Or, put another way, how severe are these
> > limitations?
> >
> > > Should I just ignore that problem and consider the network ideal?
> >
> > I suppose it's unlikely to become a practical problem right now, but
> > you'll have to deal with it sooner or later, if this multiple
> > connection thingie catches on...
> >
> > > Is it ideal in this respect?
> >
> > Frog knows. Maybe you could tag the packets with connection number.
> >
> > > Any ideas as to how to get around the problem?
> >
> > Well, any (that is, most ;-) tiles have got exactly eight neighbours.
> > Thus, assuming that all goto routes are from adjacent tile to adjacent
> > tile, you could pack each step into only 3 bits, which is a lot
> > shorter than two shorts (32 bits?)
>
> Looking at the latest version of your patch that I could find in the
> archieves, this is actually sent as an array of struct map_position,
> which means that you're sending 8 bytes per step. Yikes. I'd suggest
> something like:
> [...]
Actually it was reduced to 2 bytes per step down in the network layer.
I can get below the max packet size (4000 bytes) for any normal lenght goto, so
I think I will do that and hold back on the optimizations for a first patch.
-Thue
|
|