Comments/Ratings for a Single Item

@Fergus: sorry to complain again, but, well, something seems to have change. When playing on Game Courrier I wanted to scroll some moves back and it doesn't work anymore.

I get this message:

"Since the png rendering method draws the entire diagram as a single image, you cannot view other positions without reloading the page. But if you change your rendering method to Table or CSS, you should be able to."

Why people skilled in IS always think that it is easy for anyone else? How may I change my rendering method? I don't even know what is it.

This is a pain.

There is a dropdown to select the rendering method on the page where you can edit the preset.

Thanks but I still don't understand. What is a dropdown? Why should I have to edit anything whereas it was working fine up to now?

Under the Comments box on the game page you should see Appearance Controls. If you click that it will expand to show more options, including Render as: which you need to set to CSS or Table. After you change the settings, you have to use the Preview button that you use to enter moves to update the game display.

Click on the Appearance controls, then go where it says "Render as:", change the rendering method to either Table or CSS, and then click Preview.

I'm probably stupid. Nowhere on my screen there is "Appearance controls". I see a box with "Render as". There I change PNG to CSS or Table. And then? I see nowhere "Preview". I see "View", "Print" and "Annotate". In any case, even with CSS or Table, when I scroll the table, the diagram remains the same, I can't see past moves without pressing "view", no interactive moves like for the other games. Maybe it's impossible.

A pulldown is a display element you can click to make a short menu appear below it, from which you can then select an option.

The one you need is labeled "Render as:", third from below on the left in the large greenish block. It doesn't seem to do anything, though.

There also is one in in the Edit page you get at by pressing the 'Menu' button, and selecting 'Edit' there:

This one worked for me if I press "Test" at the top of the page to get back to the Menu page, and then press Play there.

CSS rendering looks pretty ugly, though: all occupied squares get (1px wide black) borders, the rest of the board not.

The one you need is labeled "Render as:", third from below on the left in the large greenish block. It doesn't seem to do anything, though.

It will not do anything right away, but it should change when you submit the form. The one exception to this is when you are viewing a game where you are a player, because your preferences in the log will override what you entered in the form. I should fix it so that preferences in the log are more easily overridden. [BUG FIXED]

CSS rendering looks pretty ugly, though: all occupied squares get (1px wide black) borders, the rest of the board not.

That should not be happening, and I have not seen it. Where are you seeing this behavior?

Nowhere on my screen there is "Appearance controls". I see a box with "Render as".

I assumed you were playing the game against someone else, and I based my instructions on the form you get when it is your turn to move. If you don't see "Appearance Controls", but you do see "Render as:", then you can go directly to the latter. The "Preview" button is only for playing a game. If you're just viewing a game, you submit the form with the "View" button.

I can't see past moves without pressing "view", no interactive moves like for the other games.

To traverse through all the moves in a game with JavaScript, you first need to view the last move of the game in this manner. Also, if this is a game you were a player in, there is currently a bug that will stop you from changing the rendering method in View mode from the preference you have stored in the log. [BUG FIXED]

That should not be happening, and I have not seen it. Where are you seeing this behavior?

I tried this preset from the log page, clicked Menu, then Edit, changed the "Render as" to CSS code, and finally pressed Test. That gave me this:

In your example, the black outlines were also appearing around the pieces in the Captured Pieces section, and this uses the same code no matter what the rendering method for the board. So, it's not the CSS rendering method that's at fault. This black outline is happening because the CSS rendering method is displaying them with the showpiece.php script, and the pieces in question are not in the proper format to work with this script. The pieces in use here are from the alfaeriePNG directory. The reason they are being displayed with showpiece.php is because they are 48x48 instead of the expected 50x50. So that smaller images do not get disproportionately enlarged by a background-size of contain, it runs smaller images through showpiece.php to pad them. However, the image I tested turned out to be a truecolor image, and the transparent color used was black (#000000) instead of green (#00ff00). Because of this, it could not determine and keep track of the transparent color, and instead of coloring the padded border with the transparent color, it colored it an opaque black. To fix this, there are three changes you can make to these images.

1. Make the images 50x50 instead of 48x48. This will stop the need to pad these images when the squares are 50x50.
2. Make them palette images, not truecolor images. Even with the image I tested, it had only 141 colors, which is within the capacity of a palette image. So, there was no reason to make it truecolor.
3. Make the transparent color pure green. This is a convention adopted from Zillions-of-Games, which provides a means to detect the transparent color when other means are not working.

[UPDATE]I added some fallback methods for getting the transparent color, and now the pieces show up without the black border. However, there is an issue with the cross on the king. So, I still recommend modifying the pieces to work better with this script or to even not need it in this circumstance.[/UPDATE]

Make the images 50x50 instead of 48x48. This will stop the need to pad these images when the squares are 50x50.

I think this would be the proper solution. Most Alfaerie images are 50x50; I have no idea how some (mainly of the orthodox pieces) came to be 48x48 or 49x49. I wouldn't know how to make a palette PNG image; I usually geenrate the AlfaeriePNG images with fen2.php from SVG images, and fen2.php is based on C code I took from XBoard, which uses a function to safe a bitmap as PNG file, described as a 'toy interface' that offers little or no control of the image properties. (But it works.)

When I have time I will re-render these pieces at the proper size.

I have no idea how some (mainly of the orthodox pieces) came to be 48x48 or 49x49.

The original Alfaerie pieces were 49x49, because David Howe originally made them for Zillions-of-Games, whose boards were using 49x49 squares. While I made pieces whose dimensions matched the dimensions of the visible image, he made pieces of uniform dimensions that perfectly fit the spaces they were intended for.

It appears almost all alfaerie GIF images are 50x50. Some (including the orthodox pieces) are 49x49. Elephants and their derivatives are even 53x50. I recall that I had once seen a 48x48 GIF too, but forgot which that was.

Almost all PNG images are 48x48, though. Only a few that I recently made (mostly compounds done by fen2.php) are 50x50. I produced many of the SVG from which these are derived, but I think Greg had a script that he used to 'bulk convert' the SVG to PNG. He must have used 48x48 in this script. Why he picked that size is unclear to me, as amongst the GIF images it is virtually non-existent.

I think it is undesirable that GIF and PNG images have different sizes. It should be our long-term goal to upgrade all images to the (anti-aliased) PNG, and having different sizes would obstruct that.

So what to do? Should I try to re-render all the alfaeriePNG at 50x50? I suppose I could make my own script for that, at least for everything that we have as SVG, and not compound or post-edited (to apply crosses and such)..

Almost all PNG images are 48x48, though. Only a few that I recently made (mostly compounds done by fen2.php) are 50x50. I produced many of the SVG from which these are derived, but I think Greg had a script that he used to 'bulk convert' the SVG to PNG. He must have used 48x48 in this script. Why he picked that size is unclear to me, as amongst the GIF images it is virtually non-existent.

Maybe he was considering that Game Courier highlights spaces with image borders and wanted to leave some space for the border. However, the borders used are larger than one pixel in width, and the Square Table method will now keep borders from growing too large by reducing the dimensions of the image, whereas the CSS method puts borders around an empty space of a fixed size. So, even if making the images smaller than 50x50 once had some utility, it no longer does.

Should I try to re-render all the alfaeriePNG at 50x50? I suppose I could make my own script for that, at least for everything that we have as SVG, and not compound or post-edited (to apply crosses and such).

Since Game Courier is able to copy an SVG to a GD image that will be saved as a PNG, I should be able to modify showpiece.php for conversion from SVG to PNG. Then I could make sure that the PNG is also a palette image with green for the transparent color.

Since Game Courier is able to copy an SVG to a GD image that will be saved as a PNG, I should be able to modify showpiece.php for conversion from SVG to PNG.

Since I already have a PHP function called imagecreatefromimagick2, the conversion from SVG to PNG was easily handled. However, the results I'm getting do not appear as smooth as the results Greg got.

Here are some examples of what I am getting:

And here are the same pieces as Greg has already converted them:

I have been altering imagecreatefromimagick2 to try to get better results, but so far nothing has worked.

I have rendered all images in the alferieSVG directory now as 50x50 PNG using fen2.php?s=50&p=..., in the directory /graphics.dir/alfaeriePNG50. They look like this

(The shell script I used for this is /graphics.dir/alfaeriePNG50/x, and then y to give them the desired filename.)

I think the trick to making them appear smooth is having edge pixels with varying alpha values. The images I produced had fully opaque edge pixels. As a test, I made a palette version of bknight.png in Ultimate Paint. When I loaded the palette version, the edge pixels no longer had varying alpha values. As a second test, I saved a 24 bit true color version, and it also had lost the varying alpha values on edge pixels. Finally, I saved a 32 bit true color version, and when I reloaded it, it retained the varying alpha values. I also tried the latest version of Paint.net. When I selected the option to save it with an 8-bit depth, it offered the option to set the Transparency threshold, and it said "Pixels with an alpha value lower than the threshold will be fully transparent." So, I'm thinking that having varying alpha values is available only in true color images, and that provides a reason for keeping these as true color images.

So, I'm thinking that having varying alpha values is available only in true color images, and that provides a reason for keeping these as true color images.

I am not really into these graphics formats, but I can imagine that the palette for historic reasons contains only up to 256 24-bit colors (i.e. RGB without alpha). I guess that with an alpha channel the number of different RGBA combinations in a typical image becomes so large that 256 would almost never be enough, so that no one bothered to define a standard for palette with alpha channel.

Could you add the missing bnespearman to alfaeriePNG?

Could you add the missing bnespearman to alfaeriePNG?

OK, done.

It is strange. I was looking for some recent games I was playing and that are not shown anymore in the table of my going games. It appears that they have been finished by time limit. One that I won.

Hmm, strange, in all games I played we always had few days of remaining time. Something has happened I think.

My regrets for my opponent (Richard Milner), this was not intentional.

The log:

timurthelenk-cvgameroom-2024-40-404

I found only one game of yours that ended in the past week, and it ended in checkmate. Were the other games private? Or did they end over a week ago?

There is only 1 game, not 2. I have modified my comment.

(The 2nd game I have removed was in fact that game interrupted by HG's mistake. That log stayed as a drawn after your attempt to restaure it (but it was impossible to re-start it), and for a reason I ignore, it turned as a victory for Paul "on time". As we had re-started this game from the beginning, I have erased that first log.)

So, the suspect game that has been finished "on time" is a game of Macrochess that I would have won against Richard Milner of time, which is strange because we were playing several moves a day.

@ H.G.:

In the following link to a Butterfly Chess log, I tried to move my White Advancer from e1 to j6. The (Applet generated) preset allows the move, but does not announce check. Is there a bug here?

https://www.chessvariants.com/play/pbm/play.php?game=Butterfly+Chess&log=panther-joejoyce-2024-10-868

@ H.G. Muller:

Have you seen my comment to you that I am replying to? Not too much of a rush, if you're busy or stumped.

Yes, I had seen it, but had no time to look into it yet.

Quickly glancing at the code in betza.txt suggests that it would never say 'check'; searching for "say Check" only finds "say Checkmate" where it terminates a game, as one of the possible reasons for termination. So I would be surprised if you had ever seen it say 'check'.

Is it supposed to say 'check'?

@ H.G.:

Yes, I originally would have thought when an Advancer made a move that threatened a King, an enforcing preset would automatically announce check.

However, maybe the Advancer, being an Ultima-like piece, does not actually make a check in an Ultima-like game (which Butterfly Chess is not)? So I now ask, is that the usual assumption that Applet generated preset code makes for every CV put through the generating process? If so, maybe an option can be added to the Applet to ask if Ultima-like pieces should announce check.

A problem for Butterfly Chess, anyway, is that if check is not announced for Advancers, what happens if the opponent's next move leaves his king vulnerable to capture by the Advancer. Does the preset announce the opponent made an illegal move (my much preferred choice, implicit in Butterfly Chess rules), or can the king be captured (if so, is a win announced, or does a player type in 'won' after his K-capturing Advancer move is manually entered, or does he tell his opponent to make a legal move instead)?

Yes, I originally would have thought when an Advancer made a move that threatened a King, an enforcing preset would automatically announce check.

However, maybe the Advancer, being an Ultima-like piece, does not actually make a check in an Ultima-like game (which Butterfly Chess is not)?

So I now ask, is that the usual assumption that Applet generated preset code makes for every CV put through the generating process?

I don't know how a generated preset works, but the checked subroutine I use in the fairychess include file normally checks for captures by displacement by checking if each enemy piece on the board can move to the King's position. This would not normally work with Ultima pieces, which do not normally capture by displacement, but I have managed to use this subroutine with Ultima without modifying it. First, let's look at the subroutine:

sub checked king:
    my from piece;
    local movetype;

    set movetype CHECK;
    if isupper cond empty var king $moved space var king:
        def enemies onlylower;
    else:
        def enemies onlyupper;
    endif;
    for (from piece) fn enemies:
        if fn const alias #piece #from var king:
            return #from;
        endif;
    next;
    return false;
endsub;

The key to working with Ultima is that it sets movetype to CHECK. With this in mind, I have written functions for Ultima pieces like this:

def Black_Withdrawer fn join "Black_Withdrawer_" var movetype #0 #1;

Depending upon the value of movetype, it will call either Black_Withdrawer_MOVE or Black_Withdrawer_CHECK, which I have defined separately and differently. Thanks to setting movetype to CHECK, the checked subroutine will use the *_CHECK functions for Ultima pieces. Instead of going through a normal move, one of these functions will check whether the piece at the first coordinate can capture the piece at the second. For example:

def Black_Withdrawer_CHECK 
empty where #frm - file #frm file #to - rank #frm rank #to
and == distance #frm #to 1
and not near #frm I 1
=frm =to;

This first makes sure that the piece is not next to a White Immobilizer (designated as I). It then verifies that the two spaces are adjacent. Calculating the direction away from the piece at #to, it checks whether there is an adjacent empty space in that direction. If there is, it returns true.

You did not get the point. Does the preset say 'check' when you check with any other piece than an Advancer? I think it doesn't. So then this has nothing to do with the piece being an Advancer.

By default the preset would apply the checking rule, so moves that leave your royal exposed will be refused. To switch that off (for variants where King capture is a goal) you would have to add an extra line on GAME code to the Pre-Game section. (As the Interactive Diagram does not distinguish thuse cases, but simply allows you to play on in checkmated positions.) The preset enforces the rules. It does not generate conversation during the game.

You did not get the point. Does the preset say 'check' when you check with any other piece than an Advancer? I think it doesn't. So then this has nothing to do with the piece being an Advancer.

I dug back into this thread to find the preset he was talking about. He linked to a particular game in which neither Advancer checked the opponent's King. Continuing this game by choosing Annotate and then Move, I played some moves to get a White Flying Dragon to check the Black King, and when I did, it said "check!". After moving the King out of check, I tried to move White's Advancer, but no legal moves are being highlighted on the board for it. However, its legal moves do show up in the Moves field, and when I tried one, it worked. At the top of the Moves field, I see the legal move "A e1-#to; A #to-b1". I think this is not a properly formatted move, and it may be interfering with the ability to recognize the Advancer's legal moves. Also, when I entered it, it did not recognize it as legal, and it gave the error message "#to is not a valid square".

Here are the moves to the position in question so that you can see what's going on.

1. P f2-f5 
1... p f9-f6 
2. P e2-e4 
2... p e9-e7 
3. F i1-h3 
3... f i10-h8 
4. P i2-i3 
4... p d9-d8 
5. B h1-i2 
5... c g10-f7 
6. C d1-f3 
6... f b10-c8 
7. C g1-e3 
7... c d10-f8 
8. K f1-i1 
8... p g9-g7 
9. P b2-b3 
9... c f8-e5 
10. P d2-d4 
10... c e5-f8 
11. B c1-b2 
11... a e10-h7 
12. F b1-e2 
12... p i9-i8 
13. P g2-g5 
13... c f7-e8 
14. P g5-g6 
14... a h7-f9 
15. P c2-c4 
15... p b9-b6 
16. F h3-g2 
16... c e8-d7 
17. P d4-d5 
17... f c8-d6 
18. F e2-h3 
18... p c9-c7 
19. C f3-e6 
19... c d7-e6 
20. P d5-e6 
20... p j9-j8 
21. B b2-a3 
21... b c10-a8 
22. B a3-d6 
22... p e7-d6 
23. R h1-f1 
23... p j8-j7 
24. F g2-d3 
24... b h10-j8 
25. C e3-g1 
25... f h8-i6 
26. P j2-j3 
26... p d8-d7 
27. P a2-a5 
27... p b6-a5 
28. R a1-a5 
28... b a8-b9 
29. P e6-d7 
29... f9-e8;@-d7 
30. C g1-a7 
30... f i6-h4 
31. C a7-d8 // - check! -
31... k f10-f9

Just click on Annotate for Butterfly Chess and paste these in to see the same position.

OK, I see. The betza.txt code actually does say 'check'. Problem was that by searching for 'say check' I did not find that, because there are quotes around the word 'check'.

It appears that it would only ever say 'check!' when the preset is using the accelerated method for testing legality of highlighted moves. This is the default method, because it is faster. But it is not entirely reliable. The reliable method would try out all pseudo-legal moves, and then generate opponent moves in each of the resulting positions, to see if any of those captures the King. All opponent moves will have to be tried to conclude the move is legal (which usually is the case), and on a large variant this can take very long (to the point where GC aborts the GAME-code execution). And in that branch of teh code it would never say 'check!'.

In the accelerated test it would generate the opponent moves not after the move that has to be tested for legality, but before it. (Meaning that it has to do it only once.) If any of those hit the King, the move that was just made apparently delivers check. After a move considered for highlighting it then only retries such an existing checking move, to see if the check was resolved, and all moves that hit squares mutated by the move-to-be-highlighted (which could have been discovered, and now hit the King). That is a huge time saver.

Where it goes wrong is that during this accelerated check test it actually removes the King, and tests whether it was in check by testing whether a move that hits the square it was on is capture capable. This to avoid a slider check is blocked by the King, making the square behind it to be safe to move to. King moves can then be tested for legality simply by testing whether their destination was marked as attacked. But this procedure does not mark squares that are attacked by locust capture. Such as an Advancer does.

The reliable method would try out all pseudo-legal moves, and then generate opponent moves in each of the resulting positions, to see if any of those captures the King. All opponent moves will have to be tried to conclude the move is legal (which usually is the case), and on a large variant this can take very long (to the point where GC aborts the GAME-code execution).

Thanks to GAME Code being an interpreted language written in another interpreted language, it is not as quick at things compiled languages would do more quickly, and it will sometimes exceed the time limit that PHP imposes on script execution. This makes optimizations and short cuts more important, and in hand-written code, I have done this. See my previous comment about how I handled the spotting of check in Ultima as an example.

In automatically-generated code, it might be harder to get in the optimizations needed for particular games. So I would suggest a compromise between your quick method and your reliable method. Flag pieces that can capture a piece without moving to its space, and use your reliable method on these while just checking if other pieces can move to the King's space.

So I would suggest a compromise between your quick method and your reliable method. Flag pieces that can capture a piece without moving to its space, and use your reliable method on these while just checking if other pieces can move to the King's space.

I think I managed to even use some acceleration for the pieces that can perform 'locust capture', by avoiding you have to generate all their moves, and just limit it to moves that could potentially hit the King. This would be the move that already delivers check, and the moves that that mutate a square along the path in a way that would allow a slider leg of the locust capture to pass. Which is what was already done for direct captures too.

The issue was that the test for being already in check was done with the King taken off the board, by comparing the destination of capture-capable moves with the King square. But this was tested only on a final leg, and not for a non-final leg, where the capture would be a locust capture, and the piece would move on after it. I now compare the (temporary evacuated) locust square with the king position too, and if it matches make the move go over to the next leg to see if it can be completed. (For an Advancer that would always be possible, but a Long Leaper it might not be.) If the move can be completed, the locust square would be marked as attacked. This will then make the 'check' message appear.

But more importantly, squares on the second leg would also get marked as squares where a check could be discoved. This was a bug that did not yet express itself. A Checker diagonally adjacent to the enemy King would not deliver check if a friendly piece was immediately behind that King, blocking the landing square. But that blocking piece would then essentially be pinned, and its moves should not be highlighted. The accelerated test would only have noticed that if the second leg of the Checker capture would have added that Checker capture to the moves affected by mutation (= evacuation) of that landing square.

The issue was that the test for being already in check was done with the King taken off the board

Why would you take the King off the board for this? Couldn't this cause false positives and false negatives from divergent pieces like Pawns or Cannons?

This was a bug that did not yet express itself. A Checker diagonally adjacent to the enemy King would not deliver check if a friendly piece was immediately behind that King, blocking the landing square. But that blocking piece would then essentially be pinned, and its moves should not be highlighted.

The code I use avoids this by trying each pseudo-legal move and checking whether any piece in the new position is checking the King.

Why would you take the King off the board for this?

The purpose of the accelerated check test is not only to determine whether the King is in check in the current position, but also to greatly facilitate testing whether the King would get exposed by any of the moves. One contribution to this is to mark every square where the King itself cannot go. The King is taken off to prevent it would block enemy slider moves (or lame leaps), creating the illusion that it would be safe to "step into his own shadow".

The test is NOT done by only processing all pseudo-legal moves. Because that would not reveal which pieces are protected (and thus cannot be captured by the King). For the purpose of knowing where the King could go the move generator should basically work under the fiction that all destinations contain the enemy King. That applies to empty squares as well friendly pieces; these will be marked as inaccessible to the King when the move hitting those is a move that can capture. Even when it cannot capture what is actually there.

The code I use avoids this by trying each pseudo-legal move and checking whether any piece in the new position is checking the King.

That would indeed be an alternative: do a full king-capture test after every King move. But it would be more expensive, as a King usually has several moves. So you would have to do enemy move generation several times. (And who knows how mobile a royal piece can be, in a chess variant?) Testing whether a destination contains the King is not any more expensive than marking the destination. And to do it, you only need to geenrate all enemy moves once. Then for each King moves only have to test whether the destination is marked. And to know whether you are in check it would just have to test whether the square the King is currently on is marked.

But the fiction that every square where you are allowed to capture contains a King should also be applied to locust captures. And this wasn't done.

The accelerated check test would not work in variants where there are multiple absolute royals. (Extinction royaly is no problem; there it just skips the check test completely if there still is more than one royal.)

That would indeed be an alternative: do a full king-capture test after every King move. But it would be more expensive, as a King usually has several moves.

It's more than that. I do a full king-capture test for every pseudo-legal move by every piece that can move. My code works like this.

1. It goes through every piece from the side that can move.
2. For each piece on the side that can move, it calculates the spaces within its range of movement. This is an optimization to keep it from checking for legal moves to every position on the board.
3. For each space within a piece's range of movement, it checks whether the piece has a pseudo-legal move there.
4. For each pseudo-legal move, it tries the position and checks whether it places the King in check.
5. It checks whether the King is in check by checking whether any enemy piece can move to the King's space. As an optimization, it returns true as soon as it finds one check.
6. It checks whether a piece may move to the King's space by calling its function for the move from its location to the King's space.
7. Divergent pieces are handled by writing them to behave differently when the movetype variable is set to CHECK. In the following example, the function for the White_Pawn first checks some conditions any Pawn move must meet, then handles capturing, then continues to handle non-capturing and en passant moves only if movetype is not CHECK.

def White_Pawn
remove var ep
and < rankname #1 var bpr
and < rankname var ep rankname #1
and == filename var ep filename #1
and checkleap #0 #1 1 1
and var ep
or and checkride #0 #1 0 1 == rankname #0 var wpr
or checkleap #0 #1 0 1
and empty #1
and != var movetype CHECK
or and islower space #1 checkleap #0 #1 1 1
and any onboard where #1 0 1 == var movetype CHECK count var wprom
and <= distance #0 #1 var fps
and > rank #1 rank #0;

8. Pieces with non-displacement captures are handled by writing two different functions for them and using the value of movetype to call the correct function.

So you would have to do enemy move generation several times.

Since my code uses piece functions, this is not a big problem. In tests I ran yesterday, my checked function ran 1000 times in under half a second, and the checked subroutine got called 1000 times in close to a second, and this was on a position in which the King was not in check, which meant it never broke out early. Since your code does not use piece functions, it may handle the evaluation of moves more slowly, which will also cause it to evaluate check more slowly.

Testing whether a destination contains the King is not any more expensive than marking the destination. And to do it, you only need to geenrate all enemy moves once.

This optimization might be helpful when not using piece functions, but one thing about it concerns me. While it might be helpful in determining whether a move by the King would be into check, I'm not sure it will work for revealed checks. It is because of the possibility of revealed checks that my code checks for check for the position resulting from every single pseudo-legal move it finds.

I suppose one optimization that could be made if it were needed would be to identify the pieces that might possibly check the King at its current location, then limit the test for whether a move by another piece places the King in check to those pieces. This could be done by making a short list of every enemy piece whose range of movement contains the King's location and having the checked function use it instead of onlyupper or onlylower. If this list were empty, it could even skip the step of trying out a pseudo-legal move and testing whether it places the King in check.

However, this might not work for non-displacement captures in which the capture occurs outside the piece's range of movement, such as the Coordinator capture in Ultima. So, I have to balance efficiency with the work a programmer has to make to use a piece in a game. The brute force method I use helps reduce the work the programmer has to do to make different kinds of pieces work with it.

5. It checks whether the King is in check by checking whether any enemy piece can move to the King's space. As an optimization, it returns true as soon as it finds one check.

The efficiency of your algorithm depends on whether there is a fast method to answer the question "does the piece at square A attack square B", which then can be combined to a function "IsSquareAttacked" by looping over all pieces A. But for complex multi-leg moves (pieces that turn corners, or jump over others, or do not end their move at the square they attack) it is hard to find a shortcut even if you are writing dedicated code for it. Often the best way is to just generate all moves of the piece at A, and for each of those test if it happens to hit B. For simple sliders and leapers it would be possible to immediately exclude they are attacking B based on the (x,y) coordinates of the leap from B to A (e.g. x*y!=0 for a Rook), or even tabulate in which direction you would have to move to arrive at B (and then test whether this path is unobstructed).

I could of course classify pieces (or even their individual moves) as simple or complex, and use a fast "does A attack B" function for leaps and straight slides, and only generate the complex moves of all enemy pieces to test whether these hit B. Typically only a small fraction of the pieces will have complex moves, and then this could be competitive.

This optimization might be helpful when not using piece functions, but one thing about it concerns me. While it might be helpful in determining whether a move by the King would be into check, I'm not sure it will work for revealed checks. It is because of the possibility of revealed checks that my code checks for check for the position resulting from every single pseudo-legal move it finds.

Marking of attacked squares to weed out illegal King moves is just one of the two things the accelerated check test does. The other thing is that it tabulates for each board square which (attempted) sliding moves visit it. If such a move did not hit B before, it cannot hit B after a move that would not mutate at least one of the squares that the move visited. E.g. if a Cannon is looking at the King directly it would not check, but during move generation the first leg of the move in the direction of the King would have been attempted, and perhaps even succeeded by capturing something that was behind the King. But whether it succeeded or not, all the squares between Cannon and King would get this Cannon move added to the list of moves that visit them.

If the move to be tested for legality would land on an empty square between Cannon and King, it would see in the constructed table that there was a Cannon that had a move that went over the destination square, and thus will be affected. It will then retry that move of that Cannon, to test whether it hits the King in the new position. Likewise, it would see whether (say) a Bishop had been attacking its origin, and then rerun that Bishop move to test whether it hits the King. This takes care of discovered slides and hopper activation. Moves of other pieces, as well as other moves of these same pieces would not have to be tried; these were not hitting the King before, none of the squares they visited was mutated, so they won't hit the King now.

This is actually the most robust part of the algorithm, which would even work in case of multiple absolute royals: moves that were not checking before cannot check after a move that did not mutate any squares in their path. (But if there are Immobilizers...)

In general the algoritm is very fast: for each move with a royal you test whether the destination is marked as attacked, and for moves with non-royal pieces you only have to rerun the opponent sliding moves that were tabulated as hitting origin or destination (and occasionally other squares that were mutated). And on average there are fewer than 1 enemy sliding moves (i.e. moves that could potentially have continued if the occupancy of the square had been different) to a square, in a typical variant. So in many cases a pseudo-legal move can be accepted as legal by just concluding that the mover was not royal, and the origin and destination of it were not visited by any opponent move. When already in check, it always reruns the move that was delivering that check, as the first test. (Most moves would not resolve the check, and these can then be discarded without further testing.)

Anyway, it is possible to configure the preset to not use the accelerated test, and for a not-too-lage variant (8x8 or 10x10) this will probably work fine.

Marking of attacked squares to weed out illegal King moves is just one of the two things the accelerated check test does. The other thing is that it tabulates for each board square which (attempted) sliding moves visit it.

It's not the same thing that you're doing, but I have now made a quicker version of stalemated called stalemated-quick, which does some preprocessing to reduce the work involved in checking for check. It starts by creating an array of the King's location and each space it may move to, and for each location in this array, it makes an array of every location with an enemy piece that has it in its range. The code looks like this:

// Build threat lists
set krange merge fn join const alias space #kingpos "-Range" #kingpos #kingpos;
set threats ();
for to #krange:
  set threats.{#to} ();
next;
for (from piece) fn #enemies:
  set in intersection var krange fn join const alias var piece "-Range" var from;
  for to #in:
    push threats.{#to} #from;
  next;
next;

So it creates multiple elements of an array called threats, each of which is an array of the enemy pieces that include that space in its full range of movement. At the start of Chess, threats.d2 and threats.d1 both have one element set to d8, and the others (elements e1, e2, f1, and f2 of threats) are empty.

To check for check, it first assumes a value of false, and it tries out the move only if there are pieces potentially threatening the space the King is on. That move looks like this:

set checkpos cond == #from #kingpos #to #kingpos;
set checked false;
if count elem var checkpos threats:
  move #from #to;
  set checked fn threatened #checkpos;
  restore;
endif;

Instead of using the checked function, it used the threatened function, which looks like this:

def threatened anytrue lambda (fn const alias space #0 #0 var king) 
elem var king threats 
=movetype CHECK 
=king;

This function expects threats to be populated with appropriate values. So it can't be used everywhere checked can.

In tests with Chess, everything seems to be working. After making sure it worked, I did some speed tests comparing 100 calls to stalemated with 100 calls to stalemated-quick. In each pair, stalemated is first, and stalemated-quick is second. The results show that stalemated-quick is normally quicker.

Elapsed time: 4.7686970233917 seconds

Elapsed time: 2.8460500240326 seconds

Elapsed time: 4.8747198581696 seconds

Elapsed time: 3.0506091117859 seconds

Elapsed time: 4.4713160991669 seconds

Elapsed time: 2.9584100246429 seconds