I looked at the screenshots of chesspad, and they all show the game moves with a figurine font. Can this be changed to a regular text font?
Hi David,
Yes it can be changed under preferences for language. There is a toggle for "use figurines". Default is toggled on but it switched off and went to regular text algebraic for the moves.
I must say I am not sure how large a database it can handle as i tend to download smaller databases from Chess Tempo and TWIC. BUT it has replaced Chessbase for me because it does all the types of searches that I need that Shredder Classic can't.
It is a bit simpler than the Chessbase version and is in someways a bit better. (I don't use the difference field here either).
OK, I tried out ChessPad. One thing that struck me is that the initial load of a large database is quite slow; it took 154 sec to load my 41k-games test PGN, while WinBoard does it in 30 sec (XBoard: 25 sec). A subsequent search for a position (not restricted by tag info, so it really has to go through all games) took only 5 sec, though. (WinBoard: 20 sec, XBoard: 14sec). So part of the load time must be spent to cast the PGN data into a more efficient format, which highly speeds up later searches. In WinBoard/XBoard I still have to implement that, but then it would at most take as much time as loading + a single search now, and probably part of it could be overlapped, so I would expect 40 sec. A search for material (Rook ending with 2-3 Pawns per side) took only 3 sec.
Apparently it is worth adding the search mode 'Material range' to WinBoard. As WinBoard searches for positions set up on the board, a reasonably obvious way to implement this would be to let the user set up the material that must minimally present (the lower limits) on the lower half of the board, and the additional material that may be present in the upper half. I could even add a 'Material difference' mode that works similar, except that it forces the optional material in the upper half of the board to be perfectly balanced. (So the user can specify the difference he is looking for in the lower limits.)
It is a bit simpler than the Chessbase version and is in someways a bit better. (I don't use the difference field here either).
OK, I tried out ChessPad. One thing that struck me is that the initial load of a large database is quite slow; it took 154 sec to load my 41k-games test PGN, while WinBoard does it in 30 sec (XBoard: 25 sec). A subsequent search for a position (not restricted by tag info, so it really has to go through all games) took only 5 sec, though. (WinBoard: 20 sec, XBoard: 14sec). So part of the load time must be spent to cast the PGN data into a more efficient format, which highly speeds up later searches. In WinBoard/XBoard I still have to implement that, but then it would at most take as much time as loading + a single search now, and probably part of it could be overlapped, so I would expect 40 sec. A search for material (Rook ending with 2-3 Pawns per side) took only 3 sec.
Apparently it is worth adding the search mode 'Material range' to WinBoard. ....
Hmmm... You're reinventing the wheel. And it's not going very fast ;>
PGN is terribly bound to disk I/O - the slowest part of any computer. I'd really suggest you bite the bullet and work with some chess database. Scid's si4 format is bug-free*, and it loads the 1.7 milion game Million base in between 1 and 4 seconds (depending on startup mode and system specs), and a 100 thousand games in a blink.
Obviously, Tcl is a little ugly on windows, SCID has major GUI problems, and Scid vs. PC has no installer on windows (volunteers welcome). Scidb is a new project looking for developers, which has a very attractive GUI, and can work with Chessbase and Scid dbs. Extending the very capable Xboard to do DB stuff with PGN is a little silly imho.
I mean - and i'm talking about databases here - there' nothing wrong with suping up the old Torana. You do it for love - but it never achieves anything much, and you end up buying a Porsche anyway. And PGN is more like a Model T.
What you say makes sense of course, but there are a few problems: I don't suppose any existing database format would do very well on Xiangqi games, for example. So I took it for granted I would have to design my own format, and did not even bother to check out existing database formats. (Perhaps this was a mistake. But would si4 format be able to store Xiangqi, Shogi or even Crazyhouse games?)
And if I am forced to use my own format, I cannot assume anyone to supply databases for me, and I must build in the possibility to create them myself from PGN. This is why I started doing that.
But I completely agree with your assessment that PGN is not very suitable for this. The problem is not even so much in the disk I/O; most of the time is spend parsing and disambiguating the SAN moves with the rather inefficient WinBoard move generator. So searching PGN from disk is bad, but caching the PGN in memory and searching it would not be very much better (perhaps a factor 2), especially since disk I/O can be done perfectly in parallel with a CPU-bound task like the SAN parsing. I really need a more CPU-friendly storage format. Whether I will offer the possibility to actually store in that format on disk, to speed up future loads, I have not yet decided.
I am thinking now of a format that stores moves as pairs (piece-number, to-square), with the piece numbers 1-4 reserved for special moves (promotion, castling and e.p.)., which would then specify the other info necessary for their execution (promo piece, rook move or e.p.square) in an extra pair. That would reduce the size to about two bytes per move, which gains approximately a factor 3 compared to (numbered) SAN. (And thus could speed up the disk I/O by a factor 3, should I decide to save in that format.) It allows quite efficient replay of the games for searching, because the move format directly indicates the piece in the piece list, from which the from-square follows.
It is a bit simpler than the Chessbase version and is in someways a bit better. (I don't use the difference field here either).
OK, I tried out ChessPad. One thing that struck me is that the initial load of a large database is quite slow; it took 154 sec to load my 41k-games test PGN, while WinBoard does it in 30 sec (XBoard: 25 sec). A subsequent search for a position (not restricted by tag info, so it really has to go through all games) took only 5 sec, though. (WinBoard: 20 sec, XBoard: 14sec). So part of the load time must be spent to cast the PGN data into a more efficient format, which highly speeds up later searches. In WinBoard/XBoard I still have to implement that, but then it would at most take as much time as loading + a single search now, and probably part of it could be overlapped, so I would expect 40 sec. A search for material (Rook ending with 2-3 Pawns per side) took only 3 sec.
Apparently it is worth adding the search mode 'Material range' to WinBoard. As WinBoard searches for positions set up on the board, a reasonably obvious way to implement this would be to let the user set up the material that must minimally present (the lower limits) on the lower half of the board, and the additional material that may be present in the upper half. I could even add a 'Material difference' mode that works similar, except that it forces the optional material in the upper half of the board to be perfectly balanced. (So the user can specify the difference he is looking for in the lower limits.)
ChessPad is slow for loading large databases, but I usually use subset databases (ie: of a certain opening or player etc.) when looking for positions through material search.
Good luck with the material search implementation. The website ChessTempo also has an online database with the same search function as well.
Actually it is not that bad. It seems that the standard build for XBoard does not use any optimization at all. When I use -O2 for the parser and move generator, the load time for the 41k games PGN (parsing only PGN tags) is only 10 sec. Parsing the SAN moves during loading drives that up to 19 sec. In comparison, SCID needs 9.5 seconds for this on the same machine. So XBoard is only a factor 2 slower, which is bearable. It is a lot better than ChessPad's 154 sec, anyway. (But that was under Windows, of course.)
Perhaps this was a mistake. But would si4 format be able to store Xiangqi, Shogi or even Crazyhouse games?
I hadn't considered the custom games.... I doubt si4's tightly packed DB would leave any room for alternative moves.
[SCID has a problem with maximum number of games actually, because Pascal (si4) and Shane (si3) only allowed three bytes - meaning it probably has lots of bugs after you hit the 16,777,214 games limit.]
That could indeed be a good solution. Also because I have to account for the possibility that the 'compiled' representation could be too large to fit in memory, in which case a temporary file would have to be created anyway. If we always save a compiled version, this could automatically be used for the temporary, simplifying the logic a lot, because you now don't have to figure out first if you are going to overflow memory.
On the downside is that you then also have to worry about storing all the PGN tags, comments, etc., while you don't have to bother with all that when you merely want to create a move cache to speed up position searches.
