[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window
From: |
H.G. Muller |
Subject: |
Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window |
Date: |
Tue, 16 Sep 2014 21:29:03 +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 8:13 PM:
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.
I think we have, because XBoard currently does never scale textures. But
cutting a small part out of a blown-up image of course also gives you
poorer resolution than cutting from the original would, as I already
mentioned. But the solution I had in mind for that would never do that.
At startup it would load the original texture bitmap, and always keep
that. In response to a board sizing (and at startup), it would then
create a integer-times magnified version of it, that is just larger than
the board size (if it was larger than 256x256 to start with), and it
would use that for cutting.
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.
Well, I guess there is no one recipe that would work for everything, and
XBoard is not meant to be a general-purpose image viewer. 99% of the
users would not want to do anything other than use an image of their
favorite type of wood or marble to cut out as different as possible
areas to use these as squares, as if they had a board made from these
materials (if they use textures at all). Xiangqi is really the only
variant where this is not good enough, (and only if you would want
oriental representation), because the textures are used there to
implement the grid. So I adapted the cutting procedure to preserve the
grid as well as possible. But it gives some grid distortion of the
actual size is larger than the bitmap, and cuts out the squares in a
non-contiguous way if the actual board size is smaller. Users for which
this is not acceptable can simply supply a texture that exactly matches
their board size, and never change the latter. This already exceeds what
XBoard is designed for, but it still can be done, with some effort. The
only imperfection within XBoard's goals is that there is a maximum size
to the Xiangqi board without supplying your own graphics. (And IMO it is
already debatable whether this is a serious flaw; XBoard has always had
a maximum board size.) Supplying a larger bitmap would push up that
limit, and the scaling + cutting I proposed above would remove any size
limitation.
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.
He could fix it manually by changing the size of the supplied bitmap,
when we describe the behavior in the manual.
We do seem to have a different philosophy here: you prefer more options
to give the user more control, I prefer fewer options to make sure the
user has less control. Because every control you give them can be
abused. Making options to force XBoard to do things that it would by
itself consider wrong or sub-optimal will unavoidably lead to a large
number of users configuring this option the wrong way, and coming back
to complain that things do not work well.
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
?
That depends on what that patch would do for these whole boards, in
particulare the XQ board (which is really the only case I consider of
any importance), and how that would look for the available textures. It
is hard for me to imagine anything that would beat the integer blow-up
on demand + cutting I proposed above, but I am open-minded about that.
I suppose that in stead of "each player color" you actually mean "each
square color"? Beware that in Xiangqi the square colors might not be
what you expect (the board is not checkered, and the colors indicate
areas). So I am not sure if it would make any sense to ever run in modes
where light squares use a different mapping as dark squares. For
oriental XQ I even use the same texture bitmap for both.
What idea is missing?
How to map a whole-board bitmap to the display in a better way than the
existing routine does. You said you did not like scaling (and I tend to
agree; this is how we started and it looked truly ugly), and you did not
like non-contiguous or overlapping cutting because it would wreck
Escherish boards. That does not seem to leave much...
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?
That is OK, as long as it is by an integer factor. Even with
anti-aliasing one-pixel-wide horizontal and vertical lines start to look
very different depending on whether they fall exactly on a pixel or in
between.
And it is not just needed for full-board textures. If the texture bitmap
for single tiles is smaller than a square there also is a problem. If
the aim is to support unlimited board size, this is a worse concern than
the full-board issue (which is a minority application).
As for a new option to affect whether the full-board algorithm or the
single-tile algorithm would be used I would prefer a smart option over a
simple boolean. Like where you could set an integer to specify the
minimal size the bitmap should have before the full board algorithm
would be applied. People can then always mimic the boolean by setting
that size 0 or 1000000, but that doesn't prevent them from setting a
reasonable size and let XBoard it handle automatically.
Regard,
H.G.
- [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Sebastian Pipping, 2014/09/15
- [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Sebastian Pipping, 2014/09/15
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Joshua Pettus, 2014/09/15
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, H.G. Muller, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Sebastian Pipping, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, H.G. Muller, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Sebastian Pipping, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, H.G. Muller, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Sebastian Pipping, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window,
H.G. Muller <=
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Sebastian Pipping, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Joshua Pettus, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Sebastian Pipping, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Joshua Pettus, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, H.G. Muller, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, H.G. Muller, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Sebastian Pipping, 2014/09/16
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, H.G. Muller, 2014/09/17
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, Sebastian Pipping, 2014/09/17
- Re: [XBoard-devel] XBoard 4.7.3: Full board textures + maximize window, H.G. Muller, 2014/09/17