The Chess Variant Pages
Custom Search




[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Later Reverse Order EarlierEarliest
This item is a reference work
It belongs to categories: Orthodox chess, 
It was last modified on: 2015-11-06
 By H. G.  Muller. Interactive diagrams. Diagrams that interactively show piece moves.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2019-09-19 UTC

Currently the diagram is limited to a single locust capture. Which already makes the Lion Dog of the large Shogi variants fall beyond its capabilities. If this were solved (e.g. by allowing an array of locust-victim coordinates), the XBetza notation could specify each number of victims separately, e.g. RcdafRcdafcdafR ... Which for a big board like Taikyoku's 36x36 becomes of course very cumbersome.

Perhaps there would be some benefit of extending XBetza notation with a 'repeat count' on a group of modifiers. This would then replace the 'a' modifier. A leading '0' on the number could indicate 'exactly that many', where otherwise it would mean up to that number. So cd02fR would then mean cdafcdafR. Where the expansion rule is that the repeat count would group with preceding modality modifiers, and following directional modifiers. (So that you could still slam an initial directional modifier on the first leg, and a different modality modifier on the last one. That would allow description of the Tenjiku jumping generals as multi-hoppers: Rp14cR or Rp0cR.)


Adam DeWitt wrote on 2019-09-19 UTC

I wonder if there is a way to make a piece capture everything in its path? For example, in Taikyoku Shogi there are range-capturing pieces that destroy everything in their path (including friendly pieces). In Betza 2.0 this behavior could be indicated using cd0. Perhaps the WeirdChain function holds the answer?


H. G. Muller wrote on 2019-07-24 UTC

Oops... It seems there has been a mixup of versions at some point. This code was added as a hack to do Peace Chess, where pieces can combine to 'embracing pairs' coexisting on the same square. The IDs for these combinations are generated here automatically. Piece Chess of course only has 6 basic piece types, so for that purpose having the pair codes start at 64 located them well beyond 'nType', with a large safety margin. But I should never have used that hacked version for replacing the script that powers the diagram in general, at least not without modification. There is no reason why the 64 could not be replaced by (say) 400, to not wreck any variants with fewer than 400 piece types. (Without this hack the limit was 512 piece types; the 512 bit is used to indicate piece virginity, the 1024 bit for piece color.)

Thanks for spotting this; I will fix it soon.


Adam DeWitt wrote on 2019-07-24 UTC

Interestingly, I answered my own question. When looking at the source code, I found this line of code that was responsible for the pieces IDs being overwritten:

for(i=1; i<7; i++) for(j=1; j<7; j++) ids[64+8*i+j] = ids[i] + ids[j]; // combis

When I removed it from the source code, the problem disappeared. Honestly though, I have no idea why this line of code was in there. Logically speaking, wouldn't you want every piece to have the correct ID on it, instead of having the IDs of some pieces overwritten with something else?


Adam DeWitt wrote on 2019-07-24 UTC

I also noticed another thing about the diagram that I thought was very weird. When the diagram has at least 73 different pieces it starts combining the IDs of the first 6 pieces and replacing the actual ID of the piece with those. Specifically, it does this for the first group of 6, and then it skips two pieces. This process repeats until all 6 IDs have been used (So if the first 6 IDs are 1, 2, 3, 4, 5, and 6, the overwritten IDs would be 11, 12, 13, 14, 15, 16, 21, 22, 23, and so on all the way to 66). For example, the diagram in you page on Maka Dai Dai Shogi replaces the IDs of the Furious Fiend (+Ln), Buddhist Spirit (+DS), Teaching King (+Dv), Crown Prince (+DE), and Emperor (+K) with PP, PGB, PE, PSt, and PT, respectively. This is probably due to a bug in the source code, as I can't see any reason to think that it was intentional. However, this is only a guess. Do you have any suggestions as to what might be causing this?


H. G. Muller wrote on 2019-06-25 UTC

Could be that I did that intentionally. The universal leaper moves are generated by a piece of code that is completely different from the code that generates other moves. (As they are not relative to the start square.) And this code doesn't test for the target squares being attacked. In the Maka Dai Dai Shogi diagram the Emperor was the only royal piece, (as it was the last piece mentioned), but I did not want any royal piece, (as there is no rule against putting yourself in check there), and the fact that it is a universal leaper now hides this. But later I added commands to the diagram to set the royal piece by hand, and allow multiple or none. So this kludge is no longer needed.


Adam DeWitt wrote on 2019-06-25 UTC

Interestingly, the diagram doesn't grey out the squares that would result in moving into check when the royal piece is a Universal Leaper (XBetza notation: U), like the Emperor in Maka dai dai Shogi.


H. G. Muller wrote on 2019-02-23 UTC

The diagram is in the comments to the Xiangqi article: https://www.chessvariants.com/index/listcomments.php?id=33312 . From its page source:

        function BadZone(x, y, piece, color) { // enforce board zones
          if(touched) return 0; // not during ShowMoves()
          if(piece == 4) return (color ? y < 5 : y > 4); // Elephant: across river
          if(piece != 3 && piece != 8) return 0; // otherwise OK if not Advisor or King
          return x < 3 || x > 5 || (color ? y < 7 : y > 2) && (board[y][x] & 511) != 8;
        }
        function Shade(x, y) {
          var col = 0;
          if(y > 4) col = !col;
          if(x > 2 && x < 6 && (y < 3 || y > 6)) col= !col;
          return col;
        }

The argument 'piece' contains the type of the moved piece, and 'color' indicates its color (non-zero = 1024 = black). The routine is called for a proposed move, so board[y][x] at this point is still the victim. I suppose the exception made for allowing a King to leave his Palace to capture the other King is not really necessary when its move is defined as WfkR; King and Advisors could simply be allowed in either Palace, as they have no moves that would bring them to the opponent Palace other than the one that must capture a King.


Adam DeWitt wrote on 2019-02-23 UTC

The BadZone function is indeed very useful. For example, if you wanted forbidden moves of royal pieces into check (which are highlighted dark gray) to not show up at all, all you need to do is use this function in your script, which works with both moves that move directly into check and castling moves that land on or pass through check:

function BadZone() { return blockFlag; }

However, this function isn't elaborated on very well. It has four parameters - x, y, piece, and color. The parameters x and y can be used to track the destination square of a piece (i.e. typ = board[y][x]) but piece and color are shrouded in mystery.

You said that you used this function to "confine pieces to their zones in Xiangqi," which is very interesting and could be very useful, as I am reasonably certain that you all four parameters there, though I could be wrong. Perhaps you can show me the function that you wrote to do this?


H. G. Muller wrote on 2019-02-20 UTC

Wow, you really dived deep into this. Thanks for the feedback. The 't' in XBoard was a kludge to allow approximate representation of moves that were too difficult to handle correctly, by making it possible to 'round up' the move to something that was doable, in the sense that it would include every pseudo-legal move and then some. That way the GUI would not block the entry of any legal move because it though it was not in the piece's repertoire. And then leave it to the engine to refuse the 'and some', should the user try to play it. (XBoard protocol allows engines to do such a thing.) But this strategy fails when XBoard would think one of the 'phantom' moves was checking the King. Enforcing the checking rule makes it that you have to be exactly right in your moves: if some moves are not supported, you cannot play those, but if extra moves are supported, you sometimes cannot move other pieces because it is imagined this would leave you in check. The 't' modifier was added to make it possible to selectively disable checking by all extra moves, so the latter problem cannot occur.

But the diagram does not test for full move legality; its purpose was to demonstrate how pieces move, and not showing some of the pseudo-legal moves because of checking restrictions only caused confusion. (I later added greying out King moves that directly stumble in check, to get a good representation of slider Kings that cannot pass through check, without obscuring what the pseudo-legal moves of the King really are, to do 'Caissa Brittanica'.) So the diagram does not really need the 't', as it accepts any move anyway, and the harm in highlighting spurious moves would not go away by it. And I did not know any variant that really had pieces that could not capture royals with one of their normal capture moves. So I figured the 't' was not needed.

In case of an 'emergency', there is a work-around, BTW: the diagram script looks for the presence of a user-supplied function

BadZone(x, y, piece, color)

which allows you to veto moves that the Betza encoding would allow. I used this to confine the pieces to their zones in Xiangqi, but it could also be used to veto a move because the indicated piece type cannot capture what is at square (x,y). Or to implement variants with restrictions on what can capture what, of which the 'tame' moves are just a special case. And this does affect the highlighting! (The 'k' I added to make it possible to implement the King-facing rule of Xiangqi, which was borrowed by some western chess variants as well.)

Triple moves are indeed a pain. XBoard supports those now. It would require a lot of messy code. I don't think that 'chaining' like in Paco Shako would be the simplest way to do it. It is definitely also on my wish list.

Custom definition of royal pieces is already possible, though the parameter royal=N . In the most recent version this is even implemented as setting a flag for piece type number N, rather than remembering the value of the parameter. So you can have several such lines in the diagram definition, indicating multiple royals. But since the diagram doesn't take account of the checking rule, there is not much effect of defining something as 'royal'. Only its own moves are then sometimes greyed out. And games like Chu Shogi, which do have multiple royals when you insist on representing Prince differently from King (as kanji pieces would), doesn't really have a checking rule, so that in fact the royals should not lose any moves even when they do stumble into check. The diagram doesn't test for game end.


Adam DeWitt wrote on 2019-02-20 UTC

These diagrams are a wonderful thing. They can easily describe various moves that Game Courier can't handle without using complicated code. However, I have a few suggestions that, in my opinion, would make the diagram even better.

  • Tame pieces - The modifier t on a final (or only) leg of a move means that move cannot capture royal pieces in XBoard. In other words, it is the opposite of the modifier k on a final (or only) leg of a move, which means that move can only be used to capture royal pieces. This modifier should be relatively easy to implement.
  • Custom definition of royal pieces - Currently, the only piece that is specified as royal by the diagram is the last piece on the diagram. Some variants may have more than one kind of royal piece (i.e. Chu Shogi), which makes this a useful extension, especially if the royal pieces must stay out of check.
  • Triple Captures - This is without a doubtthe hardest extension to implement. Adding this would, in theory, require adding a lot more code to handle the second locust capture. However, this extension would be necessary for the Lion Dog, which can capture three pieces in a straight line, and other pieces that can capture three pieces at once. There might be a way to do this with the WierdChain function. However, that function hasn't been used in your diagrams other than in the Paco Shako diagram.

H. G. Muller wrote on 2017-10-11 UTC

I have now implemented the 'hover method': when you are displaying a move diagram it will show the piece on an empty board. But if you hover the mouse pointer over a marked square it puts an enemy pawn there, and shows the moves in the presence of this Pawn. This can in particular be used to elucidate hop targets (grey background), to see what kind of moves the screen enables, and locust capture squares (cyan star), to show where you have to move to make the indicated capture.

On touch-screen devices, where you cannot hover, a touch when a move diagram is being displayed will count as hovering the square, and materialize a Pawn there. Switching back to the setup diagram

[Edit]

I now implemented a method to reduce 'collisions' between moves of different type to the same square in move diagrams. For normal moves and captures the highlighting system itself already takes care of this, by defining different colors/symbols for move-or-capture, move-only, and capture-only, and also showing the latter in empty squares. But for hopping moves and locust captures there was a problem, as these moves are never really possible on an empty board, but only indicate potential moves. These potetial moves can coincide with real moves on the empty board. The potetial moves therfore now use the opposite highlighting system as the others. When normal moves are indicated by symbols, the move diagram will use background color to indicate potential hops, and both a symbol and a color to indicate locust capture. In the latter case, the symbol will only be drawn if it does not collide with another symbol, irrespective of the order in which the correspoding moves are defined in the Betza move string. This way a normal move will never be hidden by a hop or locust capture, while it will always remain visible that there is a potetial hop or locust capture over the square as well. When color is used as principal highlighting method, the potential moves will be indicated by drawing a question mark in the square.

E.g. for a Checker the locust victims coincide with normal non-captures, and in the move diagram this will be indicated by the move-only symbol, plus a background color. The user is thus warned that other move potetial is present when this square would be occupied, and can then hover over the square to 'realize' this potetial, by materializing a Pawn there, and calculating the actual move through the square for this case. If it was a locust capture, the victim would now be marked with the locust-capture symbol, and the destination square would be highlighted as a normal move. For a hop, only the destination square would be marked.


H. G. Muller wrote on 2017-10-11 UTC

I have implemeted the idea now to show potential hops in the move diagram as a separate symbol. (Currently I use the same marker as on the board is used for King moves that step into check. Which is also a case of "possible under other circumstances".) It doesn't really produce the desired effect; on the Grasshopper it is OK, but the betza1 piece was defined as an enhanced Pao, mRpcR. And because the move-only access to a square is defined by a different Betza atom as the hop possibility, the latter overwrites the former. So the information that non-captures to these squares are valid moves is lost...

This is a manifestation of a more general problem: what if the same square can be reached for different purposes? Currently only the last generated highlight survives, and I leave it to the user to decide what this should be (by writing the order of the various moves). By writing the Pao as pcRmR the potential-hop marker would be overwritten by the move-only marker. So far that didn't cause any problems in practical cases. E.g. a Rook that also jumps to the second square should be written as RD, and not as DR, so that the D jump overwrites the sliding move, and remains visible. You don't have to know that you could go to the same square through a blockable move if you can get there with a leap, after all. If you had a RmD it would be problematic, though. The capture to the second square is now blockable, the non-capture is not. There is no symbol for that combination of moves. For overlapping riders it is even more hopeless: suppose you had a Rook-Dababbarider RDD. It would show up the same as a Rook, which suggests that distant moves can be blocked on squares closer to the piece. That is true for access to the odd squares, but access to the 4th square (say) is not blocked by an obstacle on the 1st or 3rd square (because the DD leaps over those), but it would be blocked by an obstacle on the 2nd square. Having separate symbols for such weird situation is not productive, I think.

Giving the markers a black outline improves visibility on an e-ink screen. For something like the Cannon, you might separate two different markers by a slash. The slash could represent a screen, and one marker could indicate a move possible before the screen, while the other could indicate a move possible after the screen. For a Cannon's one-step move, the marker for a non-capturing move could be used by itself.

I am afraid this will get too complex to still transfer information. In general you cannot fully desribe every potential situation in a static picture. Suppose you had a piece like Mats' bifurcators, which change direction after (or before) colliding with a screen. There the number of squares you could reach if there was a screen in an undetermined position fills an entire sector of the plane, and it would be completely obscure what position a screen would need to be at to reach a particular potential target.

So I think the purpose of the markers should merely be to warn the user that something tricky is going on which would alter the picture in an unexpected way if the square was occupied. (The expected way being that it blocks the ray, and all symbols identical to it 'downstream' would just disappear.) Not to encode in detail what it is that would change. That the user can discover interactively, by indeed putting something on the marked square. He can already do that in the setup diagram, by moving pieces into a similar constellation, but a simplified possibility could even be added in the move diagram through the 'hover trick'.

That being said, it still seems bad to have a move diagram of a Pao only show non-captures without a hint of hopping, or only show hop locations without a hint it could simply move there. (A similar situation occurs in Quan Trung Chess, where there is a "grasshopping Rook locust"). So perhaps the potential to hop should not be indicated by a marker, but by a grey background color, so that it can combine with any marker, rather than erasing it. The move diagram is not checkered, so it would be the only deviating background color, so no problem on a grey-scale device. And when background color is the main method of highlighting, it could draw the grey cross marker in the hop squares.


Fergus Duniho wrote on 2017-10-11 UTC

Giving the markers a black outline improves visibility on an e-ink screen. For something like the Cannon, you might separate two different markers by a slash. The slash could represent a screen, and one marker could indicate a move possible before the screen, while the other could indicate a move possible after the screen. For a Cannon's one-step move, the marker for a non-capturing move could be used by itself.

However, something different would have to be done for a grasshopper, which could not move any distance past the screen. Perhaps a move that could be continued further could be represented by an arrow in the direction of the move, and a move that cannot be continued could be represented with an octagon, the shape of a stop sign.


H. G. Muller wrote on 2017-10-11 UTC

OK, the marker images were just a flat color, which was a bad idea. I have now given them all a black outline, and have tried to make the inner colors brighter by mixing in some white for the darker colors red and blue. This should now be recognizable against any background.

As to the betza2 moves: the problem is that this piece is defined as a Grasshopper. So it has no moves on an empty board! Which is what the diagram shows, moves of the piece on an empty board. This is very nice for ordinary leapers and sliders, because you see their complete move potential, without anything being blocked. But for hoppers, which acquire moves only because of obstacles, it is not very satisfactory. That also holds for locust capture, which is not possible without a victim being present, but there (like with ordinary captures) the ShowMoves routine at least shows the location where a victim would have to be. But you still cannot see where the piece would end up if it makes such a locust capture.

I don't have any good ideas for how to solve these problems. For sliding hoppers, rather than making the board empty, the ShowMoves function could dump some platforms in their path. But then you would never know if the hopper could have moved beyond those if they had been absent. You can of course hope that if the platform is located far enough from the piece, the suggestion that it is an infinite-range sliding hop is correct. But in the case of a Dababba that mandatorily jumps (jD), you would have to place an obstacle next to it to enable the move, and you would not be able to see or even suggest that there could also be a on-capture to that adjacent square. For locust capture, a piece could have multiple possible targets (a Checker has two), and statically indicating where the piece ends up after such a capture would not reveal which final destination belongs to which capture target. (Think of the Chu-Shogi Lion, or Ultima pieces.)

How about the following?: When displaying the move diagram of a piece on an empty board, the mouse cursor becomes a 'virtual opponent piece'. If the user hovers it over the board, the diagram would be recalculated as if there was an enemy piece on the square he is hovering over. In particular, if he hovers over a square marked as locust victim, it will show where the piece can land after taking that victim. And if the square is in the path of a hopper, it will show the moves of the hopper with a platform there. (Where capture-only destinations are indicated in red even though the board is currently empty, as it now does for divergent normal pieces.)

When pieces get too complex, i.e. their moves depend on too many conditions in other squares, it is just ot possible to illustrate it in a static diagram. This is the whole idea of providing a diagram where people can move around pieces, rather than just responding to clicking on a piece name. They can then set up situations they wonder about, e.g. for the locust capture, to see what happens if they make it. But it is true that the move diagrams makes the user aware of locust captures, while potential hops remain completely 'silent'. Perhaps there should be a marker symbol (like an inverted white triangle) in the move diagrams to indicate squares where the piece could hop over something. The Grasshopper then would show up as a Queen. Not sure how I should do it for the Pao, which has both real non-captures and potential hops for capturing on the same squares...

CSS has background properties that will let you center a background image without any tiling. For example:

STYLE="background-repeat: no-repeat; background-position: center center;"

That seems to do the trick! Thanks! This is really starting to look good now.


Fergus Duniho wrote on 2017-10-11 UTC

2) The background images are positioned differently in the cells than the content images. The latter had margins, and to prevent board raks from expanding when you moved a piece to an empty rank, the square size had to be chosen a few pixels larger than the actual piece images (e.g. 53x53 for Alfaerie, which has 50x50 gif images). The background image always starts in the upper-left corner, and the cell is then tiled with as many copies of the image as are needed to cover it completely. This means that a few pixels eear the upper and left edge get repeated near the right and bottom edge. Some pieces are so big that they have visible parts this close to the edge, and then you get ugly artifacts rear the latter edges. This can be prevented by defiing the square size exactly equal to the image size (and perhaps make the marker images a bit smaller, and center those, to prevent their margins would cause cells to expand). But all existing images do not have that.

CSS has background properties that will let you center a background image without any tiling. For example:

STYLE="background-repeat: no-repeat; background-position: center center;"

You could also use the single background property for multiple values, such as background color, background image, background repeat, and background position.


Fergus Duniho wrote on 2017-10-11 UTC

I was just checking out the XBetza Sandbox on my Kindle. Some of the markers seem faint, and in comparison with my desktop monitor, the checker includes some yellow circles that do not even show up on my Kindle. Although using different colors for the markers might work well on a color display, it would be best to make them all black on a greyscale display.

Also, the betza2 does not display any moves on my monitor or on my Kindle.


H. G. Muller wrote on 2017-10-11 UTC

OK, I made some progress. The pieces of the diagram are now displayed as background image, rather than as cell content. Highlighting can now be done through background color, or an image as cell content. For the board checkering, holes in the board, and from-square/to-square highlights it will always use color. But for the move-target highlights I now made marker images with the names of the color that otherwise is used for highlighting this type of move, like "markerFFC000.png". These will then be displayed on top of the piece images.

A few issues remain:

1) The marker images are now taken from the same directory as the piece graphics. This obviously makes it necessary to put copies of them with each piece set, which is annoying. But has the advantage they can be tailored to the piece set, e.g. to the match the size well. I guess the script could be made smart enough to take them from dedicated directories, switching between them depending on the defined square size.

2) The background images are positioned differently in the cells than the content images. The latter had margins, and to prevent board raks from expanding when you moved a piece to an empty rank, the square size had to be chosen a few pixels larger than the actual piece images (e.g. 53x53 for Alfaerie, which has 50x50 gif images). The background image always starts in the upper-left corner, and the cell is then tiled with as many copies of the image as are needed to cover it completely. This means that a few pixels eear the upper and left edge get repeated near the right and bottom edge. Some pieces are so big that they have visible parts this close to the edge, and then you get ugly artifacts rear the latter edges. This can be prevented by defiing the square size exactly equal to the image size (and perhaps make the marker images a bit smaller, and center those, to prevent their margins would cause cells to expand). But all existing images do not have that.

3) On a color display I like highlighting with background colors better. (I think it is more visible. But perhaps this is because I am now used to this.) With grey scales the colors are a disaster, though. So I am probably going to force marker highlighting automatically on displays with a colorDepth <= 16. For other displays it is now subject to a new diagram parameter useMarkers=1. I set this parameter for now in the two most-recently posted diagrama, the comments to the "Betza notation" and "Wildebeest Chess" articles, so people can judge them. For now useMarkers=1 can only be used with the xboard33 piece set (graphicsDir=/membergraphics/MSelven-chess/), as this is the only place where I uploaded marker images so far.

Please let me know if the new rendering method gives any problems on other browsers, and what you think of the current set of markers on color or grey-scale displays.


Nicolino Will wrote on 2017-10-11 UTC

Didn't the leap color used to be more orange? Now it is almost impossible to distuingish from a slide.


Fergus Duniho wrote on 2017-10-11 UTC

That worked after I fixed the addcomment.php script.


Fergus Duniho wrote on 2017-10-11 UTC

P.S.: the submission form just tried to trash this comment, by complaining that I must be signed in after I pressed submit buttom in the preview screen. Fortunately I had guarded against that this time, but this is very, very bad! Especially since it tends to happen after you worked on a comment for a very long time...

This happened to me earlier today. Let's see if I can catch it. I will logout in another tab while writing this.


H. G. Muller wrote on 2017-10-10 UTC

On my desktop, it reads #0000FF.

That is the brightest pure blue you can get. I guess lowering the saturation could make it lighter. (But the it would be more like the others...) This color is only used for capturing own pieces (and so far I have never had to use that).

Yeah, colors are not ideal on grey-scale devices. Although my e-reader says it has 16 bit color depth, the grey shads 0xFFFFFF and 0xF0F0F0 were absolutely the same. So it is more like it has only 16 shades of grey! Main purpose of this exercise was to at least show where a piece can go at all, and prevent complete masking of it by the board checkering.

The one difficulty is that you might not be able to superimpose a marker on top of a piece.

Indeed, this is exactly what stopped me from doing this so far. before the "interactive diagram" I had "moves at a glance" images, which were just for showing hard-coded moves in a fixed position. I did highlight those with images (of colored dots, which would defeat the current purpose, but of course that ca be trivially changed), and the markers there obliterated the pieces on the square (which I worked around by having the capture marker bring its own black Rook with it).

The way I got around this in Game Courier was to mark spaces with a border around a piece or space. This worked by changing the CSS for the piece, and it worked on empty spaces by using a small, resizable, transparent gif as the piece image on empty spaces. Another possibility, which I haven't tried out, would be to give each space a background image instead of a background color and to change this accordingly.

I only became aware recently that you can have background images. This solution seems technically the best. There could for instance be various patterns of dotting or (cross)hatching. Note that the color system is rather 'luxurious'; because so many colors were available I made distinctions that were not strictly necessary. E.g. empty squares and occupied squares could use the same markers in other meaning; it would not be too illogical to give locust capture and slider non-captures the same markings, as both are moves after which the piece can continue. Also distinguishing capture of own or enemy pieces need not be distinguished: you can see which color piece you will capture.

Another problem is that images of some pieces could be large, not leaving much free space in the square to recognize a background shape. Perhaps it should be done the other way around, using the piece images as background!? Then the highlights would cover the pieces, and could all be small circles / squares / triagles / stars with transparency around them. That sounds exactly like what is needed.

Disadvantage is that piece graphics of different sizes might need different sets of marker images. Although I suppose that when we center the marker images, the can be suitable for a range of sizes. I mostly use 50x50 for large diagrams (Alfaerie or XBoard50), and 33x33 for smaller ones (Utrecht or XBoard33). But currently the diagram can be used for any size, and it would be a pity to lose that property.

Whatever you use, it would be helpful to include a legend that will tell people what the different colors or markers mean.

Well, on grey scales this is just beyond what color highlightig can do, even with a legend. But with shaped markers that is of course different. My feelings about legends are a bit double. For the experienced user their presence can easily turn into an annoyance. They can be made collapsable, but they should not be hidden too well, or novice users would never fid them. Further more, opening them should not push other valuable stuff out of view, or make the elements the user is acting on jump to other places.

Do you have a suggestion where best to position such a legend relative to the diagram?

If you're turning Betza codes into diagrams, would it also be possible to translate these codes into written descriptions that could appear underneath a diagram?

Interesting idea. For the trivial cases, like BN, this would of course be easy ("Moves as Bishop or Knight"). For the Chu-Shogi Lion it would be a challenge, and what it produces might not be very good. (KNADcaKmcabK: "Moves and captures like King, Knight, Alfil or Dabbaba, or captures as King and then again as King in any direction, or passes a turn"). It also depends on how you far you wat to go explaining things. Is "Moves as Alfil or Dababba" acceptable, or must it say "Makes a (0,2) or a (2,2) jump in every direction"?

P.S.: the submission form just tried to trash this comment, by complaining that I must be signed in after I pressed submit buttom in the preview screen. Fortunately I had guarded against that this time, but this is very, very bad! Especially since it tends to happen after you worked on a comment for a very long time...


Fergus Duniho wrote on 2017-10-10 UTC

Looking at your list of colors on my Kindle, #E8E8E8 and #FFFF00 are hard to distinguish from each other, and #E0E0E0,  #F0F000, #FFE000, and #00FFFF are also hard to distinguish from each other. There is very little difference between these and #D0D000. Lastly, #00B000, #FF0000, and #505050 look virtually the same. The most distinct color on the list is so dark I can barely read it on my Kindle. On my desktop, it reads #0000FF.

What I had in mind was switching from the use of colors to using some kind of image or images. I figure if you can put a piece on any space, you could also put a marker on a space. By having different shapes, image markers could remain more distinct on a greyscale screen. The one difficulty is that you might not be able to superimpose a marker on top of a piece. The way I got around this in Game Courier was to mark spaces with a border around a piece or space. This worked by changing the CSS for the piece, and it worked on empty spaces by using a small, resizable, transparent gif as the piece image on empty spaces. Another possibility, which I haven't tried out, would be to give each space a background image instead of a background color and to change this accordingly.

Whatever you use, it would be helpful to include a legend that will tell people what the different colors or markers mean. You may know what they mean, but the average visitor who comes across one of these diagrams will not. For example, I just looked at diagrams for the Rook and the Cannon in Metamachy, and the only difference between them is that one used a lighter shade of grey than the other. If you're turning Betza codes into diagrams, would it also be possible to translate these codes into written descriptions that could appear underneath a diagram?


H. G. Muller wrote on 2017-10-10 UTC

Indeed, this is no good. Part of this is Nicolino's fault, by using too dark shades for the normal board checkering; it seems his light shade is already as dark as what I use (and is default) for dark squares. But especially yellow, used to highlight non-captures, is too bright to show up well in grey scales. I guess color coding is not an ideal method on grey-scale devices, unless you are very careful in selecting the colors.

It seems to be difficult to detect if you are running on a grey-scale device from JavaScript. My e-reader still reports screen.colorDepth 16, as opposed to my laptop, which reports 24. Perhaps I should have the diagram use a darker shade of yellow (or perhaps of every color) when running with colorDepth <= 16, assuming most color displays nowadays have at least 24-bit 'true colors'.

[Edit] I have now modified the script to detect colorDepth (after the initial rendering), and adjust the square shades to pure white and very light grey if this is <= 16, irrespective of what the user defined. A darker shade of yellow is then used for 'move or capture' highlights. Ufortuately I don't know how to test if this is satisfactory; I have an old and cheap model Kobo e-reader, it has a browser, but I do not know how to flush its cache. So it keeps using on the old, cached script...

  • #FFFFFF: Light squares
  • #E8E8E8: Dark squares (grey scale)
  • #E0E0E0: Dark squares (default)
  • #FFFF00: Move or capture (color)
  • #F0F000: Move or capture (grey scale)
  • #FFE000: Jump move or capture
  • #D0D000: Initial move or capture
  • #00F000: Move only
  • #00B000: Initial move only
  • #00FFFF: Locust capture (destination click to follow)
  • #FF0000: Capture (only)
  • #0000FF: Capture own piece
  • #505050: Forbidden King move

It does help a bit that some colors will only be used on empty squares, others only on occupied square. The move-only and move-or-capture colors will only be used on empty squares. While playing on the diagram (locust) capture will only occur on occupied squares. Unfortunately in the move diagrams capture is also indicated on empty squares; perhaps I should switch to displaying a dummy black piece on the target squares in that case.

[Edit] What also helps is to not use checkering of the board at all when displaying a move diagram. I guess there is no need at all for checkering in that case; the checkering is only useful when you are playing, and want to know if a distant diagonal mover now hits one of your pieces. In a move diagram diagonal moves are highlighted themselves.

Another trick I learned: I can safely use floating style for a diagram in a comment, when I put the whole comment inside a 1x1 table. Then it will ever stick out into the comment below it, not even if you open the legend below the diagram. I tried this in the Wildebeest diagram; I needed the floating style to be able to get the pieceList and board in the same view, so that I could touch the pieces in the list and see their diagram appear, as my e-reader as a portrait-shaped screen, and the diagram and list would not fit side by side.


Fergus Duniho wrote on 2017-10-09 UTC

I frequently access this site with my Kindle Touch's browser, and I have noticed that using a different color to mark which spaces a piece may move to is not very effective on an e-ink device. To illustrate, here is a grayscaled screenshot of an interactive diagram showing how a Queen moves in Chess and a Half.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.