Comments/Ratings for a Single Item

Interesting!

I'll try to compile it and use it out of curiosity when the time comes.

Current assignment is A=BN, B=B, C=C, D=RF, E=FA, G=[F?R], H=BW, K=K, L=KNAD, M=RN, O=WAD, P=Pawn, Q=Q, R=R, S=fW, T=QN, U=[W?B], V=mBcpB, W=FC, X=mRcpR, Z=Z.

You omitted N, which I assume is the Knight. That leaves F, I, J, and Y. Can pieces be assigned to longer strings than single letters?

Can pieces be assigned to longer strings than single letters?

No, because the letters are used in a FEN. Letter + punctuation would be an option. But probably not worth the trouble, as I think we already cover almost all frequently used pieces, mostly with not very non-intuitive abbreviation.

When I download https://www.chessvariants.com/graphics.dir/alfaeriePNG/wking.png or wrook.png, etc., I get a 48x48 image and the white is 255.

Indeed, strange. And the GIF image of King is 49x49. All I can say is that every image I made (and I made a very large number of them) in PNG or PNG35 were rendered with the http://winboard.nl/my-cgi/fen2.cgi piece server, at a size 50x50, using its default white color, which is 249,249,249. As I recall it most of the old GIF files were also 50x50. (I am pretty sure of that, because I could not use them in WinBoard, which required 49x49 as the closest size.) The Wazir on the alfaerie GIF page is 50x50.

So I guess there is no consistency. It is the King and the Rook that have the wrong size and color, though. I should remake those one of these days.

"It is the King and the Rook that have the wrong size and color". Well, I'm not going to test all of them, but also Pawn, Knight, Queen, Camel, Fool, Wazir, Tiger, Rhino, Frog, Ram I stop, all in 255/255/255. I bet they are the vast majority.

In term of size, all of them are 48x48, incl the Wazir.

It seems that only those you added recently are different.

To understand, why 249/249/249? (F9F9F9). Why not FFFFFF? I suspect there is a technical reason, maybe to contrast with a FFFFFF background? I'm curious.

No, because the letters are used in a FEN.

Hah;) are non-ASCII suitable? I say as guy who overwrites pieces with them)

In term of size, all of them are 48x48, incl the Wazir.

Not on this page, they aren't. Wazir, Giraffe, Lion, Camel... All are 50x50. The orthodox pieces are 49x49, though.

I don't know where the F9F9F9 comes from. But all SVG Alfaerie piece images must use that as white fill color, or the rendering engine would not replace it by the color you requested. (And in particulare, not with blue if yioou request a black piece.)

The rendering engine's default has always been set to leave the white color as it was. And it has always been our way to convert the SVG to the PNG images in alfaeriePNG and alfaeriePNG35. But perhaps the one who has been making those other images (I suspect Greg Strong) has used an explicit w=...... argument to request pure white. I never did that, as it didn't make sense to me that the PNG images should not use the same white as thenatural color of the SVG images.

Hah;) are non-ASCII suitable?

Not really. Most people would not be able to type those in a simple way. Which sort of defeats the only purpose of the cbPiecesFromFEN function: to simplify things. People would even have difficulty remembering what non-ascii they would have to use for a given piece. Even with the ASCII alphabet that danger exists, which is why I try to make the assignment as straightforward as possible.

I am now in a state where I have almost no uncommitted patches (except those that I intentionally don't want to commit, such as the reversion of the gulp update, and 'games' I added for testing purposes to index.js). I also have applied the addition of the Terror, and pushed everything to the trial branch of my repository.

I even pushed the command-line tool for 3d piece creation, in a new directory jocly/tube.

I've published the changes on github
As I've modified the hawk sprites in the meantime, I think you'll need to get the latest version of
wikipedia-fairy-sprites.png

I've seen jocly/tube, so I'll have to study that in depth.

How do you see the next step? Is it possible to pull down the refactoring of the documentation (html of rules, images ...) to get index.js files closer? or Shall we do it on a brand new branch?

@HG, Fergus: I believe that the folder which counts is the one I'm pointing. Because it concerns the .png. The page you are referring just displays .gif. The .png are those called in the Game Courrier presets.

Maybe something modifying automatically all Alfaerie png's into 50x50 and setting white to F9F9F9 for all will improve the quality of our graphics. To be seen with Fergus?

@Jean-Louis: the gif files are the original alfaerie; the png are intended to be their anti-aliased replacements. Color or size change was never intended.

I believe the original white color (i.e. in the gif) is ffffff. It doesn't help much that the gif already have inhomogeneous size (49x49 or 50x50), but it was alway my intention to use 50x50 (and a new series of 35x35).

So I think we should re-render all SVG with the aid of fen2.php with arguments s=50&w=ffffff. (Actually I should set ffffff as fen2.php's standard white color for alfaerie.) I think I can do that today by turning the directiry listing of alfaerieSVG into a shell script that does the rendering.

As I've modified the hawk sprites in the meantime, I think you'll need to get the latest version of
wikipedia-fairy-sprites.png

The (ever recurring) problem is that yesterday night I still made some more 2d sprites for the 3d pieces I had already created with Tube, so that I could add and commit those. As a result we have again two incompatible 'latest versions' of the fairy-sprites file. Git cannot merge binary files, so I will have to create the merged image by hand, and then commit the rusult as a new commit, different from the original one. As I also had to do for adding the Terror. I will download the version from GitHub and take the new Hawk image out of that to copy it over the old one in my latest version.

This is really a very annoying characteristic of Jocly. It would have been much better is all the 2d sprites were just separate image files.

I think it should be possible to pull and merge the documentation reorganization into the same branch, as they should consider only independent changes. I will try it later today. If not we should copy it to a different branch, and then rebase one on top of the other; I am sure that will work.

Many of the games I made would need documentation too; since I was hacking those into the library, and control.html would not display rules and such anyway, I never bothered with that. The new pieces would need images that can be included in rule descriptions too.

I've started making graph images to help with the doc. I can make more images if it's useful.

The documentation is an important part of the project, because it's likely that in 2 or 3 months' time, all this will be available in the mobile applications for a wide audience who aren't necessarily comfortable with English and who want to get straight to the point. For example, for elven, it's important to explain the rules for the lion at the beginning of the page.

Note that my branch trial is rebased if you want to try to pull it.

We should make sure  that the external links in the documentation go to pages that the authors will be able to maintain over time, because updating mobile terminals will depend on the users.

I'd therefore advise anyone who has variants in jocly to make sure that the rules/description/credits pages are suitable for them with joclyboard.

I tried to use fr-terror in Makromachy and Minjiku Shogi, but it doesn't show up, and the JavaScript console of the browser reports an error (in a piece of code that looks totally unfamiliar to me, so presumably in the rendering library). So there seems to be something wrong in the .js file. (It seems to contain a lot of cruft, besides the lists of coordinates.)

Some other thoughts:

Visuals: When I look at the 2d visual you made for Mirza, the Griffon symbol strikes me as way too big compared to the symbols for the orthodox pieces. In fact the latter strike me as way too small for the square size that is used, and located too high in the square (which might be a consequence of that). To a lesser extent that also applies to the Prince symbol. (I suppose it doesn't stick out that much because it depicts a naturally smaller object.)

The black Cannon2 seems to have a black line above it in your visual that doesn't belong there. In the 2D representation of Makromachy I don't see that, though. The squares are smaller there, and this emphasizes that the white Cannon2 is really drawn too low.

I guess we should make an effort to harmonize the fairy-sprites.

PiecesFromFEN: For variants with complex promotion rules it is still a pain to extract the piece-type numbers for use in the promote routine. Would it make sense to make these numbers more predictable for the programmer? We could adopt the convention that P and S come first (in that order), and take the numbers 0-1 (or 0-3 if both are present, which would be extremely rare). After that all non-King pieces in alphabetical order of their ID in the FEN, and King last. This would be just a matter of re-ordering the tests for the presence of the pieces in cbPiecesFromFEN. In Grand Chess they would then know that A=2, B=3, M=4, N=5, Q=6 and R=7.

The assumed piece values are what they should be for an 8x8 board. For larger variants people might want different values (upgrading sliders as compared to leapers), and it currently would be a pain to redefine all values through statements like "p.pieceTypes[name2nr['rook]].value=...". If people want to redefine values, it is likely they want to redefine it for all the pieces. So perhaps there should be a function for that, which takes an object with the new values as argument. Like

p.setValues({P:0.8, N:2.5, B:3.75, R:6, Q:11});

Of course that might be futile, as people implementing the variant might have no idea what the piece values are, and actually make things worse than just using the default 8x8 values. So perhaps the default values should take account of the board size, to reduce the need for hand tuning.

Tube: The pieces we can generate now are acceptable, but I still think their diffusemaps should be better. They seem a bit bland to me. E.g. if I look at Saint or Caliph, their down-pointing surfaces are not nearly as dark as the head of the King & Queen. The natural shading algorithm gets some assistance there from a darkness gradient in the diffusemap for the head sections. I think we should have that too. It might be hard to do it automatically, but we could provide a command to order it in the tube input file. Like allowing mention of a second color in paint/shade, which would then then be interpolated to start at the first and end at the second as we traverse through the ring. And then redo all pieces we made so far, to replace their diffusemaps.

I made some adjustments to the fairy-sprites file, to better align all the pieces there, and improved some of the images I added. Some images are still unacceptably poor, though, and need reworking (too thin lines (axe, black admiral, mamoth and diamond), white outline (bull, ship, squirrel), too large (squirrel, griffon)). I am not sure whether that can be done on the existing 100x100 raster images, though. Certainly not with GIMP. So perhaps they will first have to be remade as SVG.

fr-terror : you are right, I had a conflict on that file, I thought I resolved it correctly, but I didn‘t. I pushed a new version.

Your evolutions for PiecesFromFEN are interesting, I will certainly use the setValues functions if possible.

I managed to compile Tube but I am not yet able to make the most out of it. Of course we can replace the diffuse maps if we have improved ones.

Concerning the visuals, I made it from screen capture from joclyboard, that may be why the chessboard square render badly.

Your idea to use SVG would be a great improvement for Jocly but I'm not sure how feasible it is. I assume you already have an idea of how to do it.

I confirm that the order of PiecesFromFEN work as expected. I have tested and modified grand chess but not commited it yet.

I also confirm that the default in wild-mirza-600x600-2d.jpg comes from windows resizing in joclyboard. The visual is modified. but of course the problem remains.

I saw that you'd managed to pull the refactoring of the doc to your branch. That's a good news. Let me know if there's any point in my continuing to refactor the docs of chessbase/decimal and chessbase/shogi directories, or if there are more disadvantages than advantages because of the risk of conflicts.

I saw that you'd managed to pull the refactoring of the doc to your branch. That's a good news. Let me know if there's any point in my continuing to refactor the docs of chessbase/decimal and chessbase/shogi directories, or if there are more disadvantages than advantages because of the risk of conflicts.

I had no merge conflicts with the docs; just with the fairy-set-view and sprites. So it is fine if you go ahead, as long as I will stay away from it.

@François: I have now committed rule descriptions for Minjiku Shogi and Makromachy. They refer to many images for the participating pieces that do not exist yet, though. The images that do exists are all in res/rules/fairy. I suppose that we would want a complete set of images for the entire fairy-set-view in that directory, with their 2d and 3d representation side by side.

For the pieces generated by the Tube program it is still a bit early to do that, as their 3d appearence might still be improved. There are many other new pieces for which these could be made, though. Did you plan on making those, or shall I do it?

Yes I will try to help to fill res/rules/fairy, I don‘t know yet how I'm going to get the 3d images consistent with the rest though.

for tube unfortunately I am not yet able to be useful so far.

I suppose we would have to define a variant with a board that is all white, with the desired pieces, and take screenshots. Let me do that.

As for automating the cbMoveMidZ, the problem is that this is in the View part, and that it is not clear how execution of code there is timed compared to that of the model part. So we cannot overrule the code there from fairy-move-model; the default might very well overrule that. And I don't want to make a fairy-move-view just for this purpose.

So perhaps we should just change the default in base-view.js for a more advanced one. At the time it is defined the moves of the pieces are not known, but since this code is only executed when Jocly is going to animate a move it does not matter wheter it takes microseconds or milliseconds. So we can have it examine the relevant move graph every time it is called, and let it jump to distant destinations that are directly accessible or a hopper capture, and slide otherwise.

I pushed a first draft. I can easily improve some image if necessary

yes probably best in base-view.js