Comments/Ratings for a Single Item

On my mobile, Samsung, the piece icons on Game Courier on ongoing games have become very small. Barely visible. I think it was not like that before.

There are quite some more differences than I would have expected. Apparently there are a lot of SVG images that have not been incorporated in the PNG set. Mostly 'ferzed' or 'wazired' versions of existing mimages, by drawing a cross on those.

The PNG set has a number of inverted images, which were no doubt made by rendering the normal SVG upside-down with the aid of fen2.php. It has also a gnu, as a knight-camel composit, and many elephant composits. These were probably all made with the aid of fen2.php's ability to combine two images.

The white crookedbishop was wrongly named in the PNG set. The bknightgeneral is missing from the PNG set, which has a wknightgeneral. There is a wpegasus.svg file in the PNG directory, which doesn't belong there.

The best approach is probably to just copy all the PNG50 files to the PNG directory, which will make all the files in the rightmost two columns available, and replace every image not in the left two columns by their 50x50 equivalent. Then only the images in the left two columns might have to be reconstructed at 50x50 through a more dedicated action than just rendering an SVG. Although some of these already are 50x50.

[Edit] I remade all the remaining images, so all alfaeriePNG are now 50x50.

I made an inventory of the Alfaerie PNG pieces we currently have, in particulare what is the difference between the set in the alfaeriePNG directory (which are mostly 48x48) and that in the alfaeriePNG50 directory (which is the entire alfaerieSVG directory rendered as 50x50 PNG). By first redirecting the output of an 'ls' command to a file in each of these directories, then letting the 'diff -u' command compare them, and finally extract the omisisons and additions by using 'grep' for lines starting with + or -, I created the following table. The + refers to files that are in alfaeriePNG50, but not in alfaeriePNG, the - means the opposit.

-bbishopinv.png
-bcamelknightferz.png
-bcardinalinv.png
-bchancellorinv.png
-bcircle2.png
-bcircle.png
-bcobra.png
-bcoordinator2.png

-belephantknight.png
-belephantrook.png
-belephantwazirbishop.png
-belephantwazircamel.png
-belephantwazirknight.png
-belephantwazirrook.png
-bfiredragon.png
-bgnu.png
-bkinginv.png
-bknightdabbabah.png
-bknightferzdabbabahrider.png
-bknightinv.png
-bpawninv.png

-bqueeninv.png
-brookinv.png
-bvao2.png
-bviper.png
-bwarmachineriderferzcamel.png
-bwarmachineriderferzrook.png
-bwarmachinerider...
...generalelephant.png
-bzebrawazir.png
-gcircle2.png
-gcircle.png
-rcircle2.png
-rcircle.png

-wbishopinv.png
-wcamelknightferz.png
-wcardinalinv.png
-wchancellorinv.png
-wcircle2.png
-wcircle.png
-wcobra.png
-wcoordinator2.png
-wcrooked.png
-welephantknight.png
-welephantrook.png
-welephantwazirbishop.png
-welephantwazircamel.png
-welephantwazirknight.png
-welephantwazirrook.png
-wfiredragon.png
-wgnu.png
-wkinginv.png
-wknightdabbabah.png
-wknightferzdabbabahrider.png
-wknightinv.png
-wpawninv.png
-wpegasus.svg
-wqueeninv.png
-wrookinv.png
-wvao2.png
-wviper.png
-wwarmachineriderferzcamel.png
-wwarmachineriderferzrook.png
-wwarmachinerider...
...generalelephant.png
-wzebrawazir.png

+bcamelbishopwazir.png
+bcamelgeneral.png
+bcamelriderferz.png
+bcamelridergeneral.png
+bcamelriderguard.png
+bcamelriderwazir.png
+bcamelrookferz.png
+bcamelzebra.png
+bchancellor_test.png

+belephantferzhero.png
+belephantgeneral.png
+belephantridergeneral.png
+belephantwazirwarmachine.png
+bgeneral2.png
+bgreatwarmachinegeneral.png
+bknightgeneraldabbabah.png
+bknightgeneral.png
+blemurianelephantferz.png
+blemurianwarmachinewazir.png
+bnarrowknightgeneral.png
+bnarrowknightwarmachine.png
+bnarrowknightwazir.png
+bnightriderferz.png
+bnightridergeneral.png
+bnightriderguard.png
+bnightriderwazir.png
+bsquirrelferz.png
+bsquirrelwazir.png
+btank.png
+bwarmachinegeneral.png
+bwarmachineridergeneral.png
+bwideknightferz.png
+bwideknightgeneral.png
+bwideknightwarmachine.png
+bwideknightwazir.png
+bzebrageneral.png
+bzebraguard.png
+bzebrarook.png

+wcamelbishopwazir.png
+wcamelgeneral.png
+wcamelriderferz.png
+wcamelridergeneral.png
+wcamelriderguard.png
+wcamelriderwazir.png
+wcamelrookferz.png
+wcamelzebra.png
+wchancellor_test.png
+wcrookedbishop.png
+welephantferzhero.png
+welephantgeneral.png
+welephantridergeneral.png
+welephantwazirwarmachine.png
+wgeneral2.png
+wgreatwarmachinegeneral.png
+wknightgeneraldabbabah.png

+wlemurianelephantferz.png
+wlemurianwarmachinewazir.png
+wnarrowknightgeneral.png
+wnarrowknightwarmachine.png
+wnarrowknightwazir.png
+wnightriderferz.png
+wnightridergeneral.png
+wnightriderguard.png
+wnightriderwazir.png
+wsquirrelferz.png
+wsquirrelwazir.png
+wtank.png
+wwarmachinegeneral.png
+wwarmachineridergeneral.png
+wwideknightferz.png
+wwideknightgeneral.png
+wwideknightwarmachine.png
+wwideknightwazir.png
+wzebrageneral.png
+wzebraguard.png
+wzebrarook.png

thanks!

What I saw happening in the first example is that many images were broken. While they were invisible on the board, I could see the broken image icon littering the Captured Pieces area. This is because I had replaced GD's imagetruecolortopalette with my own imagetruecolortopalette2, which I noticed I had written to do the same thing while preserving the alpha values of individual pixels. But I had forgotten and didn't notice that these two functions took different parameters. So, just changing the function name broke the script whenever it was called. When I also filled in the correct parameters, it worked. I downloaded one of the images it produced, and when I examined it in Ultimate Paint, I could see that individual edge pixels had different alpha values, which makes the piece look smoother, and it was a 50x50 palette image with a smaller file size than the 48x48 true color image it was based on. When I checked the second example, there was no longer any problem.

This game and also this for example.

Many alfaerie pieces are invisible now using css rendering.

I just looked at the page you pointed me to last time Alfaerie pieces were transparent, and I saw no problem with them when I switched it to CSS. So, where are you seeing this?

Many alfaerie pieces are invisible now using css rendering.

Currently, when I have changed the appearance settings for a game, after I confirm a move or if I cancel a previewed move, the appearance reverts to the default settings.

The Cancel button is on its own form, and it will cancel everything except the comment you wrote. This includes any changes to the appearance.

The Confirm button was being missed by some new code fixing another problem, because the value of the Confirm button is still Send, and I was checking for a value of Confirm. When I changed it to check for a value of Send, it worked.

Currently, when I have changed the appearance settings for a game, after I confirm a move or if I cancel a previewed move, the appearance reverts to the default settings.

Both appear to be fixed now. I had to color the new image green before copying the original image to it. Otherwise, some pixels in the original image might match the background color of the new image. Taking out the lines for filling it with the transparent color after copying the image fixed the problem with the PNG King's cross being partially transparent. What I needed to keep were the lines for identifying the transparent color in the new image.

So, the padding works like this.

1. If the image is true color, it gets converted to a palette image.
2. It identifies the transparent color in the original image. It first tries imagecolortransparent, then it looks for pure green, and if neither of those work, it assumes the color at (0,0) is transparent.
3. It changes the RGB values of the transparent color to green (#00ff00).
4. If either dimension of the image is below the value of $size, it creates a new $size x $size palette image.
   1. It colors this image green.
   2. It copies the palette of the original image to the new image.
   3. It copies the original image to the new image at a centered location.
   4. It recalculates the new image's transparent color in the same manner as before.
   5. It copies the variable for the new image to that of the original image.
   6. It destroys the original image.
5. When it outputs the image, it assigns the transparent color to what was previously calculated to be the transparent color.

The fix I made for Alfaerie GIFs being transparent is now broken thanks to a fix I made yesterday for Alfaerie PNGs with black borders.

Due to the way the Square CSS method handles resizing, both are being passed to showpiece.php for padding due to being slightly undersized. Padding involves the creation of a second larger image onto which the original image is copied to the center. Before yesterday's fix for the PNGs, it would first fill the new image with the transparent color. Since that fix, it will first copy the image, find the transparent color again, and fill in the edges. But something is going wrong with the GIFs, and I am working on trying to fix it.

In both instances, the images are not following the conventions Game Courier expects from piece images. Neither the GIFs not the PNGs are following the convention of using pure green (#00ff00) for the transparent color, and the PNGs are truecolor instead of palette images, which prevents the use of imagecolortransparent for finding out which color is transparent.

This happened because of changes I made to make sure that Square CSS did resizing correctly. To resize a piece, it uses the CSS property "background-size: contain", which will stretch or reduce a piece to fit the space. But this works correctly only if all the pieces have the exact same dimensions. But the pieces I have made for my own sets, such as Abstract, Motif, and Magnetic, are optimized to the dimensions of the actual image drawn, which will vary from piece to piece. For small pieces, such as Pawns, a background-size of contain will cause them to appear as large as other pieces. To prevent this, I employed showpiece.php to pad pieces whose dimensions fall below the $height and $width values specified in the set. This makes them all the same size, so that using a background-size of contain is an appropriate way to resize them.

The problem with these old Alfaerie pieces is two-fold. First, many of them have dimensions of 49x49 instead of the 50x50 specified for the Alfaerie: Many set. Because of this, they are now being sent to showpiece.php for padding. The other problem was that they were not following the convention of using pure green (#00FF00) for the background color. Because of this, the script was losing track of which color was supposed to be transparent, and it was making the wrong color transparent. I corrected this with code that finds the transparent color and sets it to green before the padding of the image is done. That code looks like this:

    // Assure that background is green
    $trans = imagecolortransparent($img);
    if ($trans == -1) {
        $trans = imagecolorat($img, 0, 0);
    }
    imagecolorset ($img, $trans, 0, 255, 0);

With this change made, the pieces are now showing up properly.

It's too late for me to work on this tonight. Many Black pieces turned white, and I examined the Black King, which had this code:

grid-area: r12 / f6; background-image: url(/play/pbm/showpiece.php?image%3D%2Fgraphics.dir%2Falfaerie%2Fbking.gif%26size%3D50)

The strange thing is that there is nothing in the query string about changing color, and the piece is originally black. And here is an image link to the piece just to confirm:

And it looks like the piece is transparent. I'll look into that more tomorrow.

Another strange css thing: in this game using Alfaerie: Many CSS rendering results in some of the black pieces being white.

Thanks! Much better now

PNG does scale the pieces correctly, but with that the highlight squares don't line up with the board squares.

I fixed that too.

but that wouldn't matter except that with CSS they don't scale down at all.

Since you pointed it out, I have fixed scaling for Square CSS.

If you set the scale to 120, and you're using a set of pieces that are all 50x50, such as Alfaerie, it should give you normal size pieces on a slightly larger board. So, now, there are three options for keeping the image borders confined to the space the piece is on.

1. Using Square Table at scale 100, the board will remain the same size, but the pieces will be smaller.
2. Using Square Table at scale 120, the pieces will be normal size, but the board will be a bit bigger.
3. Using Square CSS at scale 100, the pieces and the board will be normal size, but there will sometimes be overlap between the border used to highlight a space and the piece on that space.

Each option produces a side effect, and it's a matter of choosing which one is least disagreeable to you.

That does look better for smaller games. For larger games (like 16x16 Bigorra) where the scale might need to be reduced to see the whole board at once, the images can look too tiny with Table, but that wouldn't matter except that with CSS they don't scale down at all. PNG does scale the pieces correctly, but with that the highlight squares don't line up with the board squares.

The fix is to display the piece images not as content of the table cells, but as background.

I saw you doing that for Interactive Diagrams and applied this solution to the Square CSS format. But I did not apply it to the Square Table format, because this is supposed to be an HTML format that will continue to work with older browsers. So, to fix this, I have employed an entirely HTML solution.

The solution in place now is that it reduces the height and width values in the img tag used to display a piece that is too large for the square size. The maximum height or width a piece may now have in the Square Table format is ten pixels less than the $height and $width values. I had to work out some kinks with pieces displayed with showpiece.php. The getimgsize() function, an alternative to GD's getimagesize() function that will work with script-generated images, was not using the correct file name, and I corrected that.

The problem is that browsers refuse to fit 50x50 images in 50x50 cells, because they align the bottom of the image with the text line it is on, and text lines need extra space below them for the 'true descenders' on letters like j, p and q.

I don't think this is true. Each piece image is centered in its table cell. The problem was that when borders are used to highlight pieces, the borders sometimes extend beyond the size of the table cell, causing it to expand in size. By putting a cap on the size of the images, I have stopped this from happening.

Is this fixable?

It is easily fixable, and I think fixing it is long overdue, as it looks very amateurish.

The fix is to display the piece images not as content of the table cells, but as background. So instead of something like

<td style="width:50px;height:50px"><img src="xxx"/></td>

you would generate something like

<td style="width:50px;height:50px;background-repeat:no-repeat;background-position:center center;background-image=url(\"xxx\")"></td>

(where the extensive style specification can of course be achieved through a CSS class). You can then highlight through a border with negative margins. This is how I got rid of these annoying expansion/contraction effects in the Interactive Diagram. (But there I highlight by small symbol images displayed as content of the cell.)

If the cell backgrounds have transparent parts, you see either the specified cell background color there. Or, when no valid color is defined, the background of the surrounding (<table>) element. So you can still use full-board images as background.

The problem is that browsers refuse to fit 50x50 images in 50x50 cells, because they align the bottom of the image with the text line it is on, and text lines need extra space below them for the 'true descenders' on letters like j, p and q. So they always leave some space below the image, even if there is no text at all in the cell. How much depends on the font size that currently applies, but it is not possible to set that to 0.

When using the table rendering method, highlighted squares don't stay the same size as unhighlighted squares so the board ends up shifting around a lot when looking at move options.

This depends on the size of the individual piece, though some sets, such as Alfaerie, maximize the dimensions of the piece images, so that you may see this effect for every piece.

Is this fixable?

If you made your spaces larger than the largest pieces, you might leave enough room for a border around the piece image without expanding the size of the space. 54x54 might work better than 50x50, for example. However, the square size for the Table method is determined by the $height and $width values, which are provided in the set file, and these are usually set to 50 for the Alfaerie sets.

At least the css rendering doesn't have this problem

One of the reasons to start favoring the CSS rendering method.

When using the table rendering method, highlighted squares don't stay the same size as unhighlighted squares so the board ends up shifting around a lot when looking at move options. Is this fixable? At least the css rendering doesn't have this problem