What is new?

New features for the next release

Newly supported variants

Experimental features

Home (with downloads)

The following features are new in XBoard 4.beta:

Colored board markers applied by the engine

With the option 'Show Target Squares', XBoard can be made to mark board squares where the 'lifted' piece can move to by fat yellow (non-captures) or red (captures) dots. This obviously can only work when XBoard knows the rules for moving the pieces, i.e. when legality checking is switched on. When the latter is switched off, XBoard cannot know how thepieces move (as the only reason to switch it off would be that pieces do not move as XBoard thinks they should, to prevent it from objecting to their moves), and this feature does not work.

There now is the possibility to restore this functionality with the help of an engine. Engines of course always will have to be fully aware of the rules of the game they play (or they would do illegal moves). So they also know where a lifted piece can move to. Problem is that upto now they would not know which piece is lifted, as XBoard only sends them the move after the piece has been put down again. To remedy this, an extension of the communication protocol has been made.

Engines that want to make use of this new facility can inform the GUI of this by sending a new 'feature heighlight=1' at startup. The GUI will then inform them any time the user grabs (or selects by a static click) a piece, by sending it a 'lift' command with the square coordinates. The engine can reply to this command with a 'highlight' command, which specifies which board squares have to be marked with colored dots, of eight different colors. When the engine does this, the GUI can use the markers to decide if the move the user makes when he puts the piece down is legal, without first sending it to the engine and wait if it is rejected or not: a move that does not land on a marked square is considered illegal. But the color of the square the piece lands on will be used to trigger special GUI actions. E.g. moving to a purple square will make the GUI assume the move is a promotion, and invoke the promotion popup (or trigger sweep promotion), even when it would otherwise not think so. This way engines can more flexibly implement variants the GUI knows nothing about, by modifing the GUI behavior through the color markers.

Let an engine click squares on behalf of the user

Another feature helpful in implementing strange variants is the 'click' command an engine can send to the GUI. This command will contain square coordinates, and the GUI should react to it as if the user would have clicked on the mentioned square. The engine can use this in response to the 'lift' command to implement one-click moving, even when the GUI has no idea what the rules for moving pieces are, and thus cannot know it.

Engine-defined variant names

Although XBoard knows many different Chess variants, there are far more it doesn't know. It still can play many of these, by using the board-size overrules in the New Variant dialog, providing a start position fitting for this new board size, telling it which pieces participate, and how they are indicated in move and position notation, and switching legality checking off, so it doesn't complain if we use pieces in ways they were not intended. This requires a lot of masaging by the user, though.

The engine can now be made to do most of this. For one, the engine is allowed to use arbitrary names for variants, in the variants feature it sends as startup. Even names that XBoard doesn't recognize will now appear in the New Variant dialog, so the user can select them. If the engine is set to play such an 'engine-defined' variant, it should (in reply to the 'variant' command) tell the GUI the specifics of this variant. The 'setup' command that has been added to the communication protocol will provide this information. The engine can use it to define board format and holdings size, participating pieces, initial position, and the 'parent variant'. The latter must be a variant that is known to XBoard, and it will switch to that (but using the redefined board and setup) for playing the game. In an engine-engine game only the first engine will be listened to, and the initial position will be loaded into the second engine (to allow for shuffle games with random initial position).

This means that almost everything the user had to configure to play a non-standard variant now can be done automatically by the engine. The only thing the user still has to do is control whether legality checking is on and off. (Some variants, although non-standard, use only pieces that XBoard knows, and those can be played with legality checking on.)

Saving the clock settings with the game

When a (local, i.e. non-ICS) game still in progress is interrupted and saved, e.g. because you use the 'Abort' menu item, or close XBoard, it now saves the clock settings of white and black in the result comment. When you load an unfinished game with such saved times in it, it automatically retsores the clocks to the values that were saved. This makes it easier to resume such a game.

Setting up positions

In Edit Position mode the board can be cleared by clicking on the clock, or through a piece-menu item. Upto now this irreversibly destroyed whatever position existed before. This as now been changed: by repeatedly issuing the clear command, the position can be made to cycle through the states old position, empty board, 'piece palette', initial position, old position, etc. This makes it possible to recover from an accidental clear command.

The 'piece palette' position has each back-rank piece occurring exactly once, removing all duplicates from the initial position, and no Pawns. So for orthodox Chess only the pieces on a1-e1 and a8-e8 stay. The idea is that this is a much more convenient starting point for setting up arbitrary poitions than an empty board: the pieces that were left can be used as a kind of tool bar from wich you can draw the pieces you need, to put them in the desired place. Pieces that you don't need can be drawn off board to get rid of them, pieces you only need once can be moved to the desired location, and pieces you need twice can be duplicated by moving them with the Ctrl key pressed. Pawns, finally, can be created by static right- or middle-clicks on the squares were you want them (pressing Shift to swap the colors for those who do not have a middle mouse button, as usual). The 'piece pallette' thus is an especially convenient starting point for setting up positions with an intermediate number of pieces, where you would have to 'create' too many pieces when starting from an empty board, and remove too many when starting from the initial position.

Quickly finishing dead-drawn games

In the late end-game (with 5 or fewer men on the board) of orthodox Chess there are nowadays tables available that show whether the game can be won against best defense (bitbases), and sometimes even how (tablebases). Engines that use tablebases can play instantly in such won or lost positions, as they can just play the best move indicated in the tablebase without any further search. When they get into a position that is a theoretical draw, however, they might still think as long as always. The tablebase does not make any distinction between draws that are 'nearly won' and those that are 'nearly lost', so that just playing one of the moves listed as draw will quickly blunder away any chances the engine might have had to win against imperfect defense. E.g. in a KBPPKB draw with unlike Bishops, the tablebase would not tell the engine that sacrificing BPP on the first 3 moves is not a good idea. So it is important to give the engine some time to select the reasonable drawing move and reject pointless sacrifices, in order to keep a fallible opponent under pressure.

Very deep searches are hardly helpful, however, as the tablebase already guarantees us there is nothing to find. Just not blundering away material, and striving for good mobility, centralization and advancing of passers, while hoping for an opponent blunder (which the tablebase will then of course immediately recognize as a win) is usually sufficient. It is especially very annoying when two engines, both using tablebases, so that you know they can never blunder away the draw, don't want to agree to the inevitable draw (because of their contempt setting), but go on for 50 moves (or several times 50 moves, when they can drag it out with Pawn moves) in a futile attempt to swindle their opponent

XBoard now has an option to avoid this problem, without corrupting test results for engines that do not use tablebases by awarding them wins they would never be able to find themselves, (just because XBoard's tablebase says they are wins), or awarding them draws that they would not be able to hold on their own. This new option -first/secondDrawDepth N can be installed with engines that use tablebases, to limit their search depth to the given N, and thus speed up their play to near instancy (e.g. with N=3). This should not hurt them, as their use of tablebases guarantees they will never lose the draw, and never miss a win after an opponent blunder. When two such engines, both installed with the option, reach a drawn position, the game will end almost instantly, by playing as many moves as needed to reach a 50-move or repetion draw. If only one of the engines uses tablebases and is installed with the option, that engine would play instantly the drawing move that is best according to its 'intuition', but the other engine would be forced to prove its worth, by showing it can find the moves to secure the draw. And when the latter engine is in a won position, the option would be ineffective, but the tablebase user should be able to instantly play the best defense anyway, letting its opponent show he is able to win against that.

To allow the option to work, XBoard can now interface to Scorpio bitbases. To this end it must know the path to the bitbase files, defined as "scorpio:PATHNAME" as (comma-separated) element in the -egtFormats option. In WinBoard this option can be set through the "Nalimov path" textedit in the Common Engine Options dialog (and will be distingushed from a true Nalimov path by the "scorpio:" prefix). When the list of -egtFormats includes a "scorpio" specification, the DrawDepth options will cause them to be probed when there are 5 or fewer orthodox Chess men on an 8x8 board, and an 'sd N' command will be sent to the corresponding engine just before it receives a move, in order to retrict its search depth.

Showing or hiding engine output

XBoard used to preceed the PVs printed by the engines always with 4 colums: search depth, score, time and number of nodes searched. The protocol specs have now been extended to allow engines to also send selective depth, speed (knps) and tablebase hits, and for engines that send those, there can now be 7 columns of numeric data before the PV in the Engine Output window. (And because the latest Polyglot implements this protocol extension, this will include all UCI engines!)

It can be annoying to have so many columns eating away space for the PV, however. Especially with data you might not want to see, or the engine might not even print. So and option -memoHeaders has been added with which you can print headers above the columns. Right-clicking these headers can then show or hide the corresponding column. Only the depth and PV will always be displayed.

Combining ICS output, Input Box and Chat Window in the GTK version

XBoard always printed the communication with the ICS in the terminal from which it was launched. This x-terminal allowed colorization of the ICS messages by kind, something that wa not possible in the Athena widgets of XBoard's own dialogs. In GTK it is possible to color text line by line in a text edit, though. So XBoard now also displays this text in a dialog of its own. Once this feature is fully developed, the x-terminal will be abandoned.

The solution that has been chosen combines the ICS Input Box, the Chat Window and the new ICS Output widget into a single window. Normally this will contain a large output pane to display the (colorized) ICS output, with an input field (the old ICS Input Box) below it. Anything you type there will then be sent to the ICS. There is a row of buttons at the top of the window, however, which you can use to open a Chat. Pressing them divides the window into two panes, the ICS output going to the upper one, while the lower one will be dedicated to one particular chat. The Chat Partner can then be entered above the chat pane (a player name, channel number or message type), after which all messages from that source will be diverted to the hat pane. The Input field at the bottom of the window will be sent as a message to the designated Chat partner (prefixed with the appropriate tell, xtell or shout command). To give ICS commands again, you will have to hide the Chat pane by pressing the Hide button above it.

You can assign five dedicated chat windows this way, navigating between them with the buttons at the top of the window. If there is activity in one of the windows that is not currently displayed, the corresponding button will turn orange.

Storing board settings, and recalling them with a mouse click

The View->Board dialog of XBoard allowed the user to interactively set piece and square colors, define board textures or alternative piece images, and other graphical board roperties. But if many settings had to be changed in order to, say, change from a theme suitable for Chess to one for Xiangqi, the user had to do that for each of them separately. In WinBoard an entire set of properties defining the board look could be saved as 'theme'. XBoard now also has that feature. The themes are saved in the settings file as a persistent multi-line option -themeNames, and will be displayed in a listbox that is added to the View->Board dialog. The user just has to click a theme name there to recall all settings defining that theme. New themes can be created by defining a name for it in a textedit under this listbox, and OK-ing the dialog when such a name has been entered saves the currently specified board look as this theme.

Newly supported variants

ASEAN Chess: a new Chess variant

ASEAN Chess is a synthesis of Makruk and other South-East Asean Chess variants. It is very similar to Makruk, the main difference being that the count rules are simpler (but WinBoard did not implement these anyway), and that promotion is only on last rank. This is now added as a new supported variant to XBoard.

Chu Shogi

Chu shogi is an ancient form of Japanese Chess on a 12x12 board, which was already documented in the year 1250. It has been the dominant form of Chess in Japan for many centuries, and is still quite popular, although it has been overtaken in popularity by the 9x9 game with piece drops in recent times. As there are no piece drops in Chu Shogi, it has a much more Chess-like feel than the modern game.

Like other large Shogi variants, Chu Shogi is characterized by a very large number of piece types. Not only are there 46 pieces (12 of them Pawns) of 21 different types in the initial setup, but almost all pieces promote on reaching the last 4 ranks, often to pieces that move differently from all initially present pieces. (And even if they move the same, they are formally still different piece types, as they cannot promote a second time.) To implement a game with so many piece types in XBoard was a challenge, as upto now XBoard supported only 22 piece types (11 'basic' types, asn 11 promoted types). This has now been extended to 44, Chu shogi considering all 22 existing types as 'basic', and adding 22 new 'promoted' types. (Not all of those are needed in Chu shogi, though, so they don't have all been assigned new piece graphics.) A Chess-like representation was chosen, to make it possible to use the existing piece symbols. (The Japanese of course play this game with kanji pieces.)

Another issue was the Lion piece, which has a special two-step move, not uniquely characterized by a from- and to-square, but also needing an intermediate square, where it can capture a second piece in an en-passant-like fashion. This required quite some enhancements in XBoard; more about that below. For now, XBoard is unaware of how all these new pieces move in Chu Shogi; the game can therefore only be played with legality testing off, and relies on a Chu Shogi engine (e.g. HaChu) for judging move legality and highlighting target squares.

Mighty-Lion Chess

To make the Chu-Shogi Lion a bit more accessible to Chess players, a newly designed variant 'Mighty-Lion Chess' was added to XBoard. This uses the Lion as the only unorthodox piece added to the FIDE game, so that it is possible to enjoy an introduction to this piece without having to learn about the plethora of new pieces in Chu Shogi. In this variant the Knights on the Queen side are simply replaced by Lions.

The simples way to view the Lion is as a piece that moves as a King, but then twice per turn, possibly changing direction. And if such a two-step path would be blocked, it can jump to the final square directly. This way it has 24 unblockable moves. It can capture something in each of its steps, so upto two pieces: one in the conventional way, but the other by passing through it, leaving the square empty. It could, however, also elect to make only a single step. XBoard highights the squares from which a continuation step would be possible in cyan, when you pick up the Lion. (It is essential that the option 'Show Target Squares' is on in this game.) If you click on such a cyan square, XBoard will not consider that the final destination, but remembers it as a square the Lion should pass through, and highlights the squares you can reach with the second step. Clicking on one of those (which might include the clicked cyan square) then finishes the move.

Like in Chu Shogi there are rules against trading the Lions (so that you would be left with a game of normal Chess). Basically they forbid two Lions to be captured in consecutive half-moves: a Lion cannot capture a Lion if recapture is possible, and when a non-Lion captures a Lion the opponent Lion is invulnerable ('iron') on the next half-move. That makes trading the Lions away a very uncommon occurence.

Fischer castling outside Chess960

Upto now the ability to castle with Rooks not in a corner, or Kings not on the central files was a unique ability of FRC and (on 10x8 board) CRC. This made it impossible to combine this kind of castling with rules that were unique to other variants, such as for example gating of pieces onto the board, as in Seirawan Chess. XBoard now has an option -fischerCastling, which can be used with any variant, to allow Fischer castling there. This complements the already existing option -shuffleOpenings, which could be used to play any variant in a shuffle version. The shuffling respects the castling rules, though. So variants without Fischer castling would leave King and Rooks in place. But when Fischer castling is allowed, either natively or by use of the new option, the only restriction is that the King will remain between the Rooks. This makes it possible to configure XBoard for Seirawan960. In XBoard the -fischerCastlings setting can be controlled from the New Shuffle dialog.

Another new feature is in the reading of FENs. Back-rank pieces can now be anclosed in <>, to indicate that they should not be placed as the FEN specifies, but that they should be shuffled first. It will be deduced from the specified placement (before shuffling) and castling rights whether Fischer castling should be assumed. Another symbol in such "meta-FENs" is the question mark. If it is used together with a specified holdings, it indicates a piece should be selected at random from the holdings, and then placed at the location of the question mark. This van be used to specify the starting position of Seirawan2880, where one of the three Queen, Elephant or Hawk will be on the board initially, and then shuffled with the other pieces in 960 possible ways.

Using XBoard as GUI for non-Chesslike board games

Another special branch in the repository ('alien') contains a version that has implemented some features needed to play other games than Chess variants. Such games might require moving multiplepieces during a single turn, or moving the same piece multiple times. In Checkers, for instance, there might be two different paths to the same final square of a multiple capture, so a move is no longer uniquely specfied by two squares, like in Chess. The most convenient way to specify such a move is by considering it to be multiple Chess-like moves, and let user or engine specify each 'leg' of the move separately. This is implemented by suppressing the turn-change at the end of moves that are entered with the Ctrl key pressed (with the mouse by the user) or suffixed by a comma (for moves in text form, i.e. from the engine, from PGN or through the move type-in).

In Checkers of course moves can also have 'side effects', i.e. bring changes on other squares than those between which the piece moved, namely removal of pieces you jump over. XBoard now knows a number of variants where such 'alien' capture rules are automatically implemented, for Checkers-like, Go-like and Reversi-like captures, making it easy to support those games. For games with other side effects (e.g. Ulitma) there is a variant where an engine can send a complete board update after every move.

Some games also allow you to pass a turn. This has been implemented by clicking the clock of the side you want to pass the move to, like was already possible in Edit-Position mode. (But only when legality testing is off,of course.) More about the XBoard Alien edition you can find here.

From Chu to Taikyoku Shogi

Nowadays Shogi (Japanese Chess) is played on a 9x9 board. But there exist ancient variants (some nearly 800 years old!) that use much larger boards, upto 36x36. They can use several hundreds of different piece types. To support such extremely large variants, lot of limitations have to be overcome. For instance, board files and pieces can no longer be indicated by a single letter, since the latin alphabet is not nearly large enough.

Each piece type would need a different image, and the large number of board squares forces them to be tiny. Traditionally all forms of Shogi are of course played with pentagonal wedge-shaped pieces, on which the identity of the piece is written in kanji. As the large number of pieces requires at least two kanji to distinguish them, this requires a large resolution. As if that is not bad enough, a large fraction of the available area is lost to drawing the pentagonal outline, which has traditionally come in different sizes (losing even more area to write kanji on the small ones).

So basically the use of realistic images of traditional Shogi pieces piles one design flaw on top of another, leading to a disastrous result in terms of recognizability of the pieces (especially for those who do not read Japanese). It is with reason that for all other forms of Chess one does not use pictures of real woodware as the piece images, but an abstract pictogram. After all, we want to have a tool, not a toy. Therefore a piece set suitable for the large Shogi variants was designed from scratch, using as guidelines that the piece symbols should have high mnemonic content as to how the piece moves, that it should be possible to render the pieces at quite low resolution without loss of recognizability, that important pieces should 'jump out' between the unimportant. This has led to a piece set that can be largely 'auto-generated' from a table containg the allowed moves, shown for the case of Chu Shogi in the picture on the left. Rooks and Bishops might look a bit different than we are used to, but you should be able to pick them out without too much difficulty (hint: the Rooks are standing in front of the Bishops).

Resizable board and transparent pieces (XB)

In another branch of the repository on this website, 'cairo', the old graphics library of the X-toolkit is being replaced by the modern cairo library. Apart from the fact that this is yet another big step on the way to abandoning the obsolete Athena widget set, this has some immediate benefits to the user. For one, it is now possible to provide piece symbols as 64x64 .png files, and a complete set of such anti-aliased images is now included in the png directory of the source tree. To use them, a new persistent option -pngDirectory has been added to XBoard, similar to the -bitmapDirectory and -pixmapDirectory options. But unlike with the latter two, it is now no longer necessary to supply a separate set of piece images for every board size you want to use, as cairo is able to scale the bitmaps without too much loss of quality. It is also possible to supply the board textures as pgn files, through the same -dark/liteBackTextureFile options that could also be used for the pixmap textures.

When everything (pieces, textures) is rendered through cairo, it is also possible to resize the board with the mouse, for continuous scaling of the pieces. You just grab the board window in a corner, and drag it to its new size. When you stop dragging, XBoard will calculate the largest square size that could be used in the window, and will redraw the board in that size. After that it will shrink the window to fit the board.

This works especially well when the pieces are given as vector-graphics (.svg) files, which can be done through a new option -svgDirectory. If the provided pieces are black and white, the usual piece-color options can be used on them. But they can also be full-color images to begin with. A new option trueColors true|false can be used to disable the color-tinkering options.

A third novelty concerns pieces dragged for the purpose of excluding or re-including a move in the analysis of the current position. When grabbing the piece for this purpose (i.e. with a double click), it already remained on the from-square to indicate you were not really moving it, but where merely dragging around its 'ghost' to enter a virtual 'anti-move'. This is now made even more clear, by making the dragged piece transparent.