Author: Miguel A. Ballicora
Date: 13:25:16 02/01/02
Go up one level in this thread
On February 01, 2002 at 15:31:45, Sune Fischer wrote:
>On February 01, 2002 at 15:01:05, Alvaro Jose Povoa Cardoso wrote:
>
>>On February 01, 2002 at 14:34:28, Sune Fischer wrote:
>>
>>>On February 01, 2002 at 11:42:05, Alvaro Jose Povoa Cardoso wrote:
>>>
>>>Hi :)
>>>
>>>>In my checkers (portuguese/spanish version with long jumps) program I use the
>>>>four bitboard ray technique for the four directions for each of the 32 square
>>>>for the king jumps (with 32bit bitboards).
>>>
>>>Could tell a bit more about this ray technique?
>>>Preferably every single detail :)
>>
>>
>>I think it is very basic and even naive.
>>Suppose you have a rook at E3.
>>You need to process 4 bitboards:
>> bbD1 as bits on at E4,E5,E6,E7,E8
>> bbD2 as bits on at F2,G2,H2
>> bbD3 as bits on at E2,E1
>> bbD4 as bits on at D2,C2,B2,A2
>>Now suppose you have a bitboard called bbAllPieces
>>
>>For non captures of the 1st bitboard bbD1 you do
>>
>>while (bbD1) {
>> to = FirstBit(bbD1) /using BSF
>> If TestBit(to,bbAllPieces) break;
>> ClearBit(to,bbD1)
>> ...assemble move using 'to' as the destination square
>>}
>>
>>Now you have to do this for the other 3 bitboards.
>>You have to use LastBit() instead of FirstBit() for bbD2 and bbD3 if you use bit
>>0 for H1 orientation.
>>
>>Alvaro Cardoso
>
>Ok, thanks I get the idea. The problem here will be FirstBit which is quite
>expensive compared to regular 64-bit "instructions", and the 'if' is also not
>exactly speedy.
>
>One other idea I've been testing; simply masking out all the pieces one by one
>with a [64][64]-table containing all the rays.
>
>It is really not that slow if there are not too many pieces on the board, it's
>what i've been using up till now, but I'm on the lookout for something even
>faster ;D
>
>Of cause one thing that is an absolute must, is to check that you _need_ to
>update the attack board in the first place. Most moves made will only invalidate
>a few of the attack boards, so there is generally no reason to mindlessly update
>them all every time.
>I don't think any attack algorithm so fast that this test will actually slow
>things down. For the non-sliding pieces don't do the check, but for the sliding
>pieces I believe it is a sound investment.
That is how I started with my program. It was a clever idea but slower :-)
Maybe it needed a better implementation? mmhh.. I think that the more we want to
add, the more we slow it down.
Regards,
Miguel
>
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.