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

[Sebastian Pipping]

On 16.09.2014 19:00, H.G. Muller wrote:
> 
> 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.

The quality would decrease if XBoard is scaling it down by a factor that
is not a full divisor of the what I scaled it up by.  Say if I enlarge
it by factor 3 and XBoard rendeers it at 50%, we get blurry lines
despite the integer scale factor.  Or we have a mis-understanding here.


> 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.

That could be a way for field-targetting textures but if that's better
or worse than scaling might depend on the nature of the texture image.
Say we had something Escher-ish with different values of "darkness" on
both white and black, scaling would keep the pattern sane, scale-cutting
would break it.


> 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.)

Let's no do guessing here, let the user tell us what it is.  If we do
apply guessing, let's at least give the user a way to fixing bad
guessing manually.


>> 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.

To be honest I don#t get all of that.


>>    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.

Alright.  So would you in general accept a patch that

  * adds a branch to the draw-blank-field function,

  * uses the current code/math for textures targeting fields

  * adds a new function for textures targeting whole boards

  * adds two switches to set field/board texture mode for each
    player color

?


> 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.

What idea is missing?


> 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.

If the image is smaller than the requested display, we have to scale
things up (speaking of full-board textures only here).  What's wrong
with that?

Best,



Sebastian