TalkChess.com

Marcel van Kervinck prepared some nice PNG piece images, which can be used with XBoard. They come in two sizes: 80x80 and 320x320, but XBoard will scale them to the required size. They can be downloaded from https://marcelk.net/chess/pieces/ .


XBoard at -boardSize Average (54x54 squares) using the Leipzig 80x80 pieces.

nice! they look like pieces from diagrams in my grandpa's chess manual.

Apart from Leipzig there also is Alpha, Merida, Cheq and CBurnett (Wikipedia).


Cheq


Merida


Alpha


CBurnett

In the source for lucas chess src repo, there are svg versions of these and quite a few more. As such do not look blurry at higher resolutions.

https://github.com/lukasmonk/lucaschess ... ter/Pieces

Oh, that is very nice. The naming convention is different, of course, so you would have to rename them to be able to use them in XBoard.

But I was thinking about changing the naming convention for XBoard pieces anyway. The problem with the current convention is that it doesn't define any distant measure, so that XBoard cannot have an idea of 'nearly the right piece'. If the name of the image file would be a description of the move, e.g. in Betza notation, XBoard could automatically choose an applicable image for each piece occurring in an engine-defined variant. Presumably piece sets defined specifically for the variant (e.g. Chu-Shogi kanji pieces) would always offer an exact match for every piece occurring in the variant. And when playing something weird, like Chess with Different Armies, XBoard could just try to match all the exotic pieces to images of fairy pieces that have the most-similar move.

There is one problem, however: in Betza notation the difference lower-case/capital is crucial, while the file system might be case-insensitive. Fortunately lower-case letters only occur as prefixes for directional symmetry breaking or capture/non-capture divergence, and thus are not very common. We could therefore adopt the convention of prefixing every Betza lower-case letter with another symbol, like underscore _ or percent %.

This would make the Lucas Chess naming directly usable by XBoard, as the Betza notation for orthodox Chess pieces soincides with their common english piece idea. Provided we indicate the color by a leading 'w' or 'b', as Lucas Chess does. So bb.svg would indicate a black Bishop (Betza B), and wbn.svg a white Archbishop. ww_ff.svg would be a Gold General (WfF), etc.

This would relieve us from making up a large number of totally arbitrary names if we expand the number of supported pieces. The disadvantage of assigning piece images based on their move is that you could not assign them based on their usual naming. E.g. Elephants are popular participants in Chess variants, but sometimes they jump two steps diagonal (Shatranj) or can even be blocked for this move (Xiangqi), while in others the move like Rook+ Knight (Seirawan Chess). Or you would like to use the image for a 'Mastodon', which moves like a Queen limited to 2 steps. When the Elephant image is called w/ba.svg (Betza A, the Shatranj Alfil) XBoard would probably pick it for the Xiangqi Elehant and 'Modern Elephants' that in addition have another move (e.g. Betza FA). But it would never get the idea to use that image for the RN of Seirawan Chess.

This could of course be solved by having a separate piece set for S-Chess where the Elephant image is called w/brn.svg, rather than using this name for the XBoard standard representation of the RN piece. That S-Chess uses the Elephant and Hawk images for RN and BN in S-Chess is a hard-coded exception in the current system as well. (Which is possible because S-Chess is an XBoard standard variant.) As a rule I like it better when pieces that move the same look the same in every variant they occur in.

JoshPettus wrote:As such do not look blurry at higher resolutions.

That is not good because they should scale to quite huge boards. Can you make a screenshot of such a blurry case?

I guess it depends on the algorithm used for shrinking the image. If you just sample or interpolate, you might get aliasing effects when you shrink so much that the spatial frequencies you left in after anti-aliasing cannot be handled anymore by the target resolution. And when you remove too many high frequencies, the unreduced image will already look blurred. When the shrinking is done by averaging it would tend to destroy frequencies that cannot be handled anymore, so that this is less of a problem.

XBoard first looks for SVG in the -pieceImageDirectory, and if it finds it, renders the SVG to obtain bitmaps of the required square size. Until the square size changes it then keeps using these bitmaps. I think the SVG rendeing already involves anti-aliasing and transparency, so I don't think there could be any reason to not use SVG.

Indeed, SVG solves the problem in a proper manner, except that it is not always an option. PNG is the fallback. The fonts were only available in truetype, or the web app in which I use them only accepts PNG.

Having said that, I'm still interested in the real world case where the scaled 320px images look blurry, as they don't look like that on any of my devices so I couldn't reproduce Joshua's complaint yet. The idea is that in practice upsampling is not needed with this size, while the files are still quite small.

Above 320px all fonts started to show vector format artefacts BTW, such as disconnected parts or revealing where polygons were used instead of curves.

Yes, high quality upsampling is diffult, bilinear or bicubic will look blurry.
For downsampling a simple box filter will do.

There is another possibility of handling upsampling of vector graphics,
you can render into a relatively lowres bitmap (depends on how many details you want) using signed distance field,
assuming this is done per layer (i.e. black vector and white vector separately so you only use alpha channel to store signed distance).
Then you can simply upsample by using a bilinear filter (alpha) - note that this is trivial to do even with ancient GPUs.
The only tricky part is antialiasing which can be done but you need multiple samples per pixel (easy with shaders) - again all of this can be done on the CPU using piece cache for various sizes.

Here is a quite nice algorithm that works well with photographic images:
http://www.wisdom.weizmann.ac.il/~visio ... ageSR.html
Push the "Our SR Result" button next to each image to see it in action.