Comments/Ratings for a Single Item

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.

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

@ 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

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.

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?

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

Could you add the missing bnespearman to alfaeriePNG?

OK, done.

Could you add the missing bnespearman to alfaeriePNG?

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.

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.

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

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.

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.

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

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.

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.

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]

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:

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]

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?

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.

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.