Tamerlane Chess

[hgm]

I pushed a version of XBoard now that uses the VariantMen PGN tag to configure the move generator. The pieceToCharTable has to be defined by the user, however; there is no automatic assignment of pieces (ID + move) to glyphs yet. But if all IDs used in the PGN are defined, you can now load the PGN in game viewer mode, and it will be able to parse it.

E.g. when you start XBoard as

./xboard -pieceToCharTable "S.....F..........^F..........^S....L.......PC......RXs.....f..........^f..........^s....l.......pc......rx" -variant shogi -ncp

you can then paste the PGN

Code: Select all

[Event "Edited position"]
[Site "hgm-xboard"]
[Date "2016.02.06"]
[Round "-"]
[White "-"]
[Black "-"]
[Result "*"]
[Variant "shogi"]
[VariantMen "L:fRbrBblF;R:fRblBbrF;C:FvW;P:fDbF;+S:fAbD;+F:bRfsWfBbF2"]
[FEN "rpcxcpl/3f3/sssssss/2s1S2/SSSSSSS/3F3/LPCXCPR w 0 1"]
[SetUp "1"]

and XBoard will be fully configured for Tori Shogi! The board size will be deduced from the FEN, and the way the pieces move is given in the VariantMen tag. How they promote follows from the pieceToCharTable.

[Greg Strong]

Strange - it works sometimes and not others. If I do a game where I just focus on clearing out the space and castling quickly, it works. If I run an engine-engine match where castling happens later in the game, SjaakII rejects the move as illegal. I have the engine-debug log of such a game but it's 38 K so probably too large to post here. If you PM me your email address I can send it to you.

Does it by any chance do that when black tries to castle queen-side? I just noticed that it doesn't set the queenside-castling flag for black, even if it is specified in the startup string.

That was indeed the case, at least this time, and quite possibly every time. I was starting to think that it was a more general castling bug rather than an issue with the notation, so you've probably found it.

I uploaded the fixed source (http://www.eglebbk.dds.nl/program/downl ... src.tar.gz) if you want to test if this indeed fixes the problem for you (to compile in Linux, go to the Build/ directory in a terminal and type "cmake .. && make". You will need the CMake program, which should be available from the package manager if it isn't installed already).

Ok, I can confirm that that solved the problem. Thanks for the quick fix!

Sorry it took so long to verify. I actually hadn't tried my GUI on Linux yet. I naively assumed since it was .NET that it would just run on Linux under Mono, but that was definitely not the case. First there were problems associated with case-sensitive paths and / vs \. Then Mono's sudo-registry didn't work quite the same way. After fixing a bunch of stuff I got it running but it looked absolutely AWFUL. The rendering of images with transparency is just broken. I had to just keep trying different things until I found something that happened to work. It still doesn't look as sharp as it does on Windows, but it's acceptable. It's running Linux engines fine, but for some reason won't launch Windows engines with Wine. I think it's a problem with piping output between Wine and Linux. Something I read suggested making a .sh script that launches the program and redirects the output. Now I just have to figure out how to do that ...

Anyway, almost there ...

[Evert]

Ok, I can confirm that that solved the problem. Thanks for the quick fix!

No problem, thanks for confirming it fixes the issue!

Sorry it took so long to verify. I actually hadn't tried my GUI on Linux yet. I naively assumed since it was .NET that it would just run on Linux under Mono, but that was definitely not the case.

I would actually have made the opposite assumption: that being a .NET program, it would be quite tricky to get to run. Note that I don't have any direct experience with .NET (it's not a very natural choice if you don't use Windows) and so my preconceptions are mainly based on possibly outdated sources from a few years back.

Compiling SjaakII on Windows shouldn't be hard either, by the way: it has a VS project file that should work, or if you use MinGW, then it should be buildable through CMake the same as under *nix. In fact, that may work with VS, but I've (obviously) never tried that.

First there were problems associated with case-sensitive paths and / vs \.

Case-sensitivity is mainly a habit you have to get into; OS X is also case-preserving but not case-sensitive when it comes to matching files. Using / works on all platforms, so once you get into that habit it's also not very painful.

It still doesn't look as sharp as it does on Windows, but it's acceptable.

This is pretty weird. Not sure what might cause that.

It's running Linux engines fine, but for some reason won't launch Windows engines with Wine. I think it's a problem with piping output between Wine and Linux.

That shouldn't be an issue (it works fine in XBoard, for instance) but make sure you set things up correctly: the executable you run is wine, with the command-line argument the Windows executable that you want to run.

Something I read suggested making a .sh script that launches the program and redirects the output. Now I just have to figure out how to do that ...

Put the entire command in a script. The script (say "engine.sh" for "engine.exe") should be something like this:

Code: Select all

#!/bin/sh
wine engine.exe

and then

Code: Select all

$ chmod +x engine.sh

(I'm sure it can be done from a GUI file-manager too).

[Greg Strong]

It still doesn't look as sharp as it does on Windows, but it's acceptable.

This is pretty weird. Not sure what might cause that.

It's because the controls are different. The native Windows list control, tab control, etc. are not available. So I think what I'm getting are rough equivalents that the Mono team created. They work but they don't look or behave exactly the same. To do this the 'right' way, I'd have a separate Linux version using GTK#, a .NET wrapper around the GTK+ controls. But I won't be getting to that anytime soon (if ever.) And then OS X would have yet another version with something else.

It's running Linux engines fine, but for some reason won't launch Windows engines with Wine. I think it's a problem with piping output between Wine and Linux.

That shouldn't be an issue (it works fine in XBoard, for instance) but make sure you set things up correctly: the executable you run is wine, with the command-line argument the Windows executable that you want to run.

Yes, that's what I was doing. No idea why it doesn't work. The whole GUI terminates immediately without throwing an exception or anything. If it works with XBoard it must be something with Mono.

Something I read suggested making a .sh script that launches the program and redirects the output. Now I just have to figure out how to do that ...

Put the entire command in a script. The script (say "engine.sh" for "engine.exe") should be something like this:

Code: Select all

#!/bin/sh
wine engine.exe

and then

Code: Select all

$ chmod +x engine.sh

(I'm sure it can be done from a GUI file-manager too).

Well, that's simple. I thought I'd need some IO redirection but I guess the shell passes it through automatically (which makes sense.) Unfortunately, this wrapper didn't solve the problem. Oh well, not going to keep struggling with this for now. Other fish to fry ... But thanks for your help!

[hgm]

This is probably not yet important for Tamerlane, where the alphabet is still large enough to accomodate all non-Pawn piece types, and only the Pawn types would need a 'dressed letter' ID like R'. But it was a bit problematic to have general dressed letters appearing as promotion suffix. In particular when they also contained prefixes, like +J'. The '+' was a problematic suffix anyway, because of ambiguity with use as check indicator. Normally in games with Shogi promotions the '+' suffix would imply the promotion piece, but in case of contageous pieces this might have to be overruled. And that requires explicit specification of the piece you must promote to. And in Maka Dai Dai Shogi the contageous pieces unfortunately are promoted forms of other pieces. Merely introducing a new suffix symbol for "promote to what you captured" cannot solve it, because of the possibililty to multi-capture.

The work-around I now use is this: XBoard already did have the possibility to define 'nicknames' for the pieces, i.e. alternative IDs that it would not use itself, but would understand on input. (E.g. to be abe to read game files from a different language, where Knight=S and Rook=T.) So the trick is to define a simple alternative ID as nickname for the contageous piece. To allow the engine to do that, the nicknames can now be defined through the pieceToChar string sent in the setup command: XBoard will recognize the character combination ID=L as a definition of the given ID, plus a definition of L as a single-letter nickname for it. (The latter than overrules any nickname the user might have defined for this piece through the -pieceNickNames command-line option.) The engine can then use L as promotion suffix to specify promotion to that piece in an unambiguous way.

[JoshPettus]

To do this the 'right' way, I'd have a separate Linux version using GTK#, a .NET wrapper around the GTK+ controls. But I won't be getting to that anytime soon (if ever.) And then OS X would have yet another version with something else.

It might be possible to make a mono version. I hear mono has indeed made a lot of positive strides in recent years. Isn't the reverse true though that if you build something in with mono in mind, it will easily work on windows? I would have thought so.

We actually use GTK+ for the xboard release on OSX and works pretty good. We had to add about 50 lines of code for OSX integration. The real pain is bundling all of GTK's five million components into one portable application bundle...And then GTK's jhbuild dev environment is a real pain to setup. It actually wouldn't compile back when I tried it, plus it interferes with any package managers you have in place, which is insane design. That's why I just wrote a script to manually bundle Xboard directly off of a macports install and forgo GTK's bundling tools. (which was a whole new language to learn in it's own right).

I never heard of QT having such problems. Is there a QT# wrapper?

[Greg Strong]

Yes, I'm using Mono now. The same exes run under .net or Mono. The underlying controls are just a little different if you're not running on Windows. GTK# is also Mono. In retrospect, I could have gone this road instead and used GTK# controls under both Linux and Windows, but too late for that now.

I doubted that there was a QT#, but I just searched and it turns out there is one!