Highlight move in blindfold mode

[rigao]

I don't know if this is a bug, a feature, or a xboard-only feature, but even though I have highlight move On, when I check blindfold mode, the highlight will disappear.

I checked and out of blindfold mode the highlight does exist (request: is it possible to make the size of the line which highlight a square a parameter? I mean, when I get the new theme, the highlight square is hard to notice and I would love to make the line a lot thicker, because there are times that I miss it), but the moment you turn blindfold mode on, it disappears again.

I don't quite like this, as it is very (VERY) annoying to read the move instead of seeing it highlighted, but maybe this is the intentional design of the mode. If so, I would quite appreciate that it could be overwritten by the option 'highlight last move'. I mean, ok, blindfold is blindfold, you don't get any visual help at all, so the default option is to turn highlight off at the same time you turn blindfold mode on. But if the user goes and checks highlight option again, then, let him play as he wishes. Is it not the whole point?

Well, I hope is not too much to code. If it is, then don't bother, I don't think I will play blindfold that much, but now I'm eager to play it and I'm not able to, and that frustrates me right now.

Thank you anyway.

[Josh Pettus]

The line can be width can be changed with -overrideLineGap # (default 1) check .xboardrc in the home folder. As for highlight disappearing in blind mode, I thought that was part of the point for one to imagine the piece moving. But I suppose your idea wouldn't hurt.

[H.G.Muller]

The suppressing of highlighting in blindfold mode seems intentional: there is a specific statement in the highlighting routine that tests for blindfold mode, and aborts the routine in that case.

Code: Select all

static void drawHighlight(file, rank, gc)
     int file, rank;
     GC gc;
{
    int x, y;

    if (lineGap == 0 || appData.blindfold) return;
...


Funny thing is that in WinBoard the behavior is completely different (this code is in the front-end), and highlights are always drawn (squares as well as arrow).

I guess it could be made to do as you say. When playing with the blindfold style on ICS, the highlights would not work anyway, because WinBoard does not understand that style, and has no idea what moves are made. So it would only make a difference in local mode, and I see little reason to prevent people from doing as they please in local mode. (I.e. in ICS mode there always is the concern for what would be concidered cheating, but in local mode you would be cheating no one but yourself.)

So perhaps I just should remove this highlight suppression in XBoard, to make it similar to WinBoard.

Of course I would like the arrow highlighting to work in XBoard; it would be the best solution for the line-gap problem. (I guess it was actually added to WinBoard for that reason.) Then you could even run with -overrideLineGap 0, which in general gives the prettiest result when textures arre used. The problem is that XBoard is very selective in which squares to redraw, and the arrow damages a large number of squares. So it is very easy to have bugs where fragments of the arrow do not show up, or fragments of the old arrow stay on, unless you redraw the full board every time (which might lead to noticeable flashing).

[rigao]

Arrows could be flashy, but I don't need them. Just a thick highlight

I'll try to delete that part of the code to see if it works properly. Well, not properly, just as I want it to work. But if you decide to delete it yourself, just announce it here, please, so I can download the last version myself. I highly doubt I would do the same good job as you will do.

By the way, I didn't know that FICS had a blindfold mode. I want to play blindfold in FICS, but just in my side. I mean, I don't care at all if I play against someone who can see the pieces, it is just me who needs (and wants) this training. Obviously my rating will drop playing against non-blind opponents (which by the way is what blind people experience everyday), but I don't mind it that much. If the blindfold mode in FICS won't let me highlight the moves, then I'm not yet ready for it, so I rather have a one sided semi-blindfold mode and assume a 200 points drop from my normal rating (yes, this figure comes from the top of my head, with no real ground base).

[H.G.Muller]

FICS has a blind-fold mode, and it even has blind-fold accounts where this is the only mode you can use. Of course cheating with this cannot be prevented anyway; even an opponent with blindfold account can put a chess set next to his terminal. But we don't want to make it too easy by having the interface decode the moves.

When you want to play blindfold in non-blindfold FICS modes, it is no problem to get the highlights. The only way to get thick highlights currently is to set thick grid lines between the squares. Use -overrideLineGap -1 to always use the (board-size dependent) default,or specify the number of pixels you want yourself. (I think 3 is the maximum you can specify with that option, though.)

[Giorgio Medeot]

Apropos of -overridelinegap option, would it be possible to have an indipedent settings for highlighted and non-highlighted squares? Using the wooden theme, it is nicer to have the grid with -overridelinegap=1, but then the highlighted squares are no more that much... highlighted
If you think it is not that difficult, I can take a look at the code and see if I can figure out how to do it.

Thanks,

Giorgio

[H.G.Muller]

I think this would be quite difficult, as the entire XBoard algorithm of selective redrawing is based on the assumption that the highlighting does not damage the squares.

I just managed to make arrow work in XBoard. I think this is a nicer way of highlighting than fat borders that cover part of the squares. The arrow works even with -overrideLineGap 0. (It actually works better then, because that allows you to redraw only the damaged squares. But to also repair damage to the grid, a total redraw is needed all the time, which is a bit inefficient.)

Try the latest snapshot from the hgm6 branch in the hgm.nubati.net repository, with

xboard -highlightMoveWithArrow true

[Giorgio Medeot]

Ok, thanks, I understand. I think I will keep it this way (actually I'm on windows, so I already had the arrow highlighting).

Keep up the good work

Giorgio

[rigao]

It works great. The arrow looks clean and I don't need the highlight square any more.

Now, my only complain would be that xboard does not remember the position of the ICS Box. If its position can be set with options, it should work when the .ini is properly set, but right now xboard won't save its position to the ini file.

Anyway, I think that xboard is by far the best program I've tested to play in FICS (of course I realize this is a matter of taste, but anyway). Now when the 'Analyze File' is changed to its expected behavior (load an engine and annotate all the games of the file, which I read in talk chess HGM was planning to do) I will be able to delete Aquarium. Now if only xboard would have a good annotating interface, it would be perfect. But really, SCID already fills this void, so there is actually no need for this. It is even better to keep developing xboard in its actual direction (of course Aquarium is a great program, but it is not open source (not even free!), so it is very welcome for the open source projects to cover its functions, so nobody needs it to fulfill his needs).

Well, thank you very much HGM for your fast answers and your very fast coding. I can't wait till the day the xboard frontend is translated to GTK+ and we, the linux users, can enjoy xboard to its full potential.

[H.G.Muller]

Indeed the position of the ICS Input Box is not yet stored. This could be done, of course, like I do for the other windows. But there would remain a problem with window positioning in ICS mode anyway, as I have no control over or information on the X-term window position. Ideally (as long as ICS input and output are not yet in the same window) I would want to position the Input Box just below the X-term console. But I don't know how to do that.

Annotating a game with score/depth/PVs through Analyze File indeed works now. In the end I did not use the time-control settings for this, but the timeDelay of the auto-play loop (-td). I don'tknow how inconvenient this is; I can imagine you would want analysis to step more slowly than just loading a game. Perhaps in the future there should be independent settings for this. I also did not implement options to control the length of the PV yet. And perhaps it would be better to decouple loading of the file and annotating it completely, and change this menu entry to 'Analyze Game', acting on the already loaded game (starting at the current position).

About the 'annotation interface', what exactly is that supposed to do? I don't know SCID, and being mainly an engine developer and not a Chess player there are some things I just never do, and cannot even imagine.

[rigao]

The problem annotating with xboard is how it shows lines. Even though you now can have variations in xboard which won't delete the main line, when you are in one of such variations, you no longer see the main line, conversely, when you return to the main line, you lose sight of the variation.

It is not such a big deal. As I said, there are other open source software which can do exactly what I want, but as you ask... I like to have all the game annotated in front of me, as if it were a book or a magazine. I want to be able to jump between lines with a single click in the notes, and I expect the notes to format themselves so you can understand which move is an alternative to which other move in a glance. I use this option heavily when studying openings. I often pick an opening book and instead of a board, I use a computer. I try to reflect every line in a chapter to a single game, so after that, I can review the whole chapter quickly. So I rely heavily on a lot of variations, as normally every move will have 2 or 3 alternatives, and many of the sublines will branch another time.

Here is a good illustrative example of what I mean:

http://scid.sourceforge.net/screenshots/variations.png

In my experience things won't look so neat, but well, you get the idea. If you like, when I'm at home I can take a screenshot of some of those annotations to see how it really looks in my case.

Anyway, as I already said, I don't think this is such a great concern. You will always pick the best tool to get the job done, and SCID already does a good job annotating. Xboard does a better job at FICS (SCID does have the option to play in FICS, it is a lot more visual than xboard too, but I like xboard better, I feel it is far more responsive and it has premove, which is a big plus). As both are open source, there is no need to fight each other. I think it is better that each develops in different paths, so we can have more functionality when combined.

[H.G.Muller]

OK, thanks for the explanation. I was just curious how it would work. agree with the design philosophy that it is not needed to do eveything. But I like to fantasize how WinBoard could do things it cannot do now. Because some times it is supprisingly easy to implement some new functionality.

In WinBoard the move-history window is intended as the tool for the kind of navigation you want. Clicking on a move there will bring up the corresponding position in the board. But it does not list any variations or comments (except optionally the score/depth). If I would ever implement this functonality, I woulddo it in that window, by adding an option to also print variation 'comments' in the move-history window, nicelyformat them (using indents like shown), and have a click on a move in a variation first switch to that variation, and then bring up the position.

Hmm... It does not sound that difficult. But not for 4.5.0!