Comments/Ratings for a Single Item

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

I fixed that too.

Thanks! Much better now

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

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.

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.

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.

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.

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.

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.

Many alfaerie pieces are invisible now using css rendering.

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?

This game and also this for example.

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.

thanks!

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

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.

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.

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.

Are you using Alfaerie pieces with the Table rendering method? To stop borders from expanding beyond the space a piece is in, this method will now reduce pieces in size just enough to make room for the borders. For pieces with optimized dimensions, such as Abstract, Magnetic, and Motif, this affects only the largest of pieces. But since Alfaerie pieces have uniform dimensions no matter how big the visible image is, they are all reduced in size. If this makes pieces too small for you, you can switch to the CSS rendering method, which does things in a manner better suited for piece images with uniform dimensions.

Yes the games I'm playing are made with Alfaerie. The rendering method is Table. If I change and set it to CSS, when I re-load, it comes again to Table with very tiny icons.

So I can't play with my mobile. I discovered this this morning. Until that day, I was able to play. I don't know what you have changed and for which reason, but for me it is not good.

If I change and set it to CSS, when I re-load, it comes again to Table with very tiny icons.

If you're literally reloading the page, that would be a mistake. You should submit the form and load a new page.

I don't know what you have changed and for which reason

I just told you in my previous comment.

Anyway, I have modified it to crop images with extra space, and now the pieces are showing up at normal size. The only downside is that the image cropping seems to take a few moments to complete. At least I saw a delay between showing the Black pieces and the White pieces in Chess.

There is also an issue where the spaces increase in height from 50 to 60 when I deselect a piece. I have not figured out why this is happening, but it does seem to be unrelated to my new code for cropping piece images.

"If you're literally reloading the page, that would be a mistake. You should submit the form and load a new page."

I don't see how I can do otherwise. I go to Rendering box, I get a menu. I select CSS instead of Table, then nothing change with the diagram. I see no special button to "submit" or something like that, so I reload and the diagram has still small icons and the rendering is back to Table.

"I just told you in my previous comment"

Where?

"Are you using Alfaerie pieces with the Table rendering method? To stop borders from expanding beyond the space a piece is in, this method will now reduce pieces in size just enough to make room for the borders. For pieces with optimized dimensions, such as Abstract, Magnetic, and Motif, this affects only the largest of pieces. But since Alfaerie pieces have uniform dimensions no matter how big the visible image is, they are all reduced in size. If this makes pieces too small for you, you can switch to the CSS rendering method, which does things in a manner better suited for piece images with uniform dimensions."

Sorry I don't see where in this text what you have changed and why.

The pieces are about 1/3 in L and 1/3 in h compare to one square dimensions. So too small for me but also too small for anyone with a similar mobile I think.

I don't see how I can do otherwise. I go to Rendering box, I get a menu. I select CSS instead of Table, then nothing change with the diagram.

Of course nothing changes. This is an HTML form that calls a PHP script to redraw the board. If you reload the page, it will just reset the form, which is the opposite of what you are trying to do. For the values in the form to do anything, you must submit the form.

I see no special button to "submit" or something like that, so I reload and the diagram has still small icons and the rendering is back to Table.

Yes, you do see the submit button, but you are overlooking it because it doesn't say "Submit". It is the same button you would use to submit your move. During the course of playing a game, this may be "Preview" or "Move". When viewing a game, it would be "View".

The pieces are about 1/3 in L and 1/3 in h compare to one square dimensions.

I'm looking at it on a small phone, and I see what you mean. While the code I added will fix the display on my desktop, it doesn't fix things when the squares are greatly reduced in size.

"I just told you in my previous comment"

Where?

"Are you using Alfaerie pieces with the Table rendering method? To stop borders from expanding beyond the space a piece is in, this method will now reduce pieces in size just enough to make room for the borders. For pieces with optimized dimensions, such as Abstract, Magnetic, and Motif, this affects only the largest of pieces. But since Alfaerie pieces have uniform dimensions no matter how big the visible image is, they are all reduced in size. If this makes pieces too small for you, you can switch to the CSS rendering method, which does things in a manner better suited for piece images with uniform dimensions."

Since reducing the size of a piece does not work well for spaces that are already reduced in size, I have turned off this behavior when the board is already being displayed at a smaller size. I tested this on the small phone, and the pieces became appreciably larger.

"Of course nothing changes. This is an HTML form that calls a PHP script to redraw the board."

@Fergus: I'm not an informatician. I come here to read and play about chess variants not to discuss computer science. I don't know what PHP script is and I don't think it is necessary to know to play Tigrey or Timurid chess.

Today I play with my McBook and what I see is that is has become very slow to display a 10x10 or 12x12 board on my screen.

The important thing for you to know about PHP is that it is a server-side language. That means it runs on the web site, not in your web browser. Game Courier uses forms to pass data to programmable web pages. These pages run their code on the server and send only their output to your web browser. While Game Courier is enhanced by JavaScript, a client-side language that does run in your browser, it does not use it to entirely redraw the board.

While you don't need to know how to program, it is basic computer literacy to understand the difference between server-side and client-side scripts. Server-side scripts produce web pages, and bscause they run on the server, they can output the same web pages to any web browser. Client-side scripts run on web pages. They rely on your browser knowing the language, and because of differences between browsers, code that works in one browser might not work in another.