Check out Symmetric Chess, our featured variant for March, 2024.


[ 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
Game Courier Logs. View the logs of games played on Game Courier.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on Sat, Mar 16 06:55 AM UTC in reply to Daniel Zacharias from Fri Mar 15 11:36 PM:

Could you add the missing bnespearman to alfaeriePNG?

OK, done.


Daniel Zacharias wrote on Fri, Mar 15 11:36 PM UTC in reply to H. G. Muller from Thu Mar 14 09:36 AM:

Could you add the missing bnespearman to alfaeriePNG?


H. G. Muller wrote on Thu, Mar 14 09:08 PM UTC in reply to Fergus Duniho from 08:07 PM:

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.


🕸📝Fergus Duniho wrote on Thu, Mar 14 08:07 PM UTC in reply to H. G. Muller from 06:31 PM:

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.


H. G. Muller wrote on Thu, Mar 14 06:31 PM UTC in reply to Fergus Duniho from 05:33 PM:

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


🕸📝Fergus Duniho wrote on Thu, Mar 14 05:33 PM UTC in reply to Fergus Duniho from 03:18 PM:

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.


🕸📝Fergus Duniho wrote on Thu, Mar 14 03:18 PM UTC in reply to H. G. Muller from 09:36 AM:

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.


H. G. Muller wrote on Thu, Mar 14 09:36 AM UTC in reply to Fergus Duniho from Wed Mar 13 10:12 PM:

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


🕸📝Fergus Duniho wrote on Wed, Mar 13 10:12 PM UTC in reply to H. G. Muller from 08:49 PM:

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.


H. G. Muller wrote on Wed, Mar 13 08:49 PM UTC in reply to Fergus Duniho from Tue Mar 12 04:56 PM:

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.


🕸📝Fergus Duniho wrote on Tue, Mar 12 04:56 PM UTC in reply to H. G. Muller from 02:24 PM:

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]


H. G. Muller wrote on Tue, Mar 12 02:24 PM UTC in reply to Fergus Duniho from 01:18 PM:

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:


🕸📝Fergus Duniho wrote on Tue, Mar 12 01:28 PM UTC in reply to Jean-Louis Cazaux from 06:47 AM:

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]


🕸📝Fergus Duniho wrote on Tue, Mar 12 01:18 PM UTC in reply to H. G. Muller from 08:15 AM:

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?


H. G. Muller wrote on Tue, Mar 12 08:15 AM UTC in reply to Jean-Louis Cazaux from 06:47 AM:

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.


Jean-Louis Cazaux wrote on Tue, Mar 12 06:47 AM UTC in reply to Fergus Duniho from Mon Mar 11 09:58 PM:

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.


🕸📝Fergus Duniho wrote on Mon, Mar 11 09:58 PM UTC in reply to Jean-Louis Cazaux from 07:20 PM:

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.


Daniel Zacharias wrote on Mon, Mar 11 09:16 PM UTC in reply to Jean-Louis Cazaux from 08:23 PM:

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.


Jean-Louis Cazaux wrote on Mon, Mar 11 08:23 PM UTC in reply to H. G. Muller from 07:38 PM:

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?


H. G. Muller wrote on Mon, Mar 11 07:38 PM UTC in reply to Jean-Louis Cazaux from 07:20 PM:

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


Jean-Louis Cazaux wrote on Mon, Mar 11 07:20 PM UTC:

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


Kevin Pacey wrote on Wed, Mar 6 04:32 PM UTC in reply to wdtr2 from 10:06 AM:

At some point a while back there was a series of several finished games in a row on the link for 'Finished Games' that had a wrong result recorded (not just for some games of Pocket Shogi Copper, where we played) - Fergus fixed those glitches subsequently.


wdtr2 wrote on Wed, Mar 6 10:06 AM UTC in reply to wdtr2 from 09:59 AM:

@kevin

Amendment: I just visited your game and it said "Black has won". I think maybe fergus fixed it, or the issue has been resolved. Is all working as it should?


wdtr2 wrote on Wed, Mar 6 09:59 AM UTC in reply to Kevin Pacey from Tue Feb 6 07:01 PM:

@Kevin Kevin for pocket Shogi Copper is the "White has won" a major issue? If yes, I might be able to adjust the code. When I wrote the code I think I may have reversed the shogi pieces. i.e. black is white, and white is black. I think I reversed the label names in the programming section, and I am guessing that is the issue for white has won. The combination of reverse pieces and the labels most likely is the cause for pocket shogi copper white has won.

Do you want me to try and fix it?


Jean-Louis Cazaux wrote on Tue, Mar 5 07:05 PM UTC in reply to François Houdebert from 06:58 PM:

Yes OK, it's back to normal now. Thx


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.