Comments/Ratings for a Single Item
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.
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.
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.
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?
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.
So what did you replace, and by what?
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.
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'.
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.
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!"
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?
And if it's not, why do your badger pieces look exactly the same?
You really cannot see the difference between:
and these?:
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.
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.
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.
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.
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.
Okay, I fixed that. They're all now in the same span.
When fairychess is allowed to fill in the rules section for a game that uses svg piece images, some of the pieces end up being much larger than the others. This seems to be because the image is sized according to the piece name, even if the name is very long. Having the css explicitly set the image size could solve this.
Since the fairychess include file uses a shortcode to display pieces, I changed how the shortcode works instead of any code in the fairychess include file. I modified it to include WIDTH and HEIGHT values in the IMG tag when the image is an SVG image. These will be equal to $width and $height when these variables have values, as they usually do in Game Courier, and they will be 50 otherwise.
something seems wrong with this game. The code is just copied from Chinese Chess with some pieces added, so I don't think I changed anything important, yet it's saying I'm in check when I'm not.
Your link is missing a query string.
oops, this is it
You're using k/K for the general, but the code you copied is using g/G. So kpos and Kpos are not being updated.
25 comments displayed
Permalink to the exact comments currently displayed.
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.