Sebastian Pipping schreef op 9/16/2014 4:17 PM:
are you saying the solution is to scale up the board image, save it, and
use that for the texture? With single-pixel lines (as in the current
xqboard.png) that will not be pretty and the approach itself does not
scale since this way the window always has to be smaller than a fixed
size image. Using a 9000x10000 pixel image might be practical for
window sizes a human produces, but I don't consider that a solution.
I was more thinking of the user opening gimp, import a nice wood image,
tile it to the size he likes if it isn't big enough by itself, and then
draw a Xiangqi grid over it. :-)
BTW, the image quality would not degrade if you size it up by an integer
factor. It would even preserve the visibility of the grid lines. It
would be just less suitable to cut smaller squares from for a very small
board window. But I don't think it would be a bad strategy to have
XBoard automatically scale up texture bitmaps by the smallest integer
that makes them larger than the board size, and cut from there. Perhaps
only for texture bitmaps intended to picture the entire board, e.g. when
they are larger than 256 x 256. (And otherwise only scale them up when
they are smaller than the square size.)
In the case of a full-board texture the user will not want any tile
overlap because that wouldn't look like the board.
Well, what the user wants and what he can get might be different things.
The Xiangqi board does reasonably well upto 1.5 times the board size
(and breaks down totally beyond that). I did consider making the rim
around the XQ-board drawing a full square wide, rather than a half
square, and to adapt the cutting process to that. Then parasitic lines
would only show up after you reach twice the board size, and there would
also be no expansion of the grid before that. But it would make it
incompatible with board images drawn for the old version, which I also
consider a big minus.
Even if had second
filed-drawing function for full-board textures, XBoard would need to
know if to apply it or not. If you object to adding a switch for
full-board mode, I don't see how full board textures would be supported
properly as of now.
But the point is that we currently don't have such a second drawing
function. We only have one drawing function, which tries to make the
most of the bitmap it has. If we would implement another method of
drawing full-board bitmaps, then it would be another matter. But first
there has to be an idea for that. XBoard cannot summon up a board image
out of thin air. So if the window is larger than the supplied texture
image, it must either use parts of it multiple times (i.e. overlap),
leave parts blank, or size it up, and all of these methods are
non-ideal. If the bitmap is large enough, the current method works fine.
H.G.
Best,
Sebastian
