What is new?

New features for the next release Resuming saved unfinished games Setting up positions more easily Bitbase adjudication Showing tablebase hits A new ICS window Recalling board themes (XB) Playing moves by clicking them Fonts in the XBoard GTK build Using the mousewheel (XB) Displaying a blunder graph Slicing up a PGN database

New variant support ASEAN Chess Chu Shogi Mighty Lion Highlighting squares on engine command Let the engine finish a user move Non-standard variant names Fischer castling in any variant Knowing the moves of unknown pieces Experimental features Promotion popup and piece menu Support for non-Chess-like games The large Shogi variants Switching to a better plot library

Home (with downloads)

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 restores 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 has 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 dragged off board to get rid of them, pieces you only need once can be simply 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. Clicking an already selected piece a second time in Edit Position mode used to make it disappear. This was more an annoyance than a feature, as it often happened by accident, and it then required multiple mouse clicks to get the piece back. There are plenty of other ways to remove a piece, like drawing it off board, or moving an empty square on top of it. So the second click on a piece is now used as a signal to promote or demote it, which is very useful in Shogi-like variants, where all pieces can promote, but the promoted versions are usually not present in the 'palette', as the latter is derived from the opening 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.

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 was 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 that 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.

This new ICS Interaction window can be controlled from the keyboard: Typing <Tab> in the input text entry will navigate between busy chats (opening the chat pane if necessary) starting with those that have been active since you last saw them. Typing <Esc> wil hide the chat pane, so you can start entering ICS commands. If the chat pane was already closed, it will transfer focus to the board window, so you can exercise menu functions by typing accelerator keystrokes. Typing printable characters when the board has focus will automatically transfer that focus to the input field of the ICS window again, making it pop up if necessary. (The latter can be controlled by the option -autoBox true|false.) Typing Ctrl-N will navigate to an idle chat (or chat nr 5 if there is none), giving focus to the 'Chat partner' entry so you can assign it. Typing Ctrl-O will similarly navigate to an idle chat, automatically assigning it to the origin of the latest message you received in the ICS pane, allowing you to easily answer it.

The ICS pane has a context menu similar to WinBoard's: when you right-click a word in it, the ICS Text Menu dialog pops up under your mouse, and you can select commands from it that would automatically incorporate the clicked word. Such as challenching a person, opening a chat for a person, channel or shouts. Note that the ICS Text Menu is user-configurable through the -icsMenu option in your ~/.xboardrc file.

The general handling of chats has also been improved a bit: broadcasts by a person will also appear in a private chat you have open for that person, clearly marked as broadcasts. That will not suppress the appearance of the broadcast in the chat you have open for that channel, or the ICS pane.

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 has been 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, so that it can be recalled from the listbox later.

Playing moves by clicking them in a text window

XBoard already supported the possibility to play moves from the Engine Output window in analysis mode, by right-clicking on the PV they were part of. This was integrated with the possibility to walk through the PV by moving the mouse with the right button kept down, using the main board as a 'variation board'. This way you could even play a number of moves of the PV. The PV-walk in analysis mode started at the position after the first move of it, so that a static click would play that move. If you would move to another position along the PV before releasing the button, then all moves upto that position would be played, and analysis would continue there.

This could be a bit confusing for people that often wanted to walk through alternate PVs. (To walk the latest PV you can right-click the board, which never plays a move.) They would have to make sure to return to the start of the PV before releasing the button, in order not to play unwanted moves. Therefore the 'auto-extend' option could be used to disable this feature. This control over when to add moves as a result of PV clicking has now been improved: In WinBoard the auto-extend option can be set interactively from the General Options dialog. Furthermore, playing of move(s) is only ever done when you clicked the first move of the PV (or the data left of it). When you click the remainder of the PV, you can walk it without having to worry whether this will alter the position.

The Edit Book window now has a similar feature: right-clicking a move from the displayed list of book moves there will now also cause the move to be performed. It now also has the reverse feature: with a button in this window you can tell XBoard that the next move you are going to play on the board should not really be played, but added to the book (with a default weight of 1).

Fonts in the GTK build So far the font options were ignored in XBoard's GTK build. Now their number is even expanded: next to the existing -clockFont, -messageFont and -coordFont there are now -icsFont, -tagsFont, -commentFont, -moveHistoryFont and -gameListFont. Font specifications are not compatible between Xaw and GTK; for the latter they have to be described by names like "Sans Normal 10" or "Monospace Bold 8". To let XBoard pick a font size it considers suitable for the board size, use %d in stead of a hard number (like "Sans Italic %d"). The icsFont is used in the ICS pane of the ICS console, and should be a mono-spaced font. The moveHistory font is used in the text memos of both Move History and Engine Output dialog, to give you the opportunity to use a figurine font in those for displaying the moves that are printed there. The gameListFont is used in the listbox of the Game List; when you often use large PGN files you might want to have an extra small font there. The messageFont currently only affects the row of widgets directly above the board: the message field where the latest PV is displayed, and the buttons of the button bar to navigate through the game. It must be used to prevent these from dominating the width of the board window at small square sizes. The tagsFont and commentFont similarly affect the text memos in the Edit Tags and Edit Comment dialogs, and are mainly supplied because WinBoard has those too.

Using the mousewheel to step through the game

WinBoard already had this, but in XBoard you can now also use the mousewheel to step through the current game, when the mouse pointer is above the board, irrespective of whether it has focus. (This according to GTK custom; in WinBoard it would work when the board had focus, irrespective of where the mouse was pointing.)

Enhanced funcionality of the Evaluation Graph A new mode of displaying engine analysis of an entire game has been added, the so called blunder graph. In this mode the Evaluation Graph does not display the evaluations itself, but the difference in evaluation on subsequent moves. (This only makes sense when the evaluations come from the same engine, such as after the use of Analyze Game.) This way poor moves, which cause a jump in evaluation, stick out more visibly.

To toggle between normal evaluation display and blunder graph, you can right-click anywhere in the Eval Graph window. (Left-clicking still brings you to the move you click.) The mouse wheel can now be used on the Eval Graph to zoom the [-1, 1] score range, which formerly would allow only non-interactive control through the -evalZoom command-line option.

Selecting from a PGN database

There is a new item in the File menu: Save Selected Games. This will cause all games currently selected for display in the Game List (through applying a text filter, or using the Find Position button) to be appended to a file. The number of pieces in the final position has been added as a search criterion. The 'Save Games as Book' function will now also only take the games selected for display into account. This should offer you more control over what you include in the book.

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, which are also available for XBoard in SVG format.)

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. Although XBoard is aware of all the piece moves, it does not implement the more subtle details of the Chu Shogi rules, and has to on the engine (e.g. HaChu) for more accurate judging move legality and highlighting target squares. So it is advisable to play this game with legality testing off.

Mighty-Lion and Elven 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 simplest way to view the Lion is as a piece that moves as a King, but then twice per turn, freely changing direction between steps. 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 per turn: 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 highlights 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 put down the Lion 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 (to prevent you would quickly 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. For those that want even more excitement: the same Lion piece also features in the newly added Elven Chess, next to three other new pieces on a 10x10 board.

Colored board markers applied by the engine

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 play illegal moves themselves). 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 defined.

Engines that want to make use of this new feature 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 a piece for dragging (or selects it by a static click), 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: any move that does not land on a marked square will be 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 massaging 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 or off. (Some variants, although non-standard, use only pieces that XBoard knows, and those can be played with legality checking on.)

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 enclosed 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.

Letting the engine configure the GUI's move generator

XBoard protocol has been extended with a command to tell the GUI how pieces move. This allows XBoard to become fully aware of the rules of games it never heard of, even when these involve pieces that are not amongst the 22 standard piece types it has built-in support for. Formerly variants involving such pieces could only be played with legality testing off, which would also disable the 'show target squares' option to show the user where the piece he grabs can move to. And imagining wrong moves for a piece would also generate lousy move notation (SAN), with missing or spurious disambiguation, and cause inaccurate mate detection. When the engine sends 'piece' commands at the start of a game to (re)define the piece moves, all that functionality is restored. Legality testing will still have to be switched off (or the piece definitions would be ignored), but even then 'show target squares' would work, and XBoard would test move legality, the GUI acting as a proxy for the engine. No sense in sending a move to the engine of which the engine told you in advance that it will reject it, so that the GUI would only have to take it back, after all.

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.