Joshua Pettus schreef op 9/16/2014 1:06 AM:
I wonder if we can use a SVG board instead?
This would work for an even board with a grid, but SVG is not really
suitable for textures. As it is the code is completely specific for
cutting out bitmaps, and cannot handle SVG. It is conceivable that we
would equip it with a 'pre-processor' which would first render the SVG
to a raster image of the exact full board size, and apply the existing
cutting algortithm to that.
But, considering the very different requirements for a true texture and
a drawn, scalable grid, it would be better (and not more difficult to
program) to not use an SVG board image in stead of a PNG, but next to it
as an overlay.
I have already been working on text overlays for pieces, and this would
be a similar thing for the board. The text overlays should work by
having a -pieceToKanji UTF8 string option that would assign an UTF8
character to each white piece type. That character would then be drawn
over each piece of that type. This would allow you to only provide SVG
images of the 'koma' of Shogi pieces, and have XBoard take care of the
inscribed kanji. This already works for inscribing Latin letters, but I
could not get it to work with actual kanji (probably because I am
lacking some language packages), and I haven't put in the code to
actually flip the kanji for the side playing down the board (I think).
Once this feature works, it would be possible to have XBoard support
large Shogi variants without the need for making more piece SVGs. Of
course the notation problem would still have to be addressed as well,
for variants with more than 26 pieces.