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

[h . g . muller]

Op Do, 18 september, 2014 2:10 am schreef Sebastian Pipping:
>
> but we're no longer in the past :)
>

That is true, but progress cannot be expected to be instant, and the GTK
version still has many more important defects than this. (E.g. sensible
use of fonts as a function of board size, making sizing by dragging the
window border affect the sizing of the elements above the board.)

>
> I'm pretty sure it depends on the kind of texture.  And with SVG,
> scaling should look sharp at any resolution anyway.
>

Well, it applied to the texture that I considered looking best as new
default theme for XBoard (the beechwood / cherry theme). SVG only looks
sharp on images that lack detail below a cerain size, because they consist
of evenly colored fields with sharp boundaries between them. At large size
such images would look like drawings, because they lack detail that the
eye expects of natural substances. And if you make it so detailed that
even at the largest size there are details comparable to the pixel size,
it would start to average over those as smaller sizes, producing a hazy
look that eventually will degenerate into an evenly colored mist.

Anti-alisaing is another problem; unless you really have a display where
the pixel size is much smaller than the resolution of the eye, a
1-pixel-wide black vertical or horizontal line, drawn just between two
pixels, will be a two-pixel-wide gray line. At square sizes of 50x50 that
will be very noticeable.

>
>> The problem is that the way you want it to work would wreck the
>> behavior I would like to have for the version we distribute.
>
> How so?
>
If an option would force texture bitmaps to be scaled either to board size
or square size, we would have to set it for square size to prevent that
the 129x129 textures we supply with XBoard for tiling, and then it would
not size up the supplied XQ board at the larger board size, (as it is
already larger than a square) and give exactly the artifact you showed in
the image attached to your first mail.
>
> I don't think that's the case if you separate single-field and
> full-board modes properly.  I still hope for that to come.
>
Full-board modes are problematic anyway, because full-board bitmaps have
to be specific for one board format. No matter whether you scale or cut,
the XQ bitmap will never be usable with Chess or Go, even if you would
want to play that on grid points, because it is 9x10, and when you cut it
up 8x8 or 13x13 it gets totally out of register. The same would hold for
Escherian 8x8 boards when you switch to 10x8 Capablanca Chess or 10x10
Draughts. You just cannot expect such things to work globally. XBoard
allows you to use them, but necessarily this will result in the loss of
some functionality that would exist when you were simply tiling squares.

Note that for tiling an alternative for scaling up textures that are
smaller than teh square size would be to tile the textures to a larger
bitmap before cutting from them, so that there already is some repetition
(and possibly discontinuity, if the original texture image did not have
periodic boundary conditions) within a single square. With the texture we
have, this might look better. In fact this is how I made the xqwood.png
image; that image is 441x490, and the original wood bitmap I had was only
256x256. So I tiled it first, before drawing the XQ grid on top of it.

I must admit that the new handling of themes introduced with v4.8 will
reduce the problem with options that interfere with the standard theme, as
we can only include them the theme definition of one specific theme. But
it is still important to keep the length of theme definitions manageable.

>
> The situation is better now than two days ago (and I would welcome a new
> release with those patches soon) ...

Well, that is the idea, otherwise we would just be wasting our time. As a
matter of fact we do plan a new release very soon (4.8.0), and it could
very well be exactly the version we have on hgm.nubati.net now (if no
major bugs come up).

> but I consider the fact it doesn't work
> for other full board images rather sad.  I don't really see why XBoard
> graphics quality should /not/ be as high as that of
>
> http://blog.hartwork.org/__images/setup_imitate_playok.svg
>
>
> viewed in Firefox at any given zoom factor.  Maybe that's a goal for
> XBoard in 2015.
>

That image has no texture, and quite frankly, I think XBoard with the
xqwood.png texture looks much better at all sizes below 72x72. I also
don't see that this derives any advantage from using SVG. XBoard's pieces
are already SVG, and I think the board image used would scale just as well
as PNG as it does as SVG. There is one board size where the grid lines are
exactly one pixel wide, and at this board size a pixelated version of the
image perfectly represents it. A sized version of that image, to which you
apply anti-aliasing should be exactly the same as an SVG rendering with
anti-aliasing of it.

The advantage of SVG would be that you can keep the lines exactly 1 pixel
wide (and in register) at every size, but this is not what is done here.
This is what the cutting algorithm would also do, when you cut from a
large-enough initial drawing with lines 1 pixel wide. So for XQ boards I
still seem no advantage in SVG.

For Escherian boards the cutting would not work, and exact (non-integer)
scaling would be needed. But scaling to the actual board size would fail
for variants that require different board formats.

Perhaps there should be an option like -textureBoard "10x8", which could
tell XBoard that the texture image is a full-board image of a 10x8 board.
So that XBoard could cut an 8x8 part of it (and scale it exactly to the
actual board size) when you play normal Chess. The value "0x0" (the
default value) could be used to indicate it is just a texture with no
intended relation to the square or board size, while "1x1" would indicate
it should be scaled exactly to the square size. The bitmaps would be
extended by tiling if they are not large enough for making the original
cut (e.g. if you play Shogi with only an 8x8 texture board available),
before it is scaled to fit. That means a bitmap specified as "1x1" would
be tiled on every square as an exact fit.

What do you think of that?

> I can confirm that feature is missing in Xboard, yes.
> It's a cool feature.  I would go further and allow/deny mirroring with
> certain kinds of textures but that would need new switches for a human to
> control... which I suppose you're not too much of a fan of.

I vaguely remember I left it out because at the time being I could not
find any drawing routine that did the vertical or horizontal flipping. The
options already exist for the benefit of WinBoard
(-lite/darkBackTextureMode), and XBoard just ignores them. The options
accept an integer, and I think in WinBoard only 0-3 have a meaning (no
flipping, only horizontal, only vertical, and both). When the integer is
interpreted as bit flags, there are 32 different methods of distortion
that we could independently enable with it.

>
> Frankly I believe you need to get off Ubuntu 10.04: (a) for your own
> security (you have long run out of security updates, haven't you?) and (b)
> for developing XBoard against stable or development dependencies, not
> against old-stable (in Debian terminology).
>

I still badly regret I upgraded from 8.04 to 10.04. My sound card started
stuttering, the WiFi hardware of my computer was no longer supported, and
I cannot use USB at all. I tried to install 12.04 on a virtual machine,
and the install made the VM crash. From what I have seen from other
people, 12.04 has a completely new user interface that is complete crap. I
would never want that on any computer I actually had to work on. So if
10.04 gets unworkable, I guess I would have to switch to another distro
(people recommend Fedora).

But I think that this bypasses the real problem. Which is that XBoard
should build no matter what gettext version the user that builds it has. I
think that is a quite reasonable requirement, as our C source does not
draw on any features that would not be supported by any gettext version.

That I switch to gettext 0.18 or 0.19 would not help other users that have
gettext 0.17 or 0.11 on their system (and might have a good reason for
wanting that).

Regrads,
H.G.