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 15:50:59 -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 3:00 AM
Subject: Re: [Freeciv-Dev] (PR#9135) Roadstyle 2


>
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=9135 >
>
> John Bauman wrote:
> > <URL: http://rt.freeciv.org/Ticket/Display.html?id=9135 >
> >
> > This implements roadstyle 2, i.e. a method similar to that used in Civ
3,
> > where there is a graphic for every combination of exiting roads for a
tile,
> > and another for every combination of exiting rails.  This does require
512
> > new graphics (2 * 2**8), but it does look better than before, with all
the
> > extra possibilities.  Attached are a patch and two spec files that can
be
> > used with (scaled-down) road and rail graphics from Civ 3.  This would
be a
> > good use for that "fractal tile generator" mentioned not long ago.
>
> Very nice.
>
> A few things I'd like fixed though.  Perhaps they can be fixed later...
>
> - road.isolated and rail.isolated shouldn't be needed by roadstyle 2.
> Instead we should use tileno == 0, I think.  This may require slightly
> more complicated code (because we have to special-case to NOT use the
> special-case) but makes the tilespec file simpler.  Since I'd like to
> have the tilespec be auto-generated this will be easier.
Sure, I'll change that.
I pretty much autogenerated the spec files; the only hand-editing I did was,
indeed,
to change those to "isolated"
>
> - 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.
>
> - 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.
How do the other roadstyles work with hexagonal topologies now (in the
patch for those toplogies, at least)?
>
> - 256 should be some sort of #define.
Sure.
>
> jason
>
>
>




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