The Chess Variant Pages
Custom Search




[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Later Reverse Order EarlierEarliest
This item is a graphics resource
It belongs to categories: Orthodox chess, 
It was last modified on: 2005-03-20
 Author: David  Howe. Alfaerie Variant Chess Graphics. Set of chess variant graphics based on Eric Bentzen's Chess Alpha font.[All Comments] [Add Comment or Rating]
Fergus Duniho wrote on 2018-10-16 UTC

That's what it did. With this GIF, it used the actual size of the image.

Likewise with this PNG.

Maybe it chooses something like 150x150 for excessively large images.


H. G. Muller wrote on 2018-10-16 UTC

Let me get this clear: the WYSIWYG editor did decide on 150x150 all on its own, without you having to specify the height and width in the image-entry popup? Why did it pick 150? Does it do that for any image? Or just because it considered 2048x2048 ridiculously large?

In hindsight it is a bit unfortunately that all the Alfaerie SVG have native size 2048x2048, just because the Chess-Alpha set from which I started happened to have that. 50x50 would have been more convenient.

P.S. The board editor two comments down now generates more compact FENs, using the dressed-letter piece IDs rather than the parenthesized image names. Catch is that this requires the piece table for the diagram to be defined 'by hand', because there is no way to guess the required IDs from the image names. (Otherwise the script could just get the image names from the directory, which would make it easier to adapt to other piece sets.) I also put the Interactive Diagram there in 'position-setup mode', so that you can make multiple drops of a piece selected in the list.


Fergus Duniho wrote on 2018-10-15 UTC

I used CKEditor's WYSYWYG mode to post the image, and it turns out that it set a size for the image without me realizing it. I am switching to Source mode to control the HTML.

Here it is without any size specified:

https://www.chessvariants.com/graphics.dir/svg/alfaerie/wking.svg

Here it is with 50x50 size:

https://www.chessvariants.com/graphics.dir/svg/alfaerie/wking.svg

H. G. Muller wrote on 2018-10-15 UTC

That is good news. How do you control the size, though? I understood the 'native' size of the Alpha set was 2048 x 2048 (and 100x100 for the XBoard pieces).

I have been experimenting with connecting the SVG renderer to my board-editor page:

Board Editor

Files: Ranks:
Light: Dark:
White: Black:
satellite=Musketeer graphicsDir=http://winboard.nl/my-cgi/fen2.cgi?s=33&p= whitePrefix=w blackPrefix=b graphicsType= squareSize=35 lightShade=#e8c080 darkShade=#a89060 symmetry=none promoZone=0 useMarkers=1 royal=6 pawn::fmWfcF:::99 knight:N::::99 bishop:::::99 rook:::::99 queen:::::99 king::::e1,,e8:99 archbishop:C~:BN:knight--bishop::99 chancellor:R~:RN:knight--rook::99 amazon:Q~:QN:knight--queen::99 wazir::W:::99 ferz:::::99 dababba::D:warmachine::99 elephant::A:::99 camel:::::99 zebra:::::99 wildebeest:-:NC:knight--camel::99 bird:H:ADGH:::99 unicorn::WN:::99 squirrel:-:NAD:::99 snake:-::::99 crocodile:-::::99 kangaroo:-::::99 ram:-::::99 ox:O::::99 rhino:-::::99 tiger:T::::99 lion:L:KNAD:::99 gryphon:G":FyafsF:::99 dragon:D!::::99 grasshopper:Q;:gQ:::99 vao:B;:mBcpB:::99 cannon:R;::::99 leo:Q;:mQcpQ:paovao::99 wazirknight:N':WN:::99 ferzknight:N`:FN:::99 pegasus:-::::99 nightrider:N^:NN:::99 dababbarider:D^:DD:warmachinerider::99 elephantrider:E^:AA:::99 modern elephant:E`:FA:elephantferz::99 phoenix:E':WA:elephantwazir::99 alibaba:A:AD:elephantwarmachine::99 kirin:-:FD:warmachineferz::99 champion:A':WAD:::99 wizard:C`:FC:moon::99 mage:-::::99 fool:-::::99 man:M:K:::99 archer:-::::99 duke:-::::99 minister:-::::99 cardinal:-::::99 chancellor:-::::99 falcon:-:O:::99 halfbishop:-::::99 halfrook:-::::99 halfqueen:-::::99 flag:-::banner::99 steward:-:mWcF:::99 berolina pawn:-:fmFfcW:berolinapawn::99 asian pawn:P':fW:chinesepawn::99 lance:P^:fR:::99 horse:N~:ffN:::99 silver:S:FfW:silvergeneral::99 gold:G:WfF:goldgeneral::99 tokin:-:WfF:promotedshogipawn::99 promoted lance:-:WfF:promotedlance::99 promoted knight:-:WfF:promotedknight::99 promoted silver:-:WfF:promotedsilver::99 dragon horse:B':BW:promotedbishop::99 dragon king:R`:RF:promotedrook::99
square size: pixels

You can drag pieces from the table to the board. Clicking on a piece name shows its moves

Betza move description:

Move definition:

Design your own piece

In the pane above you can define moves of a piece by clicking the squares it should be allowed to move to. First click defines a leaper move to the square. A second click would convert this to a slider/rider move that repeats that step/leap. A third click would remove the move again.

To limit the range of a slider you can click the first square along its path that it should not be able to reach. Clicking on the piece takes away all its moves, and thus clears the entire pane. After you are satisfied with the move, you can press the 'Assign Move' button, and then click in the piece table in the 'move' column of the piece you want to assign it to.


Fergus Duniho wrote on 2018-10-15 UTC

On my PC, the image showed up on every browser I tested: Vivaldi, Chrome, Firefox, Internet Explorer, Safari, and Opera. Its aspect ratio was distorted in Safari, so that it was too short or too wide. But this is probably because the latest version of Safari that runs in Windows is old. It appeared fine in Safari on my iPad. Based on this, I expect SVG images to show up in any modern browser.


Fergus Duniho wrote on 2018-10-15 UTC

I copied them to this site. This is just to test that they show up in the browser:

https://www.chessvariants.com/graphics.dir/svg/alfaerie/wking.svg


H. G. Muller wrote on 2018-10-15 UTC

I uploaded a tar ball with all the SVG images to http://winboard.nl/graphics.dir/svg.tar.gz .

Testing a board with holes:


H. G. Muller wrote on 2018-10-14 UTC

Well, WinBoard uses asterisk for non-space in FENs, and I was planning to do that here too, rendering the corresponding squares as transparent. But for combining two pieces there are still plenty other characters available. The current version of my renderer (fen2.cgi) uses parentheses to enclose piece names for which no dressed-letter ID is available. I could easily switch that to braces, I have no preference in that respect. I don't think it is a good idea to use the same enclosing for full piece names and IDs, though. Infix notation is unambiguous enough.

I have now made it such that a 1x1 FEN always uses fully transparent background, so that it can be used as a piece in other drawing routines (such as the Interactive Diagram). That means the CGI argument p=... has become somewhat redundant; to get a bishop (which before required p=wbishop) now can simply be done by f=B. That means that the piece-combining also works, f=N-Q would give you an Amazon, and f=_Q an inverted Queen. I think I will keep the p=filename argument, but implement it to do the same as f=(filename), i.e. slam parentheses (or braces) around it, and then treat it as FEN.

It might also be worthwile to have a way to add board markers. Perhaps as a second 'color FEN' through the argument m=, where each letter then indicates a color (and perhaps a shape) to be drawn over the corresponding square.


Fergus Duniho wrote on 2018-10-14 UTC

The SVG pieces are looking good. When you have finished making them, I'm hoping you could put them into a zip file and make it available for downloading. I could then work on making use of them with Game Courier and the Diagram Designer.

It is good to be able to put more than one piece on the same space, but I'll point out that Game Courier uses the hyphen for non-space, and you might want to do the same if you plan on handling boards that are not completely rectangular. In that case, you might want to come up with a different way of including multiple pieces on the same space. Since Game Courier encloses longer names in braces, what I'm thinking of is to place multiple comma-separated names between a pair of braces.


H. G. Muller wrote on 2018-10-14 UTC

Some more SVG:

I now also allow specification of a rotation in the FEN, through prefixes '_' (180 deg), '>' (+90 deg), '<' (-90 deg), '><' (+45 deg), '>>' (+135 deg) etc.

I took the liberty to redesign the 'Steward', giving it a bit more 'body'; the original one was a bit flimsy.


H. G. Muller wrote on 2018-10-13 UTC

I guess things are nearly as I want them now:

Like a hypen between two pieces displays the pieces in the same square behind each other, a vertical bar will display the pieces above each other, the lower one vertically flipped to create symbols for forward-backward asymmetric pieces ('hunters'). It also cuts the pieces to half the square size, in that case:

The renderer now first looks if there is a file defaults.ini in the directory for the specified SVG piece set. This file can overrule the hard-coded defaults for the colors (including the original white filling color, so it knows what to replace). In addition it can specify some scaling parameters used for displaying two pieces in one square (horizontal and vertical scaling, horizontal offsets, vertical culling), so these can be made piece-set dependent. Finally it allows specification of a list of aliases for the dressed-letter codes used in the FEN. E.g. B~ stands for knighted bishop, but in Alfaerie this is a cut-and-paste symbol for which I did not make a separate SVG image. So I defined it as an alias for B-N, synthesizing the image on the fly.


H. G. Muller wrote on 2018-10-12 UTC

> Are you using Inkscape, loading the bitmap, and tracing over it?

Indeed, that is exactly what I do. I do the tracing by hand in course steps with 'Pen', making a polygon with corners at every sharp corner of the perimiter (ignoring tusks, horns or antennae), and at about every 30 degrees of smooth curves. I make that 75pt wide and red (to distinguish it from the background bitmap). Then I switch to point-editing, and start to bend all the chords of curved outlines in shape, usually by adjusting the 'angular hands' that appear in the end points of the segment once you curve it. I don't use any filling at that point, to make it easy to later remove the bitmap. Then I trace over any details the same way, sometimes with a 60-wide line (and set the end-points to 'rounded'). Usually this is just one or two lines, and an eye. Then I delete the bitmap. Finally I select everything, change the 'stroke color' to black, and select filling with #f9f9f9ff (RGBA) for the outline (and possible horns / tusks, which I drew as an open 'V'). This is the color used for white-piece filling in the original Chess Alpha SVG set, and which the CGI renderer is programmed to replace. (It is annoying that this is different from XBoard's #ffffcc.) Then I group everything, 'Save as', delete and copy-paste in the next bitmap, and scale it up (through Object -> Transform -> Scale) by a factor 4096% to make the 'nominal' size equal to that of the original Chess Alpha pieces.

Of course many similar pieces, such as the riders and ferzed or wazired leapers are cloned from each other, and where I could I started with an original Chess Alpha piece, cutting away the parts I did not want by deleting the points there in point-edit mode, and then adding new points by double-clicking the segments, and move those where I want them now.

Of course it helps that I only need outline pieces, so I don't have to make black pieces separately.

It is a bit of a pain that the color-to-replace depends on the image set. I would hate to hard-code that in the renderer. We could adopt a convention that in any directory with SVG images we put a colors.ini file which the renderer would read at startup, to define the color to replace, and the default filling colors and square shades for that piece set.

Some more:

I don't think it makes sense to also make inverted or rotated images (even though that would of course not be very hard); it seems better to equip the renderer with an option to do that. That could also hold for most cut-and-past combination pieces, which can be produced from their primitives by the renderer.

I also had a look at the Alfaerie extension sets, but there seems to be a lot of nonsense there. Colored disks for use as board markers are useful, but they do not belong in a piece set. Board markers should be a class of their own, as they are usually independent of the chess font used. Also there seem to be alternative representations of the same piece. It is true that the Alfaerie Camel (and to a lesser degree the Elephant) sucks. But that's Alfaerie. One should not combine glyphs from all kind of different fonts for the same piece, and than slam a new name on the entire collection. And some of the animals in the extension set are completely 'out of style' (e.g. Crab), using a higher resolution with thinner lines. There are also multi-colored images, (with red eyes and such), which as far as I am concerned is also a no-no.

Perhaps we should clean up the set a bit, throwing out all the stuff that is not likely to be used by anyone in the future. I doubt it is useful to have all kind of 'starred' animal images, with an undefined move.


Greg Strong wrote on 2018-10-11 UTC

Well that is very impressive.  You've got way more done that I have so you must have a pretty good technique.  Are you using Inkscape, loading the bitmap, and tracing over it?

I'll do some more pieces in the Abstract set and upload what I've completed.  (The Abstract set is easier to do anyway since it is so geometric.)

Then I need to get ChessV supporting vector graphics, which is why I started making them.


H. G. Muller wrote on 2018-10-11 UTC

Yes, I did. Still busy completing the last row, but I get a bit tired of it now.


Greg Strong wrote on 2018-10-11 UTC

Wow, that's some pretty impressive progress.  You made all those?


H. G. Muller wrote on 2018-10-11 UTC

Some SVG images for Alfaerie:

And some more:

And again some more:

And I leave it for now at these:


H. G. Muller wrote on 2018-10-11 UTC

I now also put some SVG files for the Chess Alpha font (from XBoard's alternate piece sets) on my website. These can be used in the CGI renderer by adding the argument t=alpha . (For 'type'; I changed that from d= because the latter now is indicating the dark square shade used with FENs.) These are the glyphs from which Alfaerie is derived, but there are no fairy pieces amongst those.

This absence is ameliorated by a new feature in the renderer, though: it now treats hyphens in the FEN as indicating that the pieces left and right of it should be put on the same square. So X-Y means a Y behind an X. The pieces are then both vertically shrunk a bit, the one in the background aligned with the top of the square to not totally eclips it. This allows 'on-the-fly synthesis' of Alfaerie-style cut-and-paste pieces, e.g. N-Q for Amazon:

or


H. G. Muller wrote on 2018-10-10 UTC

I had an idea for a system to indicate pieces in FEN strings with 'dressed letters', which should not be too difficult to remember. No matter how ingenious a system is, in the end there are just too many pieces in the Alfaerie set to avoid that you have to identify some of those by the root name of their image file. The system used in Fairy-FEN, which writes this name between parentheses, using capitalization of the first leter to indicate the color, seems the obvious way to do this. This system is already completely universal. So the system of 1-letter (possibly plus one punctuation character) codes serves only to allow a more efficient encoding.

My idea was to use punctuation to indicate various enhancements of the piece indicated by the letter. Of course we wantthe orthodox Chess pieces to be indicated by their normal 1-letter ID: P, N, B, R, Q or K. But e.g. a tilde '~' suffix could be used to indicate the piece indicated by the preceding letter is knighted (the tilde looks somewhat like the letter N, hence it seems the obvious choice for indicating this). So Archbishop, Chancellor and Amazon would be B~, R~ and Q~. By also assigning single-letter codes for Wazir (W), Ferz (F), Alfil (E, as we usually depict this as  an Elephant, and for this purpose it seems more important to represent how the symbol looks than representing its move), and Dababba (D), we then also cover all 'augmented Knights', W~, F~, E~ and D~.

In a similar spirit, we could use a (single) quote for a wazired piece, and a back-quote for a ferzed piece (because the backquote typically is more slanted in most fonts). The Crowned Rook and Bishop then become R` and B'. Modern Elephant would be E` (ferfil), Phoenix (WA) would be E', Kirin (FD) would be D` and Woody Rook D'. If we assign the letter A to the Alibaba, we have A' for the Omega Champion, A` for the CwDA Fad, and A~ for the Squirrel (NAD).

A '^' could be used to indicate a rider, e.g. N^ is Nightrider, D^ is Dababba-rider. P^ could be the Shogi Lance, which is the slider version of the (Shogi) Pawn. The basic obliques would also have their own letters, N (Knight), Z (Zebra) and C (Camel). That makes the Omega Wizard C`. This relatively simple set of conventions already covers a very large fraction of the pieces one typically encounters in variants. A colon could be used to indicate Pao-like hopping: 'R:' for the Xiangqi Cannon, 'B:' for the Vao, etc. Perhaps the G and S should be reserved for Gold and Silver general.

Remaining letters could be used as abbriviations for animal names. E.g. L = Lion, T = Tiger, H = Hawk, U = Unicorn.


H. G. Muller wrote on 2018-10-10 UTC

While I was at it, I thought I might as well equip the renderer with a FEN parser, so that it also can generate whole-board images. Presence of an f=<FEN> CGI argument triggers this mode. E.g.

This needs a few more (optional) parameters to control, as white and black pieces are now present at the same time, and we also have to deal with the square shades. So one can specify four colors, through parameters 'w', 'b' (white and black piece filling colors) and 'l', 'd' (light and dark square shades). These all have suitable defaults. The 's' argument indicates size, as when rendering a single piece.

There of course is the problem here of how to assign letters to unorthodox piece types (and how to then translate those in the renderer to SVG filenames). For now I used the XBoard 'canonical' assignment, which was in use when XBoard still only supported 22 piece types, and I still had the illusion that you could get away with an assignement that would be the same for all variants. All 26 letters mean something, but in the end 26 will of course not nearly be enough. Latest XBoard supports 66 piece types, and to support variants that need more than 26 types at once it also allows 'dressed letters' (suffixed by punctuation characters, like c' or L!). This is definitely an area that still requires some thinking.

The assumed SVG naming now is the same as that used by XBoard (like WhiteKing.svg, BlackCamel.svg), which is also not ideal. Alfaerie naming conventions are in general better. But what I consider most important is to have consisten naming through all piece sets.

One example that does not use default settings

http://winboard.nl/my-cgi/fen.cgi?f=tyexkeyt/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR&w=c0ffc0&b=8000C0&l=ffe8c0&d=D09080&s=55

gives

Rendering single pieces is still possible with this same CGI program:


H. G. Muller wrote on 2018-10-09 UTC

OK, it seems I messed up when copy-pasting the JavaScript code for the Interactive Diagram in the comment below (as it was not possible to update it in /membergraphics, and links to the updated version on my website were mutilated), and somehow destoyed the closing </script> tag, so that the entire sequel of the page has disappeared. Including the link that would have allowed me to edit it to undo this mess. When I had it as preview everything was perfectly fine, so I don't understand how this could have happened.

Sorry about this. I guess an editor will have to directly access the database to restore the </script> tag.

[Edit] I was able to recover after all. Just lost my posting. What happened was that the JavaScript was too long, and the submission software clipped my comment, including the </script> tag.So that the entire remainder of the Comments page became invisible, as the browser thought it was all JavaScript. I could access it by looking from the page source what the 'Edit' link does, and then guessing the comment ID untill I guessed right. Unfortunately I lost the entire comment because of this, as it was in the clipped section.


H. G. Muller wrote on 2018-10-09 UTC
graphicsType= graphicsDir=http://winboard.nl/my-cgi/piece.cgi?s=72&c= whitePrefix=e0c0ff&p=White blackPrefix=8000c0&p=White squareSize=74 symmetry=mirror Pawn::::a2-h2 Knight:N:::b1,g1 Bishop::::c1,f1 Rook::::a1,h1 Queen::::d1 King::::e1

For getting this I set the graphicsType to empty, graphicsDir to point to the CGI file with the size argument and c=, and made the whitePrefix and blackPrefix the desired color codes and p=White (so both sides use the 'white' outline pieces, but with different filling color.


H. G. Muller wrote on 2018-10-09 UTC

Progress: as I expected the webserver (lighttpd) is configured by default to only execute CGI programs when they are in the cgi-bin directory. But it was also configured to alias any URL that contained this directory name to /usr/bin/perl , which is apparently where gitweb lives. This must have happened as part of installing gitweb (which in some earlier version must have been a true .cgi file, but now apparently is something entirely different). So anything inside the real cgi-bin directory was inaccessible, web-access to the directory being diverted to gitweb.

I now configured lighttpd also to allow cgi execution in a new directory 'my-cgi', and a little test program that prints Content-type: text/html plus 'Hello World!' as HTML header, placed in this directory, shows the properly formatted message. So it seems I am back in business, and can now use compiled C programs as CGI, on a machine where I can be root.

test 2: printing "Content-type: image/png" and then copying an existing PGN file to stdout shows that image in the browser for the CGI's URL.

test3: I managed to instal libcairo, the (raster-image) drawing library used by XBoard. (Alas non-trivial, because the Ubuntu running on my VPS was no longer supported, and I had to reconfigure apt-get to be able to install the package from another source.) I could compile a test program that reads a PNG image into a memory bitmap, and then writes that memory bitmap to stdout as PNG. And running it as CGI indeed displays the image in the browser.

test4: This one drove me to despair again. I managed to install librsvg-2, and find the required include and library arguments for compiling. The rsvg functions that were supposed to give me ponters to 'RsvgHandles' kept returning NULL, however, but did not return an error either. I finally solved it by first calling rsvg_init(), a function that according to the librsvg manual does nothing, is deprecated, and should not be used in new code. Apparently my librsvg is so much older than the online manual, that the info in it does not apply. Strange thing is that XBoard works without calling rsvg_init(), even when I compile it for the same Ubuntu version. But it makes calls to libcairo before it invokes librsvg, and perhaps the (equally obsolete) libcairo calls rsvg_init() without me knowing it. Anyway, it works now: the CGI program reads the requested SVG image file into a buffer, and then uses rsvg_handle_new_from_data to convert this data (which at that point was still the exact file contents) to an RsvgHandle. (I took that detour, because the direct route through rsvg_handle_new_from_file() with which I started also gave me errorless NULL pointers, and I wanted to make sure that it wasn't due to inability to access the file. But I had planned to do it through the detour anyway, to get an opportunity to change the colors before rendering.)

test5: I now implemented color changing by replacing all occurences of "#ffffcc" (the default filling color of the XBoard white pieces) by the c=... CGI argument. For now, only hexadecimal RGB codes are accepted as values; it is read as an int through a "%x" format.

Mission accomplished! You can right-click on the images to see how the URL for them looks (under 'image info'). Apart from the c (color), s (size) and p (name of the SVG file without extension) there is a d (directory) argument that can be used to select another piece set.


Fergus Duniho wrote on 2018-10-08 UTC

I'm guessing that GitWeb was supposed to be installed to something like /cgi-bin/gitweb/ instead of to /cgi-bin/ itself, because it appears to be designed to monopolize the directory name as though it were a script name. I would recommend uninstalling it and reinstalling it to its own directory.


Fergus Duniho wrote on 2018-10-08 UTC

Do you have an .htaccess file in your cgi-bin or home folder? It might be set up to rewrite or redirect any URL to cgi-bin to a particular script.


H. G. Muller wrote on 2018-10-08 UTC

Nothing. The problem on the VPS is not missing software, but that CGI programs don't seem to work there at all, and cause GitWeb to run instead, for reasons I do not understand. (e.g. try http://winboard.nl/cgi-bin/gitweb.cgi and http://winboard.nl/cgi-bin/ and http://winboard.nl/cgi-bin/gobbledegook.nonsense , and they all do the same thing).


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.