H. G. Muller wrote on Sun, Dec 23, 2018 10:48 AM UTC:
In WinBoard I use the Unicorn image as the Royal Knight in Knightmate, so I was probably thinking of that. The Camel-Zebra compound is usually referred to as Bison, but the lame multi-path version of it is George Duke's Falcon, and in WinBoard I use the letter V for the Falcon symbol. (Because F was already taken by Ferz, and Dutch for Falcon is 'Valk'.) Not sure why I gave S the same move. Anyway, the main idea of the piecedef.ini file was that people could put their own piece definitions in there.
Note that the basic version of the generator assumes total symmetry and an 8x8 board. If you undefine the symbol DIAGSYM in the source code and recompile it would only assume 4-fold symmetry. This is not only needed for doing less symmetric pieces, but also for non-square boards. The way diagonal symmetry is implemented is leaning very much on the board size being 8x8, because it extracts the X and Y coordinates of the pieces by masking out groups of 3 bits from the index (through the RANKS and FILES masks) to be able to swap those. Even without diagonal symmetry it would not be so easy to adapt to other board sized; e.g. the tables bcode[] and deltaVec[] assume '0x88' square numbering, and would have to be changed.
FairyGen doesn't use any bitboard techniques, so the fact that the word length of a computer is only 64 bits in principle should not pose any limitation. It is just that everything having to do with square numbering and index calculation would have to be changed.
In WinBoard I use the Unicorn image as the Royal Knight in Knightmate, so I was probably thinking of that. The Camel-Zebra compound is usually referred to as Bison, but the lame multi-path version of it is George Duke's Falcon, and in WinBoard I use the letter V for the Falcon symbol. (Because F was already taken by Ferz, and Dutch for Falcon is 'Valk'.) Not sure why I gave S the same move. Anyway, the main idea of the piecedef.ini file was that people could put their own piece definitions in there.
Note that the basic version of the generator assumes total symmetry and an 8x8 board. If you undefine the symbol DIAGSYM in the source code and recompile it would only assume 4-fold symmetry. This is not only needed for doing less symmetric pieces, but also for non-square boards. The way diagonal symmetry is implemented is leaning very much on the board size being 8x8, because it extracts the X and Y coordinates of the pieces by masking out groups of 3 bits from the index (through the RANKS and FILES masks) to be able to swap those. Even without diagonal symmetry it would not be so easy to adapt to other board sized; e.g. the tables bcode[] and deltaVec[] assume '0x88' square numbering, and would have to be changed.
FairyGen doesn't use any bitboard techniques, so the fact that the word length of a computer is only 64 bits in principle should not pose any limitation. It is just that everything having to do with square numbering and index calculation would have to be changed.