[Freeciv-Dev] Re: (PR#7696) Re: Re: (PR#7637) Problem with line_width=2 [take 4]

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

Raimar Falke wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7696 >
> 
> On Wed, Mar 10, 2004 at 11:37:45AM -0800, Jason Short wrote:
> 
>>>It is well define for line_width=1.
>>
>>Right, but if you want to make 2 such calls you have to specify how 
>>they're placed relative to each other.  This "defines" the size-2 line.
>>
>>When drawing a sized-2 line around a tile, we draw 4 lines:
>>
>>   (x0,y0) -> (x0, y0+H-1)
>>   (x0,y0) -> (x0+W-1, y0)
>>   (x0,y0+H-1) -> (x0+W-1, y0+H-1)
>>   (x0+W-1,y0) -> (x0+W-1, y0+H-1)
>>
>>but these lines should all be inset.  So instead of subtracting off 1 we 
>>should subtract off 2 in most cases.  This is a situation where drawing 
>>individual lines may give some advantage, because the inset does not 
>>match exactly with the 2-line definition: think of it as two rectangles, 
>>one inside the other, rather than as 4 double-width lines.  This is more 
>>likely to make a difference in iso-view, where if you draw a 
>>double-width line you may end up going 1 pixel over into the adjacent tile.
> 
> 
>>But I'm not even sure the two-line method would work in iso-view.  Say 
>>you draw two lines, from
>>
>>   (x0,     y0 + H / 2) -> (x0 + W / 2, y0)
>>   (x0 + 1, y0 + H / 2) -> (x0 + W / 2, y0 + 1)
>>
>>can you guarantee that these lines will give the results you want?  Is 
>>it possible there will be a hole between the two lines?  How could we 
>>convince ourselves otherwise?
> 
> I face the same problem when I code gui-fs: where to draw the second
> pixel. Since I don't see a nice solution I want that this decision is
> moved up: in the common client code.
> 
> So somewhere we have to place the complexity of the decisions. Or we
> remove it altogether by only allowing lines of odd width.

IMO this work should be done by the GUI code.  The GUI already has to 
define how the single-width line is drawn (which pixels are drawn). 
This is fairly obvious but not entirely trivial, I suspect.  And 
generalizing this algorithm will probably give the X11 definition.

So I think we should just go with the X11 definition.  It is 
mathematically simple and should be easy to conform to.

Of course canvas_put_line as it is now doesn't allow you to specify the 
width.  You have to specify the line type which translates into which GC 
to use.  A different interface could just specify the width and let the 
function set up the GC as needed.  This would be trivially slower but 
ultimately more flexible.

>>I think the solution civ3 used was to provide sprites for the lines. 
>>This allowed the lines to curve over hills and mountains (it took a 
>>number of sprites, of course).
> 
> Or with this solution.

This may be useful at some point.  The problem is we have many more 
types of lines (grid, border, frame, goto).  Civ3 only had border and 
goto lines IIRC (I can't recall if goto lines had their own sprites). 
We also have a more complex set of tileset rules that may make this 
complicated.

The advantage of using a sprite is you can easily round the edges.  For 
instance a right turn goto line needn't be a sharp angle.

jason