Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: PATCH: check_map_pos
Home

[Freeciv-Dev] Re: PATCH: check_map_pos

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: PATCH: check_map_pos
From: Jason Dorje Short <vze2zq63@xxxxxxxxxxx>
Date: Sun, 21 Oct 2001 22:27:27 -0400
Reply-to: jdorje@xxxxxxxxxxxx

Gaute B Strokkenes wrote:
> 
> On Mon, 15 Oct 2001, vze2zq63@xxxxxxxxxxx wrote:
> >
> > Unfortunately the client isn't ready for this change.  It will fail
> > the assertion after a little while.
> 
> We could make the abort conditional on is_server if need be, as a
> temporary measure.

Sure.  I don't know that it's necessary, though - we're not far off in
fixing the client.

> > Fine.  Only two things: the macro can not be used inside map_inx,
> 
> Why not?

The macro aims at doing arbitrarily complex things like logging the
descrepancy.  AFAIK, this is not possible within an l-value macro.  If
it is, that would be great:

void check_map_pox(int *x, int *y)
{
  if (is_normal_map_pos(*x, *y))
    return;
  freelog(...);
  if (normalize_map_pos(*x, *y))
    return;
  freelog(...);
  abort(); /* or nearest_real_pos() */
}

> > and map_inx is where the problems are most likely to occur.  Also,
> > I'd prefer to keep the name check_map_pos (instead of
> > check_map_pos); the macro can ensure that passed parameters are not
> > evaluated more than once.
> 
> You're not coming across here.  check_map_pos instead of
> check_map_pos?

Oops.

I meant I would prefer check_map_pos to CHECK_MAP_POS.  We can make sure
arguments are evalutated exactly once, if need be.

> > In the meantime I can try to track down the client problems,
> > although they may be GUI-specific.
> 
> Please do.  You seem to be on a quest to add arbitrarily complex maps
> to Freeciv;

Yes :-).

> this is your chance to put your money where your mouth is
> and show that someone is actually willing to go through the GUI code
> and make it possible to show them on the map, a problem which is more
> complicated than dealing with them internally.

Well, we're not quite there yet, but the client problems with
check_map_pos are being resolved.  The tilespec cleanup
(tile_fill_sprite_array()) was one of them (actually there was just one
problem, but I ended up cleaning up both functions).  I'll re-evaluate
things here and see what still needs to be done.

jason


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