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.
