[Freeciv-Dev] Re: (PR#8507) generalized tile boundaries

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

Vasco Alexandre Da Silva Costa wrote:
> On Wed, 14 Apr 2004, Jason Short wrote:
> 
> 
>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8507 >
>>
>>>Hmmm, why not simply returns a list of the vertexes of the bounding
>>>convex polygon on a tile, for all directions?
>>
>>This would work as an internal implementation for the function, and in
>>time I think that's what should be done.  (I hard-coded the different
>>directions for two reasons: that's the way they're done now, so it seemed
>>easier to transpose the logic this way; and the directional ordering
>>[including DIR_CW and DIR_CCW] is sufficiently ugly that the array of
>>corners wouldn't be very elegant.)
>>
>>However to have the function return this list directly means a fair amount
>>of extra work the caller has to do.  Consider:
>>
>>- The caller has to check whether the X and Y points are equal to see if
>>the side exists.
> 
> 
> Is this necessary to just draw some lines?

Sometimes.  For instance with an iso tileset you draw 4 lines while with 
a hex tileset you draw 6 lines.  So a boolean check is needed at some point.

>>- When width comes into play the ending point for one boundary isn't the
>>same as the starting point for the next.  Consider, in iso-view, the W and
>>S national border lines (edges) drawn to the SW corner (vertex) at (x,y).
>>The W line must be drawn smack up against the W boundary, but since the
>>width of the line is 2 (lines extend upward from their origin) it is drawn
>>from (x,y+1).  Meanwhile the S line is drawn to within 1 pixel of the S
>>boundary, and since we don't have to account for width in this case it is
>>drawn to (x, y-1).  This makes little sense unless you examine it closely,
>>which is one reason why it should be concealed behind the function
>>interface.  Another is just that it would be fairly difficult for the
>>caller to make this adjustment; it's easier to do it at the time the
>>boundary vertices are generated.
> 
> I dislike such low level code.

No kidding.  But I haven't seen any alternative so far.

> Why not always use the same vertex coordinates,
> but pass different line thickness arguments to the graphics API instead
> of doing several parallel lines by hand? Any decent half graphics API has
> this functionality, X11, GDI, OpenGL, etc. Some even allow to pass
> floating point line widths and anti-aliase them appropriately. Anything to
> make the code simpler. :-)
> 
> With GDK you can use:
> http://developer.gnome.org/doc/API/2.0/gdk/gdk-Graphics-Contexts.html#gdk-gc-set-line-attributes
> 
> void        gdk_gc_set_line_attributes      (GdkGC *gc,
>                                              gint line_width,
>                                              GdkLineStyle line_style,
>                                              GdkCapStyle cap_style,
>                                              GdkJoinStyle join_style);
> 
> OpenGL can draw these types of lines for e.g.:
> http://www.dcc.unicamp.br/~lmarcos/courses/mc603/redbook/images/Image36.gif
> 
> X11 can draw them as well. Setting line attributes and stipple pattern.

We do pass different line thickness arguments to the graphics API; we 
don't draw parallel lines at all [1].  See thin_line_gc versus 
thick_line_gc.  The problem is that we want the line to nestle up right 
against the boundary of the tile, and a 2-pixel line is uneven: 
basically like 2 lines being drawn, one on the right and one on the 
left.  The API call gives the position of the right line, from which the 
left line is extrapolated.  But the position we give to the API has to 
take this into account.

[1] Well this isn't strictly true.  The red frame tile is drawn as a 
single-width with an inset rather than as a double-width line.  This 
should probably be changed, but I'm not sure what it should be changed 
_to_.  But national borders are the hard case, and they're drawn using a 
width-2 line.

jason