Actually:




I shoudl think things through before I post them.

quote:Original post by Magmai Kai Holmlor
Hey Russell, unless bm is an __int64 (or bigger), the results of b<<32 are undefined.

It''s not undefined...hint, hint Notice all of the hex values are also 64-bit.

Actually what they do are generate bitmaps (bm) containing legal moves or attacks in a game of chess. It would probably be more clear if I named the function FillUpOccluded(bm b, bm c) to something like RookAttacks(bm rooks, bm empty). So if you have a bitmap (64-bit value) where each bit is answers a yes/no question, you have the following bitmaps:

bm rooks: Is there a rook on this square?
00000000
00000000
00000000
00000000
00000000
00000000
00000000
10000000

bm empty: Is this square empty?
11111111
11111111
01111111
11111111
11111111
11111111
11111111
01111111

Then FillUpOccluded returns the following bitmap, answering the question "Does a rook attack this square?"

00000000
00000000
10000000
10000000
10000000
10000000
10000000
00000000

And then I have one that generates horizontal attacks, diagonal attacks, etc. The other function (Fill8) generates knight attacks. These become very useful. If you want to generate only captures, you simply AND this resulting attack bitmap with a bitmap for "all black pieces" and you''re set. These algorithms are variants of a kogge-stone parallel prefix algorithm. The cool thing is that if there are two rooks on the board, this algorithm will generate an attack bitmap for both rooks in parallel. Using this bitmap approach rather than an array offset approach (like int squares[64] for the board, or whatever) is very cool and allows for many such parallel operations, but I imagine it would be hell trying to figure out what the code did with no documentations or good function names. I changed the names of my functions BTW, because "KnightAttacks" might have given it away

Russell