Re: [Gnushogi-devel] gnushogi xboard support

[ydirson]

----- Mail original -----
> De: "h g muller" <address@hidden>
> À: address@hidden
> Envoyé: Vendredi 25 Octobre 2013 17:36:33
> Objet: Re: [Gnushogi-devel] gnushogi xboard support
> 
> > gnushogi maps the board in a monodimensional array.  While it looks
> > bit
> > primitive, and makes move description hard to read by humans, it
> > does have
> > some advantages for this promotion-zone issue :)
> >
> > #define InBlackCamp(sq) ((sq) < 27)
> > #define InWhiteCamp(sq) ((sq) > 53)
> > #define InPromotionZone(side, sq) \
> > (((side) == black) ? InWhiteCamp(sq) : InBlackCamp(sq))
> 
> OK, from this it seems that GNU Shogi uses separate code for white and
> black moves that you can at compile time decide which test to make by a
> macro. In Shokidoki I use the same code for both colors. So it is more
> convenient to make a test like (promoGroup[coloredPieceType] &
> canPromote[sq]) or (promoGroup[coloredPieceType] & canDefer[sq])  where
> pieces of each color just use different bits in promoGroup and zoneFlags.

Well, it would not be that hard to build a turn-independant InOpponentCamp() 
macro
from those :)

> Monodimensional boards are quite standard in engines for efficiency
> reasons; all my engines use them too. There are still different flavors
> for how to map the 2d board onto the linear one e.g. whether there are
> unused bytes between one rank and the next to act as edge guards and avoid
> pieces from wrapping around like the board is a cylinder. And sometimes
> also to make that the difference of two square numbers uniquely identifies
> the board step.

Well, I'd have thought that letting the compiler deal with converting 2d indices
to memory offset would be good enough, and that optimisations should be able to 
achieve
similar or better perf...