Re: XBoard 4.7.3: Full board textures + maximize window

Let me explain how it is done now:

As the texture bitmap is fixed size, and wood textures in general start 
to look very vague and ugly on sizing, the backgrounds for individual 
squares are cut out of the texture bitmap. The texture bitmap is divided 
into virtual squares according to the board format of the current 
variant (so 9x10 in XQ), and the central part of those virtual squares 
are then used for the cutouts. If the texture bitmap is exactly the 
right size, this would produce a perfect reproduction of the entire 
texture bitmap. If the actual board is smaller than the texture, it 
keeps the cutouts centered on the grid points of the XQ grid.

If the actual board is larger than the texture bitmap, however, there is 
no avoiding that the cutouts start to overlap. Particularly bad, 
however, is that the edge squares immediately start to extend outside 
the texture bitmap, which would lead to a white (or black?) rim around 
the board. To avoid that case (tested by the if() statements you 
mention) the grid of points on which the cutouts are centered is 
homogeneously shrunk to just make the set of overlapping cutouts fit the 
entire texture bitmap. This displaces the actually drawn grid in the 
texture bitmap away from the center of the cutouts, expanding it so that 
the distance between the outer grid lines and the window edge stays what 
it was in the texture. But the pieces are no longer exactly centered on 
the grid points.

This works reasonable (except from some minor artifacts in the diagonal 
lines) until the actual board size gets more than 1.5 times the size of 
the texture bitmaps. By that time the cutouts start to extend so far 
that they overlap the neighboring grid line, the edge squares first 
(because these are most off-center), so that spurious extra lines will 
appear in the grid.

Currently the only solution is to provide a larger bitmap for the 
Xiangqi board.

I am open to suggestions for better solutions. Perhaps we should 
consider sizing the texture by integer factors, which should not degrade 
appearance much. We could for instance double the size as soon as this 
1.5x limit is reached, so that the board will start to look like a 2x 
blown up version of a cut at 0.75 times the size of the texture bitmap. 
This would double the width of the grid lines, but that might actually 
be a good thing at such a large board size. A problem is that this limit 
might in general be reached at a different size for horizontal and 
vertical coordinates (although that would not happen with the XQ-board 
bitmaps we provide), and that stretching one direction and not the other 
might make the texture look strange.

We should also take into account that for boards other than XQ there are 
no adverse facts from having the actual board larger than 1.5x the 
texture. For Chess it can be 8x the texture, which would just mean that 
all 'cutouts' are the complete texture bitmap, so that all squares get 
the same. This is noticeable, but not fatal. Doing sizing here when you 
exceed the 1.5x limit might actually lead to worse resolts (lowered 
resolution on the texture) than the current algorithm.

H.G.

Sebastian Pipping schreef op 9/15/2014 9:32 PM:
> When I maximize the window to full screen, the boards starts to look
> very weird, see [1].
>
> I started inspecting BlankSquare and CutOutSquare in draw.c.  In
> CutOutSquare there are guards
>
>    if(textureW[kind] < W*squareSize)
>
> and
>
>    if(textureH[kind] < H*squareSize) .
>
> Is my understanding correct that these are meant to detect if the
> provided texture files are expected to be (a) a single field or (b) a
> full board?  If so we might need a new config parameter to tell XBoard
> from the outside for once, instead.
>
> What do you think?
>
> Best,
>
>
>
> Sebastian
>
>
>
> [1] http://share.pho.to/7AF1Z/8g/original
>
>