Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window

[H.G. Muller]

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