[Freeciv-Dev] Re: the directional system

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

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.

> - one big system and one small system: move all the DIR_DX2 stuff
> into fill_tile_sprite_array_iso() or at least into tilespec.c
> - 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.
>
>       Raimar
>
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
> "Last year, out in California, at a PC users group, there was a demo of
>  smart speech recognition software. Before the demonstrator could begin
>  his demo, a voice called out from the audience: "Format c, return. Yes,
>  return." Damned short demo, it was.