Shogi in Unix/Linux?

[Josh Pettus]

Hey HGM, I noticed that you had two engines on your site, GNU Shogi and Bonanza. I was wondering if any of them could be compiled on Linux and thus on OSX. I was thinking about making another xboard app package for Shogi, but it looks like both engines are only set up to be done through cygwin at the moment. Any other engines come to mind that might work? Would be willing to let me compile shokidoki on mac? UCI2WB compiles just fine, but I don't know of any free open source shogi engines that would need it.

Also on another note, for your shogi winboard package you mention a shogienese language file for winboard. Does this work with xboard as well? If so, where can I get it and how would I activate it?

[H.G.Muller]

Bonanza should compile without problems on Linux. It originally came with both Linux and MSVC makefiles. My modifications have not broken that, and in fact I did develop them on Linux. It was actually compiling on Windows that caused me great grief, as I don't have MSVC, and using Cygwin caused many errors, because the switches between platform-dependent alternative depended on WIN32 and MSCVER as if they were the same. So I had to make a lot of hacks to make it compile under Cygwin, which I did not include in the on-line repository.

As to GNU Shogi; this has always been primarily a Linux development, as all GNU stuff. The project has recently been revived at GNU, and is in a flurry of activity. (And I am even part of the development team.) I think my changes should not have broken the ability to compile under Linux; I was careful to put all Windows-related changes under #ifdef WIN32 control. But the version now on GNU Savannah (xboard branch) contains all these changes in a cleaner way, plus a lot of patches I was not aware of, developed by the Debian Maintainer (Yann Dirson), who now also is administrator of the Savannah project. If you wait a few days, it will probably also integrate the mini-Shogi patch into the master branch. And I plan to still add an XBoard 'analyze' command to it. But none of that will change the fact that GNU Shogi is the worst Shogi engine known to humankind.

GPS Shogi is an open-source USI engine. I would be surprised if it didn't come with provisions to compile it for Linux. I have never tried to compile it myself, though; UCI2WB worked fine for it. Unlike Bonanza, which is not USI, and could only be run by tandem adapters, u2b.exe converting it into a flaky USI engine (e.g. without only second time resolution).

And yes, you can compile my Shokidoki code for Mac. I have a bit of an e-mail problem currently, so I cannot easily mail it to you. I will think of something.

Btw, the latest development version of XBoard also supports Chu Shogi, and soon we will also have a set of SVG kanji pieces for it. My engine HaChu that plays it (as wel as Dai and Sho Shogi) is open source now, and also available from my on-line repository. Perhaps it would be an idea to include that in a Shogi package as well.

[Josh Pettus]

Thanks for all the info

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.

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


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:295:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:295:junk `(%rbp))' after expression
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:377:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:377:junk `(%rbp))' after expression
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:390:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:390:junk `(%rbp))' after expression
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:423:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:423:junk `(%rbp))' after expression
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:436:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:436:junk `(%rbp))' after expression
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:588:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:588:junk `(%rbp))' after expression
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:601:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:601:junk `(%rbp))' after expression
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:867:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:867:junk `(%rbp))' after expression
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:880:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:880:junk `(%rbp))' after expression
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:902:Missing ')' assumed
/var/folders/pr/m2kftwhn4vjb23fj3zw9h8600000gn/T//ccCaNh2r.s:902: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

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.

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.

[Josh Pettus]

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’:
floodgate.c:599: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘char (*)[80]’
floodgate.c:599: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘char (*)[80]’
floodgate.c: In function ‘StartPeerThread’:
floodgate.c:647: warning: passing argument 3 of ‘pthread_create’ from incompatible pointer type
Undefined symbols for architecture x86_64:
  "_Sleep", referenced from:
      _WatchDog in cc4QTjrJ.o
      _ClientProc in cc4QTjrJ.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

[H.G.Muller]

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.

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.

[Josh Pettus]

Thanks for all your help! I downloaded gcc48 via macports and switched, after that everything compiled just fine. You were right about GnuShogi, I missed the autogen.h file. GPSShogi compiled but it has a really weird setup where it put itself in an application package, which wasn't what I hoping, and the executable has compile issues, not much you can help me with.

Bonanza has a few issues. when playing it easily reaches it's hash limit and stops moving. Do you know how to increase the hash size? on top of that it constantly must write log files to a log file which will just get larger and larger with every use. can this be disabled? also the game spew? is that book learning?

hachu (another great name btw) compiled just fine, and works nicely! I remembered to strip the binary and also made everything run on os 10.6.

[H.G.Muller]

You are right, I did not translate XBoard's memory command yet to Bonanza's native 'hash' command, so it just ignores it, now. That should be pretty easy to fix, though. I will have a look at it tomorrow.

[Josh Pettus]

Silly question, but why do we say "Black" moves first? Since we are defining shogi in FIDE terms that have actually no relevance to shogi, why not actually define it in FIDE terms? It drives me nuts! And xboard too for that matter. 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 .

I have been looking at chu shogi rules on your webpage, (beautiful job btw) as well as wikipedia, and I got to say. I highly doubt I will ever be able learn the Kanji pieces. 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.

[H.G.Muller]

XBoard does define it in FIDE terms, and it calls the side that moves first 'white' in any game. I also think it is quite silly to 'translate' sente as black and gote as white, when both sides play with the same color pieces, and sente and gote do not refer to any color in Japanese.

It seems, however, that in Japanese Shogi literature it is customary to symbolize sente with a small solid triangle, and gote by an open triangle. (And usually the paper is white, and the ink black...)

It is true that in general western Shogi players seem to get a kick out of being incompatible. They indicate ranks by letters, files by numbers. The Japanes use numbers for both (but Western and Japanese numbers). While Chinese Xiangqi engines use UCI protocol like it is, the protocol was mutilated for Shogi, insisting that engines should use 'usi' and 'usiok' in stead of 'uci' and 'uciok', use 'sfen' in stead of 'fen', etc.

As to the kanji: I can assure you from experience that sooner or later you will pick it up after watching many games, even when you never make any conscious effort. For the unpromoted pieces, that is. It helps that some pieces virtually never move, (the Lance and Reverse Chariot). But it is a lousy way to play the game, and IMO using this equipment will lower your rating by some 300 points compared to using a better representation. That is not so much because of the kanji, but would also be the case if the the tiles had the piece names printed on them in English. To interpret a position at a glance it is essential that the pieces for each side have different colors, and clearly distinguishable shapes. These were the criteria I used in designing my mnemonic piece set, and are even more important than the fact that you can read the moves from the pieces. The conventional 'westernized' Shogi tiles are just as hopeless as the kanji pieces. They are still all the same color, and still all pentagonal...

Unfortunately the mnemonic pieces look completely unfamiliar, and this scares of people before they realize how easy they are. This is why for XBoard I implemented Chu with Chess-like pictograms, despite the fact that only 5 of them wold look familiar to Chess players. In the poll I conducted on TalkChess, there was a clear preference for the pictograms.

I tried to build some mnemonic content even into the pictograms.

[Josh Pettus]

That really is funny about the ranks and files system. I don't get it. I understand being authentic to the culture and the game. Particularly the years of thought behind would all be in Japanese. But using a reverse FIDE system solely for the purpose of being backwards and making it difficult to communicate to FIDE players, that's just silly..

I'm sure you are right the more I play Chu it the more I'll pick it up. What a crazy game. You really did a great job with the pieces. I must say this is where SVG and Cairo really shine. Could you imagine having to do all those board sizes for all those pieces?

As to shokidoki, have you thought about dropbox? It's a really easy to use file storage/distribution and gives you a lot of freedom. I especially like the OS integration where all i have to do is drop my file in a folder and it automatically syncs making it great for projects with small groups of people. To distribute all you have to do is right click on the file, it gives you a link and you can post it where ever you want. PM'
s for example. Then you can move the file yourself out of the dropbox and it stops hosting right away.

[H.G.Muller]

I pushed a new bonanza version to the hgm.nubati.net repository that should obey the memory command. I couldn't test the Linux compile, as the makefile is set to compile with SSE 4 enabled, and my Linux machine is only Pentium-M, so it crashes immediately. But I expect it to work, as it was a completely trivial change.

[Josh Pettus]

Exellent! sorry it took me a little bit. I just updated to the latest macos 10.9, which borked everything and I had to reinstall macports from scratch. On top of that most the binaries have not been pre compiled so getting gcc48 setup again took forever.

Anyway here is the Shokidoki, I made sure to make it's target 10.6 so anyone who wanted to compile xboard for themselves with 10.6 and later wont be left out. I also remembered to strip the binary and deleted your pm for safety's sake.



Bonanza gave me a funny error when I tried to compile it. Apparently I was successful with the master branch before but the 6.0 one isn't working

Code: Select all

Joshuas-MacBook-Pro:bonanza-0736144 herecomethej$ make gcc
/Applications/Xcode.app/Contents/Developer/usr/bin/make CC=gcc CFLAGS='-std=gnu99 -O2 -Wall -DNDEBUG -DMINIMUM -DHAVE_SSE4 -msse4.1 -DDFPN -DTLP -DDFPN_CLIENT -DINANIWA_SHIFT -DMNJ_LAN -DCSA_LAN -DXBOARD -DMPV' LDFLAG1='-lm -lpthread' bonanza
make[1]: *** No rule to make target `bitop.h', needed by `data.o'.  Stop.
make: *** [gcc] Error 2

Does the make file need updating? As far as I can see there is no bitop.h, so why does it want it?

[H.G.Muller]

I guess I must have forgotten to put that file in the repository. I will add it. It is not modified, so if you are in a hurry you could use the bitop.h from the original v6.0 distribution too.

[Josh Pettus]

Ok thanks!

I found the bonanza 6.0 source code

also missing are:
dfpn.h
dfpn.c
dfpnhash.c

Of course now the new bonanza quits with

"Illegal instruction: 4"

Does that mean anything to you?
Thats running it via command line. Xboard says it just closes.

[H.G.Muller]

I guess you have to remove some of the compile options from the Makefile; -DDFPN and -DDFPNCLIENT, -DCSA_LAN and -DMNJ_LAN. And perhaps add -DNO_LOGGING.

I don't know what CPU you have. If it is an old one, it might not support SSE 4 instructions, and choke on those. In that case you can also remove the -DHAVE_SSE4 and -msse4.1 flags. Or include compiles both with and without it in the package.

I grabbed the zip file, btw.

[Josh Pettus]

Thanks! Yah, my cpu is an intel 2 core duo, It doesn't support SSE4, which was the issue, but it does support SSE2, which is pretty common, so I'll just build it with that.
proce.c wouldn't even compile without the -DMNJ_LAN flag. various undeclared identifies. But thankfully that wasn't an issue for it running. I did remove everything else as you suggested. And the log thing will come in handy.

Thanks for letting me know about the zip file I'll remove it. I'll leave hosting it to you

[Josh Pettus]

Well I edited the svg kanji images a bit thought you'd like to take a look
https://dl.dropboxusercontent.com/u/50486448/kanji.zip
Essentially I made all the promoted pieces red which was how my board at home is like. I know not all sets are like this but I find that it helps myself.

Second i gave the little mark on the right side of the white king marking sente. As to this I don't know, as it isn't properly reflected when you flip the board in flip black mode. I see it's just set to reverse the positions and not the pieces. It would be nice if it worked. But i guess it is pretty minor.

I took a look at the gettext stuff and thought it to be real overkill for what I wanted to do. (Not to mention beyond my ability)
So instead, I went into xboard's dialog.c and changed the instances of what appeared regarding to the clocks from "White" to "Sente 先手" and "Black" to "Gote 後手." It came out rather nice, and being a non-coder, I'm rather proud of myself. But even though it's a minor change does this mean I'd have to include the xboard source code inside the app package?

[H.G.Muller]

I guess formally it means that. A good way to see that this will not be a burdon is to create a patch file describing the difference. You can make this with the command

diff -u originaldialog.c dialog.c > x.patch

when you also keep the original version (it could be in another directory). You can then simply include the x.patch file with the distribution. It will be very small, and people can feed it as input to the 'patch' command to make the changed version from the original one.

I guess the Bonanza identifiers could not really have been undeclared, because that is a fatal error and would abort the compilation process without producing a binary. Are you sure you are not running a version that already existed somewhere? Best if you would post the error messages here...

As to the implementation of flipView: currently the -flipBlack option just swaps black and white pieces. Unlike in WinBoard, where it really flips them upside-down. The problem is that what you need depends on the piece images. Before switching to Cairo, XBoard was using the xShogi piece graphics, which has 3d drawings of the pieces. If you would flip those, the board would look if the pieces were hanging from it! Arun dug up the current SVG set from some other open-source project, and for these flipping would work. I don't think they are particularly nice, though. So I was hoping that at some point someone would make the effort to convert the xShogi bitmaps to SVG. I was told that inkscape should have a function to do this automatically, but I am a complete novice to inkscape.

The swapping of white and black pieces interferes with having different King images, however. I thought having them the same would be an acceptable solution. Because it is NOT that the two alternatives belong to a specific side. E.g. always giving sente the king and gote the jeweled general would still be wrong 50% of the time in the eyes of the Japanese. Who gets the King depends on status of the players, not on who has the first move...

So actually it seems a feature, rather than a bug, that you can change this! We should set it up such that the player with the lower status always plays down. (An alternative would be to use a 4-cycle flip view, like I did in the WinBoard Alien Edition for Dark Chess, where you first get two orientations with the full board visible in EditGame mode, and then two orientations with the opponent blacked out. We could first make it such that every other flip swaps the King. But that would require us to have images for both Kings in both orientations.)

This reminds me of the fact that we also do not have Elephants yet, with the Shogi piece set. They would be needed for Sho Shogi.

[Josh Pettus]

Thank-you for the suggestions.
A patch file would probably be a good idea anyway, as the current build i'm using will change when ever you feel like it And it could save me a bit of time looking up the japanese and changing those 8 lines every time.

For Bonanza here is the output with -DMNJ_LAN removed

Code: Select all

gcc -c -std=gnu99 -O2 -Wall -DNDEBUG -DMINIMUM -DHAVE_SSE2 -msse2 -DTLP -DINANIWA_SHIFT  -DXBOARD -DMPV proce.c
proce.c: In function 'update_exclude_list':
proce.c:186:7: error: 'moves_ignore' undeclared (first use in this function)
   if( moves_ignore[0] == MOVE_NA ) { // nothing is excluded yet; make a copy of root move list;
       ^
proce.c:186:7: note: each undeclared identifier is reported only once for each function it appears in
proce.c: In function 'cmd_undo':
proce.c:610:3: error: 'moves_ignore' undeclared (first use in this function)
   moves_ignore[0] = MOVE_NA; // [HGM] exclude: exclude list cleared for new position
   ^
proce.c: In function 'cmd_exit':
proce.c:660:3: error: 'moves_ignore' undeclared (first use in this function)
   moves_ignore[0] = MOVE_NA; // [HGM] exclude: exclude list cleared after analysis
   ^
proce.c: In function 'cmd_move':
proce.c:1603:3: error: 'moves_ignore' undeclared (first use in this function)
   moves_ignore[0] = MOVE_NA; // [HGM] exclude: exclude list cleared for new position
   ^
proce.c: In function 'cmd_new':
proce.c:1621:3: error: 'moves_ignore' undeclared (first use in this function)
   moves_ignore[0] = MOVE_NA; // [HGM] exclude: exclude list cleared for new position
   ^
make[1]: *** [proce.o] Error 1
make: *** [gcc] Error 2

Another thing, even without -DFPN and -DFPN_CLIENT, dfpn.c, dfpn.h and dfpnhash.c are still needed from the bonanza 6.0 so long as dfpn.o and dfpnhash.o are in the OBJS list. I don't think It does any harm to omit them but you would know better then I.

I actually thought about taking a look at that Shogi font and seeing if I can convert it, and making it into svg pieces. You're right, the current images don't really look all that great, and a simple boarder around them would do them wonders. I now have a little experience with inkscape. It really is a neat program. I'll take it on. I do know that has both kings in both orientations. I'll see if I can cobble something for the elephant while I'm at it. Still would be quite a challenge to get right. Would have to create the background of the piece somehow.

I had no idea about sente and gote with the King and Jeweled General's that's good to know. (Is it just me or that makes Sente = Black even more silly!) WIkipedia was a little vague on this. My understanding was basing it off of other shogi programs I have seen, where the Jeweled was always sente. I guess that is their solution.

[H.G.Muller]

Well, this is bad, as it has to do with the exclude-moves feature I implemented. Probably I have forgotten to commit a change in a header file to the repository.

That it still tries to use files after switching off the code that calls the routines in them with a compiler flag is basically a defect in the Makefile. I will include the files in the repository as a fix, though.

I guess all this trouble originated because the previous version of Bonanza did not have those files. I just unpacked the 6.0 tar ball in the directory where before Bonanza Feliz was sitting, and let the 'git' version-control system notice all the changes. But it only notices changes in files it knows belong to the project, and ignores new files. But that never bothered me when compiling, because the files were there...

I will try to fix it this evening.