Основные принципы генератора ходов (Bitboard и 0x88)

Ага, особенно на почти пустой доске с двумя-тремя пешками у каждой стороны

Ты заметил слово проще? Можешь предложить вариант попроще?

На самом деле определять шах нужно зависимо от хода последней фигуры. Тогда это очень быстро. Сопоставимо с временем доступа к двумерному массиву.

Определимть не оставляем ли мы своим ходом короля под шахом сложнее. Там возникает много технических нюансов. Я пока этот момент не оптимизировал. Просто делаем ход, а потом смотрим попали под шах или нет Тут тоже используются функции быстрого определения шаха.

Это правильно. В позициях, где дальнобойные фигуры не блокированы, скорость должна заметно возрастать.
Кстати, тебе обязательно нужно сделать список фигур. Без него о скорости лучше совсем уж не париться.

Это правильно. В позициях, где дальнобойные фигуры не блокированы, скорость должна заметно возрастать.
Кстати, тебе обязательно нужно сделать список фигур. Без него о скорости лучше совсем уж не париться.

Могу предложить очень много разных определений понятия "проще", на любой вкус

Что за странные вопросы. Сразу понятно, что быстрее пройтись по списку фигур, чем сканировать всю доску в их поиске.

ProstoTak, я тя не понял. Ты спросил - я ответил. Если че не понял - переспроси еще раз.

А что с ним происходит?

Да нет, все нормально. Тормоза - это когда без списков.

Списки можно такие - PieceList[цвет][тип][номер]. С ними никаких тормозов.

Одномерность массивов никак помехой быть не может. Но ты конечно выбрал язык - 1С. Какой смысл после этого рассуждать о тормозах

У меня, вроде, никаких сложных циклов с условием нету

Вот функция удаления черной фигуры:

Код:

void DeleteBPiece(int type, int sq)
{
    BXOR(type, sq);
    Plist[type][Pole[sq].num] = Plist[type][Plist[type][0]—];
    Pole[Plist[type][Pole[sq].num]].num = Pole[sq].num;
    Material += PieceValue[type];
    if (type != bpawn) BPieces -= piece_value[type];
    TotalPieces--;
}

У меня вообще почти все функции продублированы и за черных и за белых

Не знаю. Мне так больше нравится.

Я сейчас пробую написать на классических двусвязных списках, с указателями на предыдущий и последующий элемент для каждого поля.

Надо ещё как-то уметь быстро находить удаляемый элемент. Сняли пешку с E2 - как будем искать элемент в середине отдельного массива-списка? Перебирать все подряд?

У меня примерно так:

Код:

struct Sq
{
   PIECE piece;
   Sq* pnext;
   Sq* pprev;
};

struct Position
{
   Sq base[14];
   Sq board[65];
};

В массиве base хранятся указатели на начала списков для каждой фигуры.

В хороших современных программах замена генератора ходов на мгновенный даст очень мало прибавки.
Но если генератор написан так, что затормаживает всю остальную програму, то его оптимизация может дать значительную прибавку.

Нужно профайлером померять сколько времени тратится на генератор ходов, а потом уже решать стоит ли думать о его оптимизации.

На какой машине? Crafty на Атлоне 2200 мГ нужно около полуминуты (если правильно помню). Так что твой результат не очень плох. А моей проге секунд 15.

Ну это же на 32-битной машине