Moderator: Ras
Wow, well done!mar wrote:Ok the fix is rather simple. A typo I guess:
keyboard_input_waiting:now I get the expected 13%. however when run manually from the console it's still using only a fraction of CPU time.Code: Select all
if (virgin) { virgin = false; // instead of virgin = true
EDIT: +100 elo for Sjaak on Windows now in blitz I guess
Sure, I guess after you agree with Ferdy on perftEvert wrote:I have some other bugfixes locally, so it may make sense to push out RC2...
You can simply PM me when ready and I will recompile.
No bother, keep'm coming!hgm wrote:Sorry to keep pestering you:
Oops, it seems I didn't include setting the rules for dropping or holdings in the parser for the config file. I'll fix that for RC2.Someone wanted to have an XBoard engine for Goro Goro Shogi, and I recommended him Sjaak II, to configure it himself. Out of curiosity I peeked in the variants.txt file, to see how difficult this would be. Well, it seemed reasonably straightforward, except...
You do mention holdings, demotion on capture and dropping there, but it does not specify how this should be enabled. (E.g. should it be specified for each piece separately, or is it a game-global flag, and what are the required keywords and syntax.) I also could not find any drop game amongst the examples either.
Any piece should be able to get the castle flag. There should be no assumption in the code that the main castle piece should be royal (but I haven't tried it).A second point that was not entirely clear to me:
Is castling reserved for royal pieces only, or can any piece set the castle flag?
12x12 is too big. There are a number of arrays that have their size hard-coded to 128 squares maximum, but more importantly the move encoding also assumes this. I'm not sure there is space to extend that to 256 squares…I ask because I recently discovered that in Omega Chess there is this silly feature where you can castle a Queen with a Rook. (They call it 'guarding'.) Of course the problem ther is that both the Queen and the Rook move would always be legal as well, so you have to enter it as QxR. Can do Sjaak Omega Chess anyway, or is 12x12 too big?
The castle flag is only set on the piece that initiates castling (ie, the king). The castling partner is then identified by the square it's on in the line that describes the castling move, that this is missing in the examples is probably an oversight. It might make sense to define a default of "king moves two steps and castles with corer piece".I noticed that the examples do not set a castling flag on the Rooks. How is the castling partner determined? Is it always a Rook, or is it always the corner piece?
The move generator uses three bitmasks for the generation of castling moves: one that indicates which pieces are required to be virgin, one that indicates which squares should be empty for castling to be possible and one that indicates which squares should be safe (not attacked) in order for castling to be legal. There are two sets of masks for white and two for black (so four sets in total). These masks are (re)calculated based on the FEN to accommodate Chess960-style castling and they keep the move generator fairly agnostic about what is actually going on: it just knows to move some pieces from where they are to a new location, and it pulls all relevant data from tables.hgm wrote:It is not that I am particularly fond of Omega Chess, but I don't quite see the need fo having only a single piece that can castle. What would go wrong if a game definition would contain both the lines:
Castle: e1-g1 with h1
Castle: d1-f1 with h1
The reason the flag exists is so the move generator can test whether to even try to generate castling moves for a particular piece before it starts testing bitmasks. You're right that it's implied by the definition of the castling move, so setting it explicitly should be redundant.Why would a castle flag need to be explicitly specified with the piece anyway?
There currently is no default, which means that the missing Castle: line is really a bug. I have to check if this is something that was already present in the older version of Sjaak, or whether this is something I introduced recently. For the default I would specify that for short castling the king moves next to the corner, long castling moves the same number of squares in the opposite direction and castling is done with the corner piece.(I must admit that none of the examples in the variants.txt file conatins a Castle: line, though. Is a default assumed in that case? How does the default depend on the board width?)
No, but that could easily be changed by setting the "must be safe" masks to 0 if the castling piece is non-royal.BTW, if a non-royal piece is given castling rights, would it be allowed to castle over attacked squares?
Well, from this it sounds like the limitation is just that you only allow two sets of masks per side. It seems useful to increase that anyway, because some variants have castling rules where you can choose how many steps the King takes in the direction of the Rook (e.g. whether to Q-side castle by e1-b1 or e1-c1). I see no reason why some masks could not indicate virginity of the King (+ applicable Rook) is required, and other masks would require virginity of the Queen (+ Rook). They already differ in the virginity requirement for the Rooks.Evert wrote:The move generator uses three bitmasks for the generation of castling moves: one that indicates which pieces are required to be virgin, one that indicates which squares should be empty for castling to be possible and one that indicates which squares should be safe (not attacked) in order for castling to be legal. There are two sets of masks for white and two for black (so four sets in total). These masks are (re)calculated based on the FEN to accommodate Chess960-style castling and they keep the move generator fairly agnostic about what is actually going on: it just knows to move some pieces from where they are to a new location, and it pulls all relevant data from tables.
Ah yes, this is very annoying. Using O-O outside Chess960 does work in XBoard, but actually is a protocol violation.So really the reasons this doesn't work properly right now areThe last point is probably the most annoying one in practice. The reason SjaakII prefers O-O and O-O-O for castling moves was originally that this allows it to treat Chess960 and ortho-chess as the same game: XBoard protocol defines O-O and O-O-O as castling notation for Chess960 and understands it for orthochess. In practice this isn't so straightforward because UCI interfaces doesn't understand O-O/O-O-O and (worse) don't understand KxR if the variant is not set to Chess960 (I ran into this awhile back).
- Castle masks are defined per-game rather than per-piece (changing this is straightforward)
- Castling with non-royal pieces would be disallowed if it passes over "unsafe" squares (very easy to fix)
- By default, all castling moves would be output as O-O or O-O-O, independent of whether the moving piece is a king or (say) a queen.
Even if I get rid of O-O/O-O-O though it'll be annoying to work out what exactly to send to the GUI for a (non-standard) castling move since the easy alternative (always sending "KxR", ugly as it is) doesn't always work...
I guess that could be a good idea. I'll look into that.hgm wrote: Well, from this it sounds like the limitation is just that you only allow two sets of masks per side. It seems useful to increase that anyway, because some variants have castling rules where you can choose how many steps the King takes in the direction of the Rook (e.g. whether to Q-side castle by e1-b1 or e1-c1). I see no reason why some masks could not indicate virginity of the King (+ applicable Rook) is required, and other masks would require virginity of the Queen (+ Rook). They already differ in the virginity requirement for the Rooks.
I guess it depends a little on how you treat castling generation. Many engines do not tie that to generation of moves with a certain piece, but just have a separate stage 'generate all castlings' (skipped in check-evasion nodes). In such a design it would not really matter which pieces can castle, or not. You would just loop through all mask sets for the stm, testing whatever they specify you should test, and if it passes the test, the table should tell you which pieces to move and where.
Huh?Ah yes, this is very annoying. Using O-O outside Chess960 does work in XBoard, but actually is a protocol violation.
From http://www.gnu.org/software/xboard/engine-intf.htmlEven though all versions of this protocol specification have indicated that xboard accepts SAN moves, some non-xboard interfaces are known to accept only coordinate notation. See the Idioms section for more information on the known limitations of some non-xboard interfaces. It should be safe to send SAN moves if you receive a "protover 2" (or later) command from the interface, but otherwise it is best to stick to coordinate notation for maximum compatibility. An even more conservative approach would be for your engine to send SAN to the interface only if you have set feature san=1 (which causes the interface to send SAN to you) and have received "accepted san" in reply.
Well, the move parsing is on the list of things to completely rewrite (it's a mess). I'll think about how I handle this.Perhaps the protocol notation for each castling should be made configurable through the Castling: line? For input moves you could then always compare them against each entry in the castling table, and if it matches one, and the corresponding castling is a legal move, it must mean that castling, (as otherwise the notation would have been defined in an ambiguous way), and you can encode it by whatever internal format you are using (which would also be in the table). Only if it doesn't match, or the one it matches isn't legal, you would subject the input move to normal parsing. On output you would just recognize the internal castling format, and use the tabulated text string for it.
This is now fixed in the 1.0RC2 release, which will also correctly parse those options from the configuration file. I've added Judkins Shogi as an example too.hgm wrote: Someone wanted to have an XBoard engine for Goro Goro Shogi, and I recommended him Sjaak II, to configure it himself. Out of curiosity I peeked in the variants.txt file, to see how difficult this would be. Well, it seemed reasonably straightforward, except...
You do mention holdings, demotion on capture and dropping there, but it does not specify how this should be enabled. (E.g. should it be specified for each piece separately, or is it a game-global flag, and what are the required keywords and syntax.) I also could not find any drop game amongst the examples either.
Could you fix that in the description?
This is now also fixed, and you can define a castling move for any piece (well, you already could), but you can still only define one "king-side" and one "queen-side" castling move for each side, which will be written "O-O" and "O-O-O" by default or by "<from><to>" or "KxR"/"RxK" in UCI mode. However, the code is mostly ready to extend this to any arbitrary number of castling moves for any piece, I just need to expand the arrays and handle the notation logic. What to do for notation is not so obvious though.I noticed that the examples do not set a castling flag on the Rooks. How is the castling partner determined? Is it always a Rook, or is it always the corner piece?