[Freeciv-Dev] Re: the directional system

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Sep 10, 2001 at 07:43:23PM -0400, Ross W. Wetmore wrote:
> At 12:21 PM 01/09/10 +0200, Raimar Falke wrote:
> >On Sun, Sep 09, 2001 at 07:53:13PM +0200, Thue wrote:
> >> On Sunday 09 September 2001 18:59, Raimar Falke wrote:
> [...]
> >Problem: Freeciv's primary direction system (DIR_DX) is used in most
> >code places. Freeciv is or will be after a few patches independent in
> >this respect of the direction system used.
> 
> So, this isn't a problem anymore ...
> 
> >Non-isometric tilesets are layouted in INDEX_NSEW. The isometric
> >tileset is layouted in DIR_DX2.
> 
> This is a fairly specific problem area, and is not a problem if the
> existing code is left to its specific hardcoded flavour, i.e. not 
> linked to the global direction system. At some level you probably
> want to do this, even if is just the primary load from disk. It is
> entirely reasonable to have glue code that picks up (a given case of)
> arbitrarily formatted data and loads it into system standard memory 
> structures.
> 
> >Solutions:
> > - unify the systems
> >   * to DIR_DX: the isometric tileset (loading) has to be changed
> >     (specfile changing, mapping at some point)
> >   * to DIR_DX2: a some of code has to be checked if it works with
> >     DIR_DX2 (this is a good thing). 
> 
> > However we tie a lot of code to
> >     the DIR_DX2 system and so loose flexibility
> This is both patently false and a red herring issue anyways
> 
> The same DIR_DX references and iterate macros are used for either
> system with relatively compact changes in the header file to switch
> between them.
> 
> If anything, the rotational system adds flexibility over the current
> array order, as well as significant efficieny savings when the header
> implementation takes advanatage of its characteristics.

IMHO we should encapsulate any special properties of the system using
macros/methods like DIR_REVERSE, DIR_CW and DIR_CCW. For the
rotational system these macros/methods may be very simple and may be
more complicated for the current DIR_DX system. This way we ensure
that we have a system independent algorithm.

> > - get rid of this problem: change the way the road and rail graphics
> > are handled. Instead of indexes use symbolic names. Change
> > 11, 1, "r.road0"
> > 11, 2, "r.road1"
> >to
> > 11, 1, "r.road_n"
> > 11, 2, "r.road_ne"
> >and 
> >      struct Sprite *dir[8];
> >to
> >      struct { struct Sprite *n,*nw,*ne,....;} iso;
> >
> >in struct named_sprites.{road,rail}. This may include some extra work
> >but leave us with less problems in the long run.

You haven't commented this the text above.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Any sufficiently advanced technology is indistinguishable from magic."
    -- Arthur C. Clarke