Author: Severi Salminen
Date: 05:32:21 02/01/01
Go up one level in this thread
>I calculate a "pseudo-attack" bitboard for sliders. (That's a bitboard >that has a bit turned on for each enemy piece on which the slider is >bearing, ignoring any blocking pieces.) Then I start extracting the >coordinates of the "victims". For each such coordinate I test to see if >any pieces are blocking the attack using a blocking-mask bitboard which >has all the bits turned on for squares that lie between the attacker and >victim. If no blockers are there, we have a real victim. > >I don't think this differs much in cost from rotated bitboards. In >some cases it's probably faster (sparse board), in others it's probably >slower than rotated bitboards. Even if rotated bitboards happen to be a >little faster generating captures, they will certainly slow down make() >and undo(). It is hard for me to believe your system is faster than rotated bitboards (I might be wrong). But considering the fact that you make about 10% of the moves that you generate rotated bitboards should be faster in all cases. I tried to convince myself one month that rotated are not faster than non-rotated. The result was a 10-30% speedup after 6 hours of programming (it was really brainboiling task to figure out a good mapping scheme). Using simple lookup tables and a little assembly you can extract the horizontal, vertical and diagonal occupation info in a couple of assembly instructions and with one table lookup you have the attackboard, voila! It would be "very" initeresting to see the results if you tried to convert your engine into rotated bitboard engine. Severi
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.