Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2004:
[Freeciv-Dev] Re: (PR#9135) Roadstyle 2
Home

[Freeciv-Dev] Re: (PR#9135) Roadstyle 2

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#9135) Roadstyle 2
From: "John Bauman" <john@xxxxxxxxxxxxxxxx>
Date: Mon, 28 Jun 2004 16:34:43 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=9135 >


----- Original Message ----- 
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
To: <john@xxxxxxxxxxxxxxxx>
Sent: Monday, June 28, 2004 7:04 PM
Subject: Re: [Freeciv-Dev] (PR#9135) Roadstyle 2


>
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=9135 >
>
> John Bauman wrote:
>
> >>- I really don't like the separation of diagonal and cardinal roads in
> >>the tileno.  Rather than "r.road_n0s1e0w1_n1s1e0w0" I'd rather have
> >>"r.road_01001110" or "r.road_n0ne1e0se0s1sw1w1nw0".  Note the use of a
> >>rotational ordering, which I suspect will be very helpful later on.
> >
> > Do you have a good idea for a name? I think I'll go with the second
choice
> > you
> > gave.  Rotational ordering would make much sense than what we have now.
>
> Yes, rotational ordering is nice for tilesets.  Problem is the direction
> enumeration doesn't guarantee it.
>
> What do you mean by a "good idea for a name"?
I get the feeling that INDEX_NNEESESSWWNW might be a bit too long for
a macro, which we would want to make in case we want to use this scheme
later.
INDEX_CLOCKWISE ?
>
>
> Side note...
>
> I think the tileset code needs to use directional indices rather than
> directions directly.  That way we can guarantee that the indices are
> rotational and that the cardinal indices correspond to the cardinal
> directions in the tileset rather than the cardinal directions in the map.
>
>    bool is_valid_tileset_dir(enum direction8 dir)
>    {
>      if (is_hex) {
>        if (hex_width > 0) {
>          return (dir != DIR8_NORTHEAST && dir != DIR8_SOUTHWEST);
>        } else {
>          return (dir != DIR8_SOUTHEAST && dir != DIR8_NORTHWEST);
>        }
>      } else {
>        return TRUE;
>      }
>    }
>
>    bool is_cardinal_tileset_dir(enum direction8 dir)
>    {
>      if (is_hex) {
>        return is_valid_tileset_dir(enum direction8 dir);
>      } else {
>        return DIR_IS_CARDINAL(dir);
>      }
>    }
>
>    num_valid_tileset_dirs = 0;
>    num_cardinal_tileset_dirs = 0;
>    dir = DIR8_NORTH;
>    do {
>      if (is_valid_tileset_dir(dir)) {
>        valid_tileset_dirs[num_valid_tileset_dirs]++ = dir;
>      }
>      if (is_cardinal_tileset_dir(dir)) {
>        cardinal_tileset_dirs[num_cardinal_tileset_dirs++] = dir;
>      }
>      dir = DIR_CW(dir);
>    } while (dir != DIR8_NORTH);
>
> >>- Think about hexagonal tilesets.  Here we only have six directions.
> >>How will this be coded?  (Note that all the other directional tileset
> >>code doesn't really support hex tilesets either.  The hex author figured
> >>out ways around it in the tileset.)  (As a side note, the NSEW should be
> >>changed to be rotational as well.)
> >
> > I imagine that the tileset author could just ignore the directions that
> > don't exist.
>
> Yes but this is ugly since it requires 4x more tileset tags than are
> needed.  (As a side note, making a "good" hex tileset should be much
> easier than making a "good" rectangular tileset.)
>
> > How do the other roadstyles work with hexagonal topologies now (in the
> > patch for those toplogies, at least)?
>
> I assume he just ignores the extra directions.  For roads this is easy,
> but for cell-based terrains or river graphics (which are based on
> cardinal directions) it doesn't work well.
>
> jason
>
>
>




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