Tamerlane Chess

[hgm]

A closer reading of http://history.chess.free.fr/tamerlane.htm revealed the line "Pawns are all different: they were miniature reproduction of one given major piece", which suggests that yes, they were distinguishable.

Well, that should be the decisive vote, then. For now R', K' etc. can be used as IDs for the various Pawns. I will still try to implement the '-' ID, and hopefully flexible pairing before the release of 4.9.0.

So I copied the current position, closed down XBoard, fired up the engine in the console to inspect what was up with the position in question - and promptly banged my head on the keyboard because the copied position doesn't have enough information and I should have copied the game instead.

This is why I always autosave all test games. You can always throw away the file if no irregularities happened.

[Evert]

A closer reading of http://history.chess.free.fr/tamerlane.htm revealed the line "Pawns are all different: they were miniature reproduction of one given major piece", which suggests that yes, they were distinguishable.

Well, that should be the decisive vote, then. For now R', K' etc. can be used as IDs for the various Pawns. I will still try to implement the '-' ID, and hopefully flexible pairing before the release of 4.9.0.

I will go with R', K' etc for the pawns for now, it seems easiest.
The only question is how to treat the Pawn-of-Pawns after it promotes: it becomes iron and gains the power to warp to an arbitrary square to fork a piece (capturing any piece on its destination square, friend or foe), after which it must promote again and turn into (basically) a new Pawn of Kings (where it's not clear what happens if the initial square for the Pawn of Kings is occupied; presumably it can't promote in that case).

So I copied the current position, closed down XBoard, fired up the engine in the console to inspect what was up with the position in question - and promptly banged my head on the keyboard because the copied position doesn't have enough information and I should have copied the game instead.

This is why I always autosave all test games. You can always throw away the file if no irregularities happened.

I managed to fix it now. It turned out that setboard would reset the promotion options tied to the piece list, which had the effect that the promotion piece was taken from the file on which the promotion occurs, making the Pawn of Rooks promote to Elephant. Since setboard is only sent to the second engine, the two engines disagreed on what should happen.

[Evert]

Ok, different question:
Stalemate is a win in Tamerlane, but it doesn't have the baring rule of Shatranj. Is there a parent variant that would give me that? If I pick Shatranj XBoard ends the game when one of the kings becomes a bare king, if I pick fairy it adjudicates stalemate as a draw.
Or should I just switch off adjudications? I suppose that's inevitable in the end anyway...

[hgm]

Can you specify what font it should use for that? The Quivira font defines a lot of chess-variant picto-graphs in its private use area; I'm not a big fan of the overall style and the fact that they're basically just outlines detracts from their appeal, but they could still be highly useful for this.

I checked it out, and currently the font is hard-coded as "Sans Normal %dpx", where the %d is 5/8 times the square size (draw.c, line 775). Making the string user configurable is trivial, but the size parameter is a different matter. Specifying a hard size (not using %d in the string) works only for one square size. The fraction of square size could be specified (e.g. in units of 1/256), but there still is the problem of positioning within the square as well (line 780). I determined all this expermentally for getting good single-kanji pieces from a blank Shogi tile of average size. (So that you could add dedicated tiles for pieces that needed other size, such as Pawn and King.) So I suppose the vertical offset as fraction of the square size would also have to be given.

My guess is that for Tamerlane it would be easier to just make 11 clones of the Pawn.svg, and use InkScape to write 11 different letters on them, than to use this feature.

By the way - I never realised that there is such a difference between XBoard and WinBoard in this respect, I thought they were pretty much the same these days. Why is there this difference?

One reason is that it is one of the latest changes, and a front-end change, so that the code for it is not shared between WinBoard and XBoard, and it would have to be done separately. And for WinBoard the need was not so great, because there already exists the Alien Edition fork, which does do such rendering of kanji (but not in a user-configurable way, but from a built-in table for all large Shogi variants upto Tai). So I never bothered to add Chu Shogi as standard variant in the standard edition of WinBoard, as I could simply bundle HaChu with the Alien Edition. To do Chu Shogi in a similar way with WinBoard as with XBoard (which uses a pictogram representation) would require bitmaps for the 22 pieces of the Chu-promoted series, for every board size I want to support it, as in WinBoard piece images are not sizable. But at least in 4.9 WinBoard will be able to load external bitmaps for all 54 piece types.

This is a bit similar to what SjaakII does: for each piece-type it has a bitmask of what piece types it can promote to, and another to indicate what it demotes to (which it only does when a piece is captured, I think). It would be great to have similar freedom in XBoard, but I can imagine that overhauling the code is a lot of tedious work that requires a lot of tedious testing.

I had not planned to do it as elaborate as that; I am happy with a system where some pieces can promote to all, and others just to one. So each piece would have a single 'partner', and if the ID assignment is such that one of those has a + or -, the letter could promote to +, or the - could promote to the letter. In all other cases it could promote to all pieces with letter ID (if they are Pawns reaching the zone, or the engine forces their promotion).

I guess this could also solve the promotion of large numbers of types to Tokin, as occurs in Maka Dai Dai/Tai Shogi: the unpromoted pieces would all identify Tokin as their partner. Tokin would identify Pawn as its partner. As it would have ID '+', this link would only be used to represent it in SAN/FEN, so it would always be written as +P, even when it is a promoted Rook. But this seemed acceptable; writing +S and +L might make sense in regular Shogi, but when they are game-theoretically the same piece type it always struck me as highly artificial.

I know it's the sort of internal detail thing that engines shouldn't be exposed to, but it would be really useful if there were some way to check what can and cannot be done through the piece-to-char table. In Postduif I have a setting that changes the piece-to-char that is sent to XBoard, so that it can still work on XBoard 4.8 (replacing the Zebra with a Nightrider and the Lion with a ... Cobra, I think). The user needs to activate that by hand though, which isn't ideal. If there is a new/better way to indicate promotion/demotion options, it would be useful if the engine could know about this so that it can use it, or fall back on the old method if needed/possible (just generate an error and tell people to upgrade if it isn't).
That's a whole different can of worms though...

Well, I am not too keen on that. Using obsolete versions does not have to be institutionalized. If an engine does want to support it, a command-line argument would be good enough as a switch, I don't even see an advantage in making it possible to set this interactively.

A bigger problem is the disparity between XBoard and WinBoard that is developing in terms of available piece images. Making an SVG image for a new XBoard piece is already a pain. But for WinBoard it is 10 times worse, as you need to do every supported size separately (and I try to support 3 sizes for fairy pieces), and you also have to supply a third bitmap for specifying the 'alpha channel', as Windows bitmaps do not support transparency. And you cannot simply render the SVG image in the required size, as this produces a grey-scale image with variable transparency. So you basically have to redraw them by hand, pixel for pixel, to get an acceptable monochrome representation (as you cannot flood-fill very well after anti-aliasing).

So Win/XBoard should definitely support enough internal piece types to do what is needed (and they do use the same piece types), but I consider it acceptable that not every piece type will have a built-in image, even in XBoard. People that write engines requiring vast numbers of piece types can bundle the engine with a directory with the required piece images. The chessvariants.org website contains several very extended piece sets (e.g. Alfaerie) that can easily be adapted to bitmaps, because they are not anti-aliased. The current situation is a bit painful, because WinBoard can also not load the pieces without built-in image as external bitmaps (because no name is defined for them). But WinBoard 4.9 already corrects that.

[hgm]

The only question is how to treat the Pawn-of-Pawns after it promotes: it becomes iron and gains the power to warp to an arbitrary square to fork a piece (capturing any piece on its destination square, friend or foe), after which it must promote again and turn into (basically) a new Pawn of Kings (where it's not clear what happens if the initial square for the Pawn of Kings is occupied; presumably it can't promote in that case).

I would treat them as different types after each promotion. The third type happens to be already present in the initial setup. But after one promotion it becomes a 12th Pawn type.

Or should I just switch off adjudications? I suppose that's inevitable in the end anyway...

Sadly there doesn't seem to be a variant that has stalemate a win without baring. Except Xiangqi and Shogi, but these would cause other problems (like zone depth). Wildebeest Chess, which I added to Fairy-Max, had the same problem. In fact variant nocastle is recommended as parent for Tamerlane, because piece swapping on capture-own only works in variants without castling rights.

But I suppose switching off adjudication is unavoidable anyway. (That reminds me I still have to check on mate detection with multiple Kings.) You could be checkmated because the only evasion would be an inter-position that puts two of your pieces in a forkable constellation, after which the promoted Pawn of Pawns jumps your King. No way XBoard is ever going to see that.

[Evert]

My guess is that for Tamerlane it would be easier to just make 11 clones of the Pawn.svg, and use InkScape to write 11 different letters on them, than to use this feature.

Ok.

One reason is that it is one of the latest changes, and a front-end change, so that the code for it is not shared between WinBoard and XBoard, and it would have to be done separately. And for WinBoard the need was not so great, because there already exists the Alien Edition fork, which does do such rendering of kanji (but not in a user-configurable way, but from a built-in table for all large Shogi variants upto Tai). So I never bothered to add Chu Shogi as standard variant in the standard edition of WinBoard, as I could simply bundle HaChu with the Alien Edition. To do Chu Shogi in a similar way with WinBoard as with XBoard (which uses a pictogram representation) would require bitmaps for the 22 pieces of the Chu-promoted series, for every board size I want to support it, as in WinBoard piece images are not sizable. But at least in 4.9 WinBoard will be able to load external bitmaps for all 54 piece types.

I would get really confused between the different versions and platforms.
I also didn't realise that WinBoard is unable to read the SVG pieces; wouldn't it safe a lot of hassle to make it able to do that (I assume Cairo is portable)?

Well, I am not too keen on that. Using obsolete versions does not have to be institutionalized. If an engine does want to support it, a command-line argument would be good enough as a switch, I don't even see an advantage in making it possible to set this interactively.

Some people look at you funny if you suggest they add a command-line option to something. Otherwise I agree.
I like to know when to disable certain things because I tend to just use a development snapshot of XBoard myself, but then users may (reasonably) just use the latest stable release, which lacks certain features.

A bigger problem is the disparity between XBoard and WinBoard that is developing in terms of available piece images. Making an SVG image for a new XBoard piece is already a pain. But for WinBoard it is 10 times worse, as you need to do every supported size separately (and I try to support 3 sizes for fairy pieces), and you also have to supply a third bitmap for specifying the 'alpha channel', as Windows bitmaps do not support transparency. And you cannot simply render the SVG image in the required size, as this produces a grey-scale image with variable transparency. So you basically have to redraw them by hand, pixel for pixel, to get an acceptable monochrome representation (as you cannot flood-fill very well after anti-aliasing).

That sounds obnoxious, but I'm surprised it has to be done by hand: The Gimp can rasterise .svg images, and it allows you to extract the alpha channel. I'm pretty sure you can even automate it with a plugin, but I've never tried to do that myself (I think the Gimp uses a form of Python as a scripting language).

So Win/XBoard should definitely support enough internal piece types to do what is needed (and they do use the same piece types), but I consider it acceptable that not every piece type will have a built-in image, even in XBoard. People that write engines requiring vast numbers of piece types can bundle the engine with a directory with the required piece images. The chessvariants.org website contains several very extended piece sets (e.g. Alfaerie) that can easily be adapted to bitmaps, because they are not anti-aliased. The current situation is a bit painful, because WinBoard can also not load the pieces without built-in image as external bitmaps (because no name is defined for them). But WinBoard 4.9 already corrects that.

That's good to know.
The problem is usually finding a good set of consistent piece images. The Alfaerie set for instance is nice because it has a consistent look, but the resolution is dreadful on modern systems...

[hgm]

I would get really confused between the different versions and platforms.
I also didn't realise that WinBoard is unable to read the SVG pieces; wouldn't it safe a lot of hassle to make it able to do that (I assume Cairo is portable)?

I don't know if it is portable. But it would mean rewriting WinBoard's graphics handling completely. Unlike XBoard, where the clocks and message field are separate widgets from the board, WinBoard draws all of those directly on the top-level window. So the XBoard code for this would not be usable as is.

Besides, 'portability' often means you have to add some 20MB of libraries for low-level functions, which I consider an unacceptable bloat.

Some people look at you funny if you suggest they add a command-line option to something.

Well, XBoard's Load Engine dialog asks for an 'Engine command', so you could just specify people have to write "postduif" there when they are using the latest version of XBoard, but "postduif -xb48" if they are still using XBoard 4.8. Even a noob should have no difficulty with that.

I like to know when to disable certain things because I tend to just use a development snapshot of XBoard myself, but then users may (reasonably) just use the latest stable release, which lacks certain features.

I understand that, but this is a bit of an unusual situation, because I am unsually late with releasing a new XBoard version, and it is supposed to remain a rare occurrence that new pieces get added anyway. If future policy will be to not supply more images than we already have, extending the number of pieces further would only create problems when you really need to use that large a number of piece types. (In which case you could not run on the old version anyway.) If people would have to supply images, they might as well assign them to piece types they would otherwise not use, instead of to imageless pieces, if the total number allows it.

Before declaring such a policy, however, I first want to be 'reasonably complete' in the images we have. Camel and Zebra are considered 'core pieces', and not having a Gnu in a GNU project seemed a fatal omission. The Wolf was a personal indulgence, for Werewolf Chess. I already made a number of other SVG images, to use in the Interactive Diagrams on chessvariants.org for Macadamia and Cashew Shogi, for which the current set of XBoard images (which I also use there) was not enough. I could add these to XBoard, but they seemed so specific that I could imagine little use other than in Macadamia / Cashew Shogi, so I might as well add them to HaChu (Right and left-handed Wheels, right and left-handed Shields, a Butterfly, an Owl. Perhaps I should add these all to XBoard now, and then consider it done once and for all. As the pieces above Lion were never officially defined, when I make the promoted/unpromoted pairing fully configurable through the pieceToCharTable, I could nor re-order them in a way that puts the generally usable ones much more in front. Now there are a lot of very Chu-specific symbols at the start of the promotion series, because the existing ordering of the old 22 pieces, which Chu uses as base pieces, forced this. And even then I had to make some of the glyphs for the first 22 variant dependent, swapping them for new glyphs only in Chu.

A bigger problem is the disparity between XBoard and WinBoard that is developing in terms of available piece images. Making an SVG image for a new XBoard piece is already a pain. But for WinBoard it is 10 times worse, as you need to do every supported size separately (and I try to support 3 sizes for fairy pieces), and you also have to supply a third bitmap for specifying the 'alpha channel', as Windows bitmaps do not support transparency. And you cannot simply render the SVG image in the required size, as this produces a grey-scale image with variable transparency. So you basically have to redraw them by hand, pixel for pixel, to get an acceptable monochrome representation (as you cannot flood-fill very well after anti-aliasing).

That sounds obnoxious, but I'm surprised it has to be done by hand: The Gimp can rasterise .svg images, and it allows you to extract the alpha channel. I'm pretty sure you can even automate it with a plugin, but I've never tried to do that myself (I think the Gimp uses a form of Python as a scripting language).

The problem is usually finding a good set of consistent piece images. The Alfaerie set for instance is nice because it has a consistent look, but the resolution is dreadful on modern systems...

In general I do not like Alfaerie too much, because I hate 'cut and paste' symbols. We don't use a Bishop-on-top-of-Rook image for a Queen either. But that is just personal taste. It is certainly an advantage that there are many, and som people like them. They are 50x50, which is a good size. (It makes them usable in WinBoard's 49x49 format.)

[Evert]

I don't know if it is portable. But it would mean rewriting WinBoard's graphics handling completely. Unlike XBoard, where the clocks and message field are separate widgets from the board, WinBoard draws all of those directly on the top-level window. So the XBoard code for this would not be usable as is.

Besides, 'portability' often means you have to add some 20MB of libraries for low-level functions, which I consider an unacceptable bloat.

Well, the Cairo DLL is apparently in the order of 1MB, but I haven't been able to find an easily available Cairo package (most download sites seem to think you want it as part of GTK rather than stand-alone). The Cairo site suggests you want libpng and zlib in addition to Cairo itself, but I'm not sure why those would be needed (zlib is needed for libpng, but Windows has native functions for reading PNG files, I think?).

Cairo seems to have functions for rendering directly to a Windows surface, so it should be possible to do the conversion on the fly, without needing GTK. Lacking Windows, I obviously don't have any personal experience with this though.

Even if that is too much work, it seems worthwhile to make an external utility to convert the SVG images to the required Windows bitmaps.

Before declaring such a policy, however, I first want to be 'reasonably complete' in the images we have. Camel and Zebra are considered 'core pieces', and not having a Gnu in a GNU project seemed a fatal omission. The Wolf was a personal indulgence, for Werewolf Chess. I already made a number of other SVG images, to use in the Interactive Diagrams on chessvariants.org for Macadamia and Cashew Shogi, for which the current set of XBoard images (which I also use there) was not enough. I could add these to XBoard, but they seemed so specific that I could imagine little use other than in Macadamia / Cashew Shogi, so I might as well add them to HaChu (Right and left-handed Wheels, right and left-handed Shields, a Butterfly, an Owl. Perhaps I should add these all to XBoard now, and then consider it done once and for all.

Well, I'm not much of an expert on what would be needed for large variants of Shogi. Looking at it from a different perspective, I wonder if it is worthwhile to have something to represent the different "basic" leapers: WFNAZC are taken care of, what about D, H and G? For D I guess most variants use the "crowned rook", but it might make sense to add an alternate (a catapult, say?). I don't know what H and G would best be represented as. It appears that a case could be made for including a Giraffe in the menagerie (we have Zebras, Gnus and Lions already). Other than that... perhaps a Bow&arrow or a Chariot?
I think that covers all reasonable requests for additional images on top of the other new additions.

In general I do not like Alfaerie too much, because I hate 'cut and paste' symbols. We don't use a Bishop-on-top-of-Rook image for a Queen either. But that is just personal taste. It is certainly an advantage that there are many, and som people like them. They are 50x50, which is a good size. (It makes them usable in WinBoard's 49x49 format.)

The compound pieces for the most part look very silly (although I actually like the Amazon), but they help visualise the move. I disagree about 50x50 being a good size though, it becomes really blurry when scaled on a high-resolution display. It's sortof ok, but it's not very future-proof.

[Greg Strong]

For what it's worth, I think there value in being able to represent all positions with FENs and having a unique notation for all types of pieces. Of course, for games with lots of piece types it can be difficult or impossible with only single-letter notations. So, in ChessV I allowed two-letter notations. If the first letter of a two-letter notation conflicts with a one-letter notation, you prefix it with an underscore to disambiguate. (The underscore is always removed before any display to the user.) Even for games with less than 26 piece types, I didn't want to have to use random letters, and for example, in Chess with Different Armies, I wanted a unique notation across all armies.

In SjaakII I allow double-character encodings, but the second character has to be a punctuation mark. Beyond that it's arbitrary.
Not particularly pretty, but it works well for communicating with XBoard.

P.S. Good to be back. Glad to see you're both still hard at work creating greater support for chess variants while I've been slacking I plan to be around for a while now that my kids have reached a more manageable age, and hopefully release the completely rewritten ChessV sometime soon.

That would be awesome.
I opened up the ChessV source the other day (with HGM's changes to make it work through XBoard), with the idea to see how hard it would be to make it compile on Linux/OS X. Pretty hard was the answer, so I decided to do something else instead.

It would be really good to have another "current" multi-variant engine (in particular if it's configurable, hint-hint).

Yeah, porting ChessV to Linux would be fairly hard, but it should run under WINE - it uses very few Windows APIs, really only the most basic stuff. It's not worth doing any development on, though. The code base is a mess. It was my first attempt at any kind of chess program, and I went whole-hog with a universal chess engine and integrated GUI. It was too ambitious for a first project and it shows.

The replacement is two separate components - A new GUI written in C# which will run any winboard protocol engine, and a new winboard protocol engine written in C++. The GUI is in a very advanced state of development and is close to a state where it could be released. The engine is much farther off. I should be focusing on the GUI and releasing that first, but I've been more interested in the engine recently. It will definitely be compilable under Linux as that's how I'm developing it.

I've decided to abandon Windows because I'm seriously pissed off about the direction Microsoft has chosen to go. Windows 10 being basically a spyware operating system. It reads your personal documents and emails and gives you targeted ads. I expect that from Google because their stuff is free. I pay for Windows so that I don't have to deal with that. I've been a huge Microsoft fan for decades and now they've lost me. And if they've lost me, it's hard to believe they have any fans left. But both my government and major corporations are spying on us constantly and there seems to be little outrage and absolutely no willingness to abandon the slightest convenience in favor of privacy. So going Linux is my first concrete step. I have two machines - one running Mint and one running Qubes. I like Qubes due to it's ultra-secure design; it's very promising but still a little rough around the edges and I am no Linux guru by any stretch so I have difficulty getting it to do things. Mint has been an absolute breeze to get everything I want installed and running. I think any moderately sophisticated Windows user could make the switch to Linux Mint with very little hardship.

Question - what development environment do guys use for your C/C++? I'm using CodeLite at the moment, and it is acceptable. It's a big step back from Visual Studio though (the only Windows program I really miss.) I tried Eclipse but that thing was way too big and slow. Just scrolling would cause refresh jitters and I'm on a modern i7. I also tried Code::Blocks but the ctrl+tab document switching doesn't behave correctly and that was a deal-breaker for me right there; I use that constantly...

[hgm]

I am using gedit + gcc on Ubuntu 10.04, and NotePad + Cygwin gcc 3.4.4 on Windows.

BTW, since you are doing WB protocol, did you follow the latest developments of the protocol aimed at improving support for arbitrary Chess variants? In particular the engine->GUI 'piece' commands to reprogram the GUI's move generator through an XBetza description (since about a year), and (since about two days) the 'choice' command to control the promotion popup (or whatever method the GUI uses to let the user enter promotions)? And the somewhat older 'highlight protocol' ('highlight', 'lift' and 'put' commands, that started in the Alien Edition, but is now also incorporated in the standard edition)?