Darklord42 wrote:What of the language file in xboard? It would be really nice to have Sente and Gote as oppose to the confusing white and black.
XBoard relies for internationalization on gettext and the GNU translation project. I know nothing about how to make translations of XBoard. What I do know is that all this stuff is in a sub-directory po of the source tree. There is an xboard.pot there, which seems to be an empty translation, and a number of po files derived from it for various languages. There also is a file LINGUAS that seems interesting.
I was confused by GNU Shogi as the install file only referenced the cygwin make. I didn't realize you had to type
make gnushogi
However, make doesn't appear to like the make file very much as I get this.
- Code: Select all
make: CC@: No such file or directory
make: *** [attacks.o] Error 1
Have you run ./configure first? Which version exactly are you compiling? The xboard branch from Savannah?
Bonanza tries to compile but gets an error when it trys to compile thread.c
- Code: Select all
gcc -c -std=gnu99 -O3 -Wall -DNDEBUG -DMINIMUM -DTLP -DCSA_LAN -DMNJ_LAN -DXBOARD -DMPV thread.c
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:282:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:282:junk `(%rbp))' after expression
...
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:915:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:915:junk `(%rbp))' after expression
make[1]: *** [thread.o] Error 1
make: *** [gcc] Error 2
Those are very strange errors, coming from the assembler when it tries to transform the gcc-generated .s files from assembly into binary machine code. It looks like you somehow have a mismatch between compiler and assembler, so that the compiler generates assembly code that the assembler does not understand. It is hard to diagnose the problem without seeing the actual assembly file (which now is in some temporary-file directory, where it probably is automatically deleted); perhaps you could try to generate it by running gcc with the same arguments as when it produced thi error, but with the extra flag -S so that it saves the .s file. And then hope that the line numbers still are the same.
On Ubuntu 10.04 I don't have such problems at all; 'make gcc' works with a few warnings. The resulting executable crashes, however, since I run Linux on an old laptop with Celeron-M CPU, which doesn't have SSE4.1, which the makefile apparently says I have.
[qoute]Thanks for the tip about GPSShogi. It's huge, unfortunately my poor computer hangs while compiling it, I suspect it has a GUI of it's own that's part of the whole thing.
perhaps an issue with the compiler. Ill keep trying it though.[/quote]
Well, I never tried to compile it, (or even download the source), so I can offer little assistance here. The Bonanza stuff does suggest there is something seriously wrong with yor compiler, though. I did check the threads.c file, and it seems just plain C-code (no explicit assembly code inserted by using asm{} directives). So any faulty assembly code in the .s file must have been generated by the compiler.
I'd love to include chu shogi, perhaps the mini shogi as well. Is there any reason that isn't an actual variation? Does Chu Shogi share any of the same pieces as regular shogi? If so I take it the Kanji pieces will match those of regular shogi.
Chu Shogi has most of the pieces of regular Shogi, except Knight, and the promotetd Knight, Lance, Silver (because these promote differently in Chu). That doesn't help very much, as Chu Shogi has 36 piece types (which actually uses 40 different Kanji faces), of which only 10 are shared with regular Shogi (P, L, S, G, K, B, R, +P, +B, +R). Some could be derived by merely changing the kanji color (e.g. DH and +B use the same kanji, as do DK and +R, but th former are black, and the latter are red).
I never added mini-Shogi as an independent variant, because it was possible to configure XBoard for playing it with the aid of the regular board-size and pieceToChar overrides, and I wanted to limit the proliferation of variants. The same holds for Sho Shogi, which can be played as variant shogi with holdings switched off, and an extra Elephant in the pieceToCharTable. If every tiny difference like that would leas to a new variant, we would quickly have hundreds...
The development version of XBoard has a novel mechanism that allows engines to define nonstandard variant names in their variants feature command, which will appear in the New Variant dialog as choices, and which on selection expect the engine to define the 'parent variant', board & holdings size, pieceToCharTable and initial position by sending a 'setup' command. With this mechanism variants differing only in the last three of these parameters can all be mapped to the same parent variant (which, for instance, defines whether capture is mandatory, whether you win, lose or draw on stalemate, checkmate or King baring, if pieces explode after capture, how deep the promotion zone is, etc.). Then only a limited number of parent variants have to be explicitly programmed into XBoard, and the user still gets the service he is used to. (If he is running with an engine, that is.) In the future we might even allow the engine to modify parent variants, (e.g. by specifying a nonstandard promotion zone), perhaps even in such detail that all variants can be derived from variant normal.
For now it seems best to use the old mechanism of making an .ini file with the required overriding options, and referring to a .fen file with the initial positions, and refer to that on the engine line in the engine list. (e.g. "-fcp shokidoki @mini" for mini-Shogi, or perhaps the -fcp could even be specified in the mini file, the latter being renamed to mini.xop, so that people could start Shokidoki for mini-Shogi by simply clicking that .xop file.) Because mot of the engines (even Shokidoki) won't use the new mechanism yet.
Darklord42 wrote:I tried to compile hachu with this
gcc -O2 floodgate.c hachu.c -o hachu
is that correct?
I get this
- Code: Select all
floodgate.c: In function ‘ClientLoop’:
...
Oops, this is an error. Floodgate.c does not belong in that package at all, it is a completely different program that should never have been made public. You should just compile hachu.c.
Posted: 19 Oct 2013, 00:44
I bet it is because of ideas of who is thought of as the defending player. (Edit: If it were the case then it would be at least understandable. But looking into it with the actual general names, I don't think it is!) But it's still silly. If it's being renamed for the sole purpose of practicality for non-japanese speakers, then let it be practical. It would be so much better to point to the general with the little notch on the right and say to my fellow chess player, "that guy is white." But instead I have to tell him, "That guy is black but he moves first" And he thinks I am being stupid because they are ALL black. And he will say, "Then why not call it white?" To which I have to reply, "I don't know, go with it." Apparently some western player didn't think shogi was unique enough and so added further arbitrary uniqueness .
Not with out extensive study in the Japanese language at least. The only reason I managed to learn modern shogi pieces was the convenient similarities to the Chinese symbols in Xiangqi added the extra context. But with Chu Shogi there are just too many pieces! It's hard enough to learn the pieces themselves, and what they promote too.