|
From: | H.G. Muller |
Subject: | Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window |
Date: | Tue, 16 Sep 2014 19:00:43 +0200 |
User-agent: | Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
Sebastian Pipping schreef op 9/16/2014 4:17 PM:
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. :-)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.
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.)
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.In the case of a full-board texture the user will not want any tile overlap because that wouldn't look like the board.
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.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.
H.G.
Best, Sebastian
[Prev in Thread] | Current Thread | [Next in Thread] |