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
