Op Wo, 12 februari, 2014 10:38 pm schreef Yann Dirson: Hi Yann,
I will move GNU SHogi to the top of my priorities list this weekend, as otherwise I just don't get to it. I went sort of manic on XBoard the past few weeks, as I finally figured out how to do one of the features that was still on the wish list for the GTK version (ICS output not in the x-term but in its own dialog window, where it can have appropriate callbacks). And then I got distracted by another pet-project of mine, on-the-fly tablebase generation. Let me first comment on (some of) your remaks on XBoard-experimental: > > * games defaulting to hachu (@chu and @sho) look OK > * games defaulting to gnu(mini)shogi require xboard support, I'll > upload a gnushogi master snapshot into experimental as well; they work well > with the correct binaries in $PATH > * @mini should I think default to japanese theme Mini-Shogi is not an officially-defined variant of XBoard, and thus needs some user configuration to be played. In cases like that, it seemed best to separate the theme config file from the rules config file. (I guess the same in principle holds for Sho Shogi, but I probably figured that there would be no interest outside the traditional Shogi community for that anyway. While for mini-Shogi I see a good future, provided that people get the opportunity to play it in a 'kanji-free version'.) The need for user rule configuration would disappear completely if GNU miniShogi would use the engine-defined-variants feature of XBoard-exp, however, and I think this is the way to go. I should simply announce feature variants="mini,5x5+5_shogi" and respond to the "variant mini" command with setup (P.BR.S...G.+.++.+Kp.br.s...g.+.++.+k) 5x5+5_shogi rbsgk/4p/5/P4/KGSBR w 0 1 Then it could be played by simply selecting "mini" from the New Variant menu, and no rule configuration would be needed anymore. The 5x5+5_shogi would only be mentioned in the variants feature for compatibility with older interfaces and older engines. (E.g. if you want to play engine vs engine, and the opponent engine would not support 'variant mini'.) Then only theme configuration would remain, and you could use @shogi for that: xboard @shogi -fcp gnuminishogi would overrule gnushogi as default engine specified in @shogi. > * @xq board drawing is messed with large window sizes here, > although OK with smaller window sizes (see http://imagebin.org/292981), > otherwise seems OK That is a matter of the size of the bitmap provided for the Xiangqi board. XBoard cuts tiles the size of a square from this bitmap. For a square grid of NxN squares that would in principle allow cutting 2Nx2N squares out of it before you start to see the next grid line, but with the diagonal lines in the Palace you already see artifacts when the square size gets >N. These are not very annoying, however. My attitude was pertty much that if people would think the board is too messy, they should simply switch to smaller square size. In older XBoard (before it used Cairo) the only sizes for which there were built-in westernized Xiangqi piece bitmaps were 33, 49 and 72 anyway, and the bitmap of teh Xiangqi board was made with 49x49 grid. > * I feel .desktop files for shipped confs would be > needed to make them more visible to users Indeed, the confs are only useful from the command line. OTOH, confs can be combined on the command line, which is useful when they configure different aspects (game rules, board theme, engine). It would be hard to provide desktops for every possible combination of those. But if there are a few obvious combinations of theme + rules + engine (e.g. because GNU also features an engine, such as with GNU Shogi), we could make desktop files for those. > > * Tried Mighty Lion by starting "xboard -fcp hachu -scp hachu" and > selecting that variant, looks like hachu crashed (xboard -debug output > attached for comment by HGM, hachu is current master, ie version > 0.17-3-g3460d0c). The same technique is OK with Sho and Chu. OK, I will have a look at that. > * Trying to switch to Dai or Tenjiku is refuse with "Engine did not send > setup for non-standard variant" * Maybe a @hachu conf would be useful for > easy access to those games ? Maybe better shipped by hachu itself ? The current XBoard does not support Dai or Tenjiku, and could not be made to support them even through user configuring. The number of piece types needed for thos games exceeds XBoard's current maximum (44 piece types, which was already doubled compared to 4.7.x in order to support Chu Shogi). Only the WinBoard 'Alien Edition' fork currently supports those variants (as well as Dai Dai, Maka Dai Dai and Tai), but the piece images are constructed from scratch in the WinBoard front-end in the 'mnemonic' theme, so this does not work for XBoard. In addition, Tenjiku is not fully implemented in HaChu yet. The move generator still doesn't do 'area moves'. My original plan was to first finish the move generator for all variants (which would also require me to do hook movers fot Dai Dai and larger), before starting to worry about search and evaluation, but then people started to push me for quickly getting a working Chu, and I never got back to finishing the Tenjiku. This exposes a weakness of the engine-defined variants protocol: an engine can claim to support variants xxx and yyy, but as XBoard has no idea what these entail, it cannot realize that it is not able to support them. It only gets that info from the engine after the user selects the variant, in the 'setup' command. Only at that point XBoard can discover it is not able to support the variant, for a number of reasons (too-large board size, too many piece types, parent variant unknown, and of course errors in the setup command). This might seem strange to a user that doesn't know in detail how things work. But to prevent it XBoard would have to probe the engine for every variant, which currently can only be done by switch it to that variant, and waiting for the 'setup' response, to judge from there for of the variants it wants to display buttons in the New Variant dialog. Perhaps I should do that, although I really hate to mess with an engine that way. > > > * Switching to Chu from "xboard -fcp hachu -scp hachu" enlarges the > window while keeping the same tile size, which always make it too big for > my screen, since xboard already starts up using the full screen height for > 8 tiles. This is still a legacy from the pre-SVG era, when the tile size could not be changed at all during a session. Now that we use Cairo the board window is resizable, but the clocks and other elements above the board still are not fully so (even in Xaw they won't automatically switch to the font that would belong to the new size, and in GTK they completely refuse to shrink below the initial size). I guess it would make sense to keep the total board-width fixed after a variant switch, though. I will alter XBoard that way. > > * I guess xboard shipping chu and sho confs make those in hachu.git > redundant ? > Yes, it would. I think the future will be to distribute those confs with the piece and board graphics as separate packages, apart from XBoard or the engines. H.G. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org