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
About Game Courier. Web-based system for playing many different variants by email or in real-time.[All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Thu, Mar 21 10:09 PM UTC in reply to Daniel Zacharias from 09:24 PM:

Okay, I fixed that. They're all now in the same span.


Daniel Zacharias wrote on Thu, Mar 21 09:24 PM UTC in reply to Fergus Duniho from 08:59 PM:

On firefox they line up, but on chromium and vivaldi they don't. It seems to be somehow because the Preview and Resign buttons are both inside a span but the Reset button is not.


🕸💡📝Fergus Duniho wrote on Thu, Mar 21 08:59 PM UTC in reply to Daniel Zacharias from 01:55 AM:

Some recent change to game courier has the Preview Resign and Reset buttons differently sized and misaligned. I assume the bigger Preview button might be intentional, but Reset is positioned slightly higher than Resign and it looks awful.

The bigger Preview button is intentional so that users will more clearly know which button is the main submit button. The alignment of the buttons is a matter of how your browser and device happen to display them. I still see the Resign and Reset buttons at the same level as each other.


H. G. Muller wrote on Thu, Mar 21 06:54 AM UTC in reply to Fergus Duniho from 12:44 AM:

OK, sorry. I overlooked that you were not changing the stroke:none but the fill:none. (And I did not see any filenames, as I just copy-pasted them from your comment in WYSIWIG mode.)

But then the good result is entirely accidental, and cannot be generalized to other images that contain a 'none' filling or stroke.

I think I understand what was causing the problem, though: because this image did not have a black outline with white/blue fill, but had a black ouline without fill, and an exactly matching white/blue area without outline inside it, the latter gets white/blue pixels that are partly transparent when rendered as a raster image. Normally only the black outline touches the transparent background. Apparently the palette did not contain the white/blue with the required transparency, and rounding took place which either made the pixels entire white/blue, or entirely transparent. (Mostly the latter, it seems from the mottled result.) When you apply the fill to the outline, the holes in the inside area make this fill shine through, which camouflages them. In fact these stroke:none elements seem entirely redundant if the other elements are filled.

This SVG was probably generated automatically with the help of an edge-tracing function; these often do not treat the outlines as outlines, but as borderless black-filled areas, tracing both the inner and the outer side of the black lines. And then they create separate areas for the interior.


Daniel Zacharias wrote on Thu, Mar 21 01:55 AM UTC:

Some recent change to game courier has the Preview Resign and Reset buttons differently sized and misaligned. I assume the bigger Preview button might be intentional, but Reset is positioned slightly higher than Resign and it looks awful.


🕸💡📝Fergus Duniho wrote on Thu, Mar 21 12:44 AM UTC in reply to H. G. Muller from Wed Mar 20 09:49 PM:

You're posting the wrong images. Did you notice that the second pair you posted are called wbadger2.png and bbadger2.png? Look at the first two pairs in my previous comment. The first pair is mine, the second pair is yours, and they look the same. You posted the second pair and the third pair, which I never said looked alike.


H. G. Muller wrote on Wed, Mar 20 09:49 PM UTC in reply to Fergus Duniho from 09:42 PM:

And if it's not, why do your badger pieces look exactly the same?

You really cannot see the difference between:

and these?:

 


🕸💡📝Fergus Duniho wrote on Wed, Mar 20 09:42 PM UTC in reply to H. G. Muller from 09:30 PM:

This 'first one' has much to narrow outline compared to the other alfaerie pieces.

What are you talking about? It fits in better with them than the alternative badger pieces do.

It is not the original.

And if it's not, why do your badger pieces look exactly the same? And what do you think it should look like?


H. G. Muller wrote on Wed, Mar 20 09:30 PM UTC in reply to Fergus Duniho from 08:49 PM:

In my opinion, the first ones look best. So I don't think I made any mistake here.

We have a proverb: "In the land of the blind, one-eye is king". The goal is not to be best, but to be good. This 'first one' has much to narrow outline compared to the other alfaerie pieces. It is not the original. As my math teacher used to say: "nearly correct. Thus faulty!"


🕸💡📝Fergus Duniho wrote on Wed, Mar 20 08:49 PM UTC in reply to H. G. Muller from 07:11 PM:

That is not the correct thing to do, and will alter the image.

Here are the badger PNGs I made:

And here are the ones you made:

They look the same.

To figure out what these invisible strokes are, I replaced 'none' by #ff0000, and then I get:

By replacing every remaining none with the fill color, I get these:

By replacing every remaining none with #000000, I get these:

In my opinion, the first ones look best. So I don't think I made any mistake here.


H. G. Muller wrote on Wed, Mar 20 07:11 PM UTC in reply to Fergus Duniho from 06:26 PM:

I replaced "fill:none" with "fill:#5984bd" in bbadger.svg and "fill:#f9f9f9" in wbadger.svg. I uploaded both corrected files and used them to generate new PNG files.

That is not the correct thing to do, and will alter the image. To figure out what these invisible strokes are, I replaced 'none' by #ff0000, and then I get:

So it seems these invisible outlines cover partly the black, and partly the white areas. It would be less critical if you would first reduce the stroke width to 1.

There must be a bug in the SVG rendering routine that it cannot handle the 'none'.


🕸💡📝Fergus Duniho wrote on Wed, Mar 20 06:26 PM UTC in reply to H. G. Muller from 05:34 PM:

I finally got all my size 50x50 PNGs to display correctly. One of the things that was stopping me from seeing any progress was that it had cached the images I had created previously, and it was giving me those instead of creating new images. I got around this by adding a uniqid to the query string for showpiece.php.

I then saw that bknightferz.png and bknightgeneral.png were white. Checking the SVG files, I found them using #ffffff for the fill color. So I changed this to #f9f9f9 for the white images and #5984bd for the black images and uploaded them. After redoing these, the PNGs looked correct.

The one remaining issue is that desertferz and desertwazir each have a gray piece, though maybe this is intentional. So I left these alone.

So what did you replace, and by what?

I replaced "fill:none" with "fill:#5984bd" in bbadger.svg and "fill:#f9f9f9" in wbadger.svg. I uploaded both corrected files and used them to generate new PNG files.


H. G. Muller wrote on Wed, Mar 20 05:34 PM UTC in reply to Fergus Duniho from 05:29 PM:

So what did you replace, and by what?


🕸💡📝Fergus Duniho wrote on Wed, Mar 20 05:29 PM UTC in reply to H. G. Muller from 04:43 PM:

If you open the newly made black badger in a text editor, do you see a white color anywhere in the text? When I look at the original SVG the stroke color around the eyes is #f9f9f9. All other stroke colors are #000000, but there are a few areas that specify "stroke:none". Perhaps the latter cause the problem?

I did a search and replace on the black badger, and that fixed it.


H. G. Muller wrote on Wed, Mar 20 04:43 PM UTC in reply to Fergus Duniho from 04:29 PM:

If you open the newly made black badger in a text editor, do you see a white color anywhere in the text? When I look at the original SVG the stroke color around the eyes is #f9f9f9. All other stroke colors are #000000, but there are a few areas that specify "stroke:none". Perhaps the latter cause the problem?


🕸💡📝Fergus Duniho wrote on Wed, Mar 20 04:29 PM UTC in reply to H. G. Muller from 09:06 AM:

To get a better idea of what's going on, I used showpiece.php to make SVG pieces for the black pieces. These were all colored appropriately. However, looking at the SVG for the black badger, I do see white outlines around most of the blue areas.

Since showpiece.php handles conversion of SVGs to PNGs with different code than it handles mere processing of SVGs, I looked at the difference between these. Each used str_replace for changing the color of the SVG, but each used it with a different condition. I changed the condition for converting to PNG from ($oc != $nc) to !samecolor($oc, $nc), but when I converted the SVGs to new PNGs, I still had the same miscoloring issues.

Since I now had black SVGs, I changed my script to convert each SVG into only one PNG. When I downloaded the results, I still found the same miscoloring issues. This time, though, I knew the SVGs they were based on were not miscolored. I may try to make my imagecreatefromimagick2 function simpler and see if that makes a difference.


H. G. Muller wrote on Wed, Mar 20 09:06 AM UTC in reply to Fergus Duniho from Tue Mar 19 09:58 PM:

Just to be sure I understand what is going on: showpiece.php also renders the white SVG files as a raster bitmap, after replacing the #f9f9f9 by some other color? And then saves this bitmap as a PNG image with palette encoding?

I know for sure that all areas of the images you mention that must be recolored are filled with #f9f9f9. Otherwise the rendering of the black pieces with fen2.php would not have worked. But there the inside of the Rook is always blue.

So the problem is not in the SVG; it must be in showpiece. It must overlook one of the #f9f9f9 strings when it replaces those. That it always does it in the Rook part suggests that the string is in some special context there that prevents it from being recognized by the substitute command. These images are all composits, and they were probably made by Greg (I usually relied on fen2.php's ability to combine SVGs on the fly, without first making SVG for those) with Inkscape by combining the existing SVG images of the pieces they combine. Perhaps this combining created the context that prevents the recognition of the color string.

The bbadger.png looks weird. I suspect something has gone wrong in creating the palette. Perhaps an overflow of the number of colors. It is all the pixels that would interpolate blue and black that seem to be missing.


🕸💡📝Fergus Duniho wrote on Tue, Mar 19 09:58 PM UTC in reply to H. G. Muller from Mon Mar 18 10:11 AM:

Since you moved the pieces from alfaeriePNG50 to alfaeriePNG, I used the alfaeriePNG50 directory for my own conversions with showpiece.php. The main difference is that the images it produced are palette images instead of true color. However, they still have varying alpha values for the edge pixels, and in many cases, they may appear identical to your pieces. After downloading and examining the individual pieces, I found that some black pieces were not recolored properly. These include

  • bbadger.png, which looks grainy in its coloring.
  • bcamelrook.png, which has a white rook.
  • bcamelrookferz.png, which has a white rook.
  • bchancellor.png, which has a white rook.
  • bchancellorferz.png, which has a white rook.
  • bchancellorrider.png, which has a white rook.
  • bforwardchancellorprince.png, which has a white rook.
  • bforwardrookbackwardsprince.png, which is white.
  • bkingrook.png, which has a white rook.
  • bzebrarook.png, which has a white rook.

Since it's consistently the rook part that is white in most of these, I'm thinking there is a problem with the SVG files. However, when I checked some of your conversions, I did not find the same problem. And when I checked the SVG code for some of these, I couldn't spot where a different color than #f9f9f9 was used for the fill color. So I'm not sure what is causing this.


H. G. Muller wrote on Tue, Mar 19 09:28 AM UTC in reply to Fergus Duniho from 07:28 AM:

You are a bit too hard on our non-programmer users. Since Game Courier is partly implemented server side through PHP, and partly client side through JavaScript it is not really possible to know what task is done where if you don't know the exact details of the implementation.

For clarity: the rendering method is decided server side, (so communication with the server is needed to chage it), and only the Table and CSS rendering method, once provided by the server, would allow you to move pieces through mouse clicks.

BTW,  isn't it possible to make the system more user friendly by automatically requesting a new page load when someone changes the setting of the render method? It should be possible to attach a JavaScript event handler to such a change of the selected item.


🕸💡📝Fergus Duniho wrote on Tue, Mar 19 07:28 AM UTC in reply to Jean-Louis Cazaux from 06:03 AM:

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.


Jean-Louis Cazaux wrote on Tue, Mar 19 06:03 AM UTC in reply to Fergus Duniho from 12:14 AM:

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


🕸💡📝Fergus Duniho wrote on Tue, Mar 19 12:14 AM UTC in reply to Jean-Louis Cazaux from Mon Mar 18 10:25 PM:

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.


Jean-Louis Cazaux wrote on Mon, Mar 18 10:25 PM UTC in reply to Fergus Duniho from 09:57 PM:

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


🕸💡📝Fergus Duniho wrote on Mon, Mar 18 09:57 PM UTC in reply to Jean-Louis Cazaux from 09:39 PM:

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.


Jean-Louis Cazaux wrote on Mon, Mar 18 09:39 PM UTC in reply to Fergus Duniho from 07:35 PM:

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.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.