Ratings & Comments
Done!
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Stairchess960
To BenR: Maybe this can be both?
To David mRcpR: Why is that a problem? What about Pawn on h-file which cannot move forward? Edit: I didn't see HGM's Interactive Diagram when I was creating an Interactive Diagram for this. To HGM: Shouldn't the pawn beiiflmnDflmWflceF
?I beat you by 4 minutes! :-)
It is interesting how we both chose a different rectification of the board; mine spoils the coordinates, yours spoils the moves of the pieces. In your representation it would in principle be possible to use a whole-board image as background that has the original diamond-shaped cells.
I tried using the Atlantic SVG set through fen2.php, but this set is not suitable for use on a black-and-white board. (Alfaerie doesn't do so well either, on the dark squares...)
[Edit] Concerning Pawn: Ah yes, I had overlooked that detail in the description. Thanks!
Talking about background it doesn't seem to work on my device even though it used to work. Interactive Diagrams that use backgrounds like Eurasian Chess, Chak, VaoQi don't seem to have backgrounds on my device.
Note that it is possible to control the way the captured pieces are placed next to the board by defining arrays Model.Game.handLayout[color][handIndex]. This array should contain the square numbers where you want the first captured piece of the given color (1 or -1) and hand value to be placed. (A second piece will be placed at sqr+color, and after that counters will appear between the two shown pieces.)
Currently the default assignment is used, which places the white pieces on the first 'file' on the right of the board, the hand number equal to the rank number (which starts at 0). By defining a handLayout you could also use the ranks under or above the board to place pieces, thus requiring fewer extra ranks.
E.g. with a single extra rank (instead of the 4 you have now) you could place 6 white pieces below the board, and 14 white pieces to the right of the board.
It's good to know that you can use the bottom squares for that. Does it mean that we have to specify something like Model.Game.handLayout[1][{2:18,4:17}]; // eg : square 2, hand 18 for the white for each piecetype?
No, you have to write something like
Model.Game.handLayout[1] = [0,2,4,6,8,10,12,14,30,46,62,...];
if you want the first 8 'hand squares' for white to be at the bottom, and the rest along the right edge.
I gave it a try here. I think It looks better this way.
@Adam: apart from the adjustments linked to the changes, what do you think?
I guess the drop model still needs some tweeking. The square painting on the hand ranks should be the same as that of the other hand squares. Now there seems to be no coloring at all, so that the rim texture shines through. I suppose the logical way to do this is that the square-painting array that has to be defined in the game's view file should include the extra ranks.
It is also not clear to me why the 'counter piece' in the lower-right corner is larger than the others.
[Edit] The array boardLayout defined in the view file is accessed in two places in grid-board-view.js, inside nested loops over rows and columns. The loop over rows was modified to skip the extra hand ranks. I suppose this was a bad idea; especially in the 'paintCells' function it should have run over all ranks, requiring the boardLayout to also specify how the cells in these extra hand ranks should be colored. There is a second routine 'paintInCoordinates' that also loops over all cells, which does more complex things and might need more subtle modification than just changing the loop limits. But it seems this function is not normally used.
The handLayout[-1] in the view file appears to have a 16 where there should be a 17, which causes misplacement of the 'counter piece' on 15 rather than 16.
The change in paintCells was necessary because the grid wouldn’t display. May be that a better modification is possible, but I don't think I'm in a position to make it.
After a few modifications, current result
I don't know if you'd like to have a look at sources : latest to check grid-board-view.js
Your current setup for this game looks way better, but I did notice a few errors were made while making the new version. I also noticed a bug in the Hectochess implementation.
---------------------
Chu Seireigi Setup Errors
---------------------
White Kirin and Phoenix are swapped from where they should be in the initial setup
Black King and Great Elephant are swapped from where they should be in the initial setup
---------------------
Chu Seireigi Promotion/Drop Errors
---------------------
Pawn, Lance, Running Rabbit, Knight, Gold General, and Great Elephant are currently allowed to promote immediately if they are dropped into the promotion zone (this should not be the case)
White Copper General is put in same place as Black Lion in hand spaces, resulting in the hand space setup looking asymmetrical (White Copper General should be placed between the Great Elephant and Running Wolf)
(Also, because of this bug, a "King" may sometimes appear in current hand space of extra White Copper Generals/Black Lions for some reason...though this thankfully doesn't affect anything)
---------------------
Hectochess Castling Error
---------------------
When attempting to castle, the Champion's starting squares (b2/b9 and i2/i9) and queenside Knight starting squares (c2/c9) are not checked to see whether a piece is occupying them or not.
I think that all that is needed is to make the 'row' loop run from 0 to NBROWS, and remove the -NBVHND from
this.cbView.boardLayout[NBROWS-NBVHND-row-1][col]
And then putting the extra hand ranks in the boardLayout defined in the game's view file. I don't think there are any other games yet that use extra hand ranks. I implemented that feature with Wa Shogi in mind.
The paintCells function is not involved in drawing the grid.
I had already looked at the sources, by looking at the chu-seireigi-view.js of the compiled version. Since you build Jocly without uglification all used source files are in there unmodified.
In that case : I get in 2d with pictos
Would this come from using the draw function wrongly in my view : chu-seireigi-view.js ?
Note that I have the impression that with the modified version the result is satisfactory with or without extra hand ranks.
That's why I'd like your opinion on grid-board-view.js, because I thought it would be useful to transfer this modification to the pullreq branch for jocly.
If you'd like to make an implementation of wa shogi, here are some unused jocly-compatible sprites that might come in handy.
To be seen if useful
This sounds like an out-of-bounds access on boardLayout. Are you sure you defined that array with sufficiently many ranks? To further diagnose the problem you could add console.log(NBROWS-row-1); just before the access to boardLayout in paintCells; then you could see in the console what the offending value is.
the array length is 19
NBROWS-row-1,row: 13, 0
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Strange. 13 should be a valid index for an array of length 19. That means the array should have some internal elements that are undefined. What happens if you print
console.log(
)?19 is the size of handLayout
boardLayout :
0: "##............##"
1: "##............##"
2: "##............##"
3: "##............##"
4: "##............##"
5: "##............##"
6: "##............##"
7: "##............##"
8: "##............##"
9: "##............##"
10: "##............##"
11: "##............##"
length: 12
Should I add : Should I add " ##############" before and after?
Should I add : Should I add " ##############" before and after?
Indeed, you should, because you want the extra hand ranks to be colored black as well.
thanks for the advice.
I have modified accordingly
Looks good, save for a few errors:
---------------------
Setup Errors
---------------------
White Kirin and Phoenix are swapped from where they should be in the initial setup
Black King and Great Elephant are swapped from where they should be in the initial setup
---------------------
Promotion/Drop Errors
---------------------
Lance, Running Rabbit, Knight, Gold General, and Great Elephant are currently allowed to promote immediately if they are dropped into the promotion zone (this should not be the case)
Both Pawns in the hand spaces can be selected when multiple Pawns are in the hand)
It should be ok now
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Looks like it. I have uploaded the new version to the site and have adapted them so the implementation will work properly with the CVP files.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Flying pieces still do not fly!
They work the same as in the interactive diagram, only jumping over enemies.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Ok, I thought it is like in tenjiku shogi!
Sorry, I was wrong. The real explanation is that they only jump to capture. It works correctly anyhow.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Note that the SVG for laser cutting is updated with a rabbit.
Also the doc has been improved a bit in jocly.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Thanks.
Out of curiosity, what program did you use to make the Seireigi Jocly sprites?
I am trying to fix a visual bug involving the 2d Kanji kings in Seireigi's implementation. The King with the extra stroke in the 2D Classic set is used for the player that moves second, when it should be used for the player that moves first.
I use gimp. if the general of jade should be white (player a), it could be changed in seireigi-shogi-model.js
keep me posted I'll have to make the change too.
You should only have to swap the King kanjis in the 2D Classic Seireigi sprites.
For the 3D pieces its as simple as swapping "sh-king" and "sh-jade" in the 3D piece definitions in the *-view.js files, so no problem there.
P.S. What I said above also applies to the Shogi Jocly implementations that use the King kanji on the biscandine site.
P.S.S. Also you have two extra rooks in your laser cutter SVG.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
you can also swap the 2d in the same *-set-view.js
It not clear to me, when there's an apostrophe, it's the general of jade that corresponds to the blacks, right?
It not clear to me, when there's an apostrophe, it's the general of jade that corresponds to the blacks, right?
In kanji sets, the player that moves first always has the King with the extra stroke. And it is true that the player who moves first is called Black (or Sente) in Shogi. It's just that in Jocly and the Mnemonic sets by H. G. Muller, the player that moves first has the white piece images by convention to make it easier for chess players.
I made the modification on my branch,
I'll wait to see if HGM wants us to do the same on the branch that will go into jocly.
The Wikipedia has it that the player with the weakest player has the Jade General, and the strongest player the King. I am not sure if and how we should implement that in Jocly.
I'll send you an updated pictogram spritesheet that you can use. Currently, the pictogram images still have the Kanji for the Kings since they are pulling from those locations.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Here is my updated version of your spritesheet. (For best results, clear browser cache before downloading)
I also took the opportunity to clean up stray pixels in your other shogi spritesheets.
www.chessvariants.com/membergraphics/MSchuseireigi/jocly-shogi-sprites.zip?nocache=true
do you want me to replace the sprites Adam just sent for shogi on the pullreq branch?
ok, taken into consideration
I also updated the seireigi-sprites file one more time so that the promoted Kanjis are all facing the right way.
www.chessvariants.com/play/jocly/dist/browser/games/chessbase/res/shogi/seireigi-shogi-sprites.png
P. S. GIMP is awesome.
I have done it but not sure it is a good idea because if you use "view as player B". It won’t be correctly oriented.
62 comments displayed
Permalink to the exact comments currently displayed.
This is an excellent concept. There's just one tweak I'd like to see. Pawns on the a-file cannot move any further to the left, so that could be a problem. One way to remedy that might be to divide the board vertically down the middle, giving pawns on files A-D a move to the RIGHT, and on files E-H to the LEFT, as you have currently done for all pawns.