Типа - да. Если не умеешь в оценке угадывать стенку.
Но вроде, нарастание идет по прямоугольнику через A и B - более "направленно" вроде...
Давненько уже экспериментировал, подзабыл маленько

[size=-2]------ Добавлено в 19:30
То есть - нет.
Надо дойти сначала до стенки по прямой (не до угла), а потом начать ее обходить.
Еслив дырки не нашлось

Те разрешать пересечения, правильно?

В принципе, мой пример можно доделать так, что пересечение с линией можно будет делать, но "стоить" это будет, скажем, шагов 20-30. Т.е. если в обход - длиннее на 20-30 шагов, то будем "бурить"

в терминологии "оценочной" ф-ии: к "цели" прибавляешь (20-30)*<количество бурений>

Суть там у тебя вроде та же, т.е. есть "волна" - граница обработанной области, и расширять эту границу нужно для тех точек, которые ближе к целевой и имеют возможность для движения. Следуя этой стратегии, добравшись волной до целевой точки, можно сказать, что кратчайший путь уже найден, что, вроде-бы, логично. И лишней работы по вычислению расстояния не будет, потому что дальние (от целевой точки) точки границы так и останутся "непродвинутыми".

[size=-2]------ Добавлено в 21:32

Я думаю, коэффициент можно и поменьше сделать, типа 20+5*<количество бурений>

[size=-2]------ Добавлено в 21:33
Т.е. если уж "бурить", то какая разница - одну или две линии.

Конечно та же
Волна - она и в Африке волна.


Не будет.
Говорю же - народ ТЕОРЕМЫ доказывал

Имелось ввиду, если линии, которые "бурим" непосредственно рядом друг с другом.

Ну бурим, и что...
В принципе, это же общая схема для "переборов".

Пробурили...
У данной точки появился дополнительный прайз в 25...
И очередь до его обработки дойдет только тогда, когда непробуренные за 25 ходов не доберутся до цели...

Все нормально же, вроде.

Поигрался с алгоритмом, сел за реализацию и понял, что в общем случае для бесконечного поля HiAsm потребуется очень большая(огромная матрица)... Кроме того эту матрицу перед каждым перебором еще нужно построить. А чтобы её построить это надо по хорошему вставлять виртуальные методы отрисовки для каждого элемента(не делать же честный bitmap в памяти на вся ширины и высоту схемы). Было бы гораздо проще, если бы алгоритм работал с регионами и отрезками без дополнительных построений.

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

Нафига, у каждого элемента тоже есть границы (в координатах матрицы, например реальные координаты / 7). Линки тоже состоят из линий. Отрисовку из моего примера можешь выкинуть (кроме, конечно, найденной линии - тут отрисовку надо заменить на формирование координат линий линка, т.е. пока направление совпадает - идёшь дальше, а на повороте - формируешь точку линка)

Но вообще, надо бы оптимизировать алгоритм, т.е. вместо очереди использовать список, отсортированный по возрастанию "расстояния" до целевой точки. Выбирать всегда первый элемент (или последний, если по другому отсортировать - удобно если хранится в массиве - никаких сдвигов), а вставку делать с применением бинарного поиска. Ну или как у Galkov-а - использовать хеш.

Не факт, между прочим.

По памяти: в элементе MatrixArray самая большая память расходовалась на пустом поле. Это был прямоугольник, у которого начальная и конечная точка стояли по его диагонали.

Что такое верхняя точка Matrix в этом элементе
Да, грубо говоря, интерфейс запроса для ответа на вопрос: "а чего есть в этом месте".
Если говорить о "боевой программе", то это может быть более тонкий интерфейс.
Ну, скажем, в запросе идут координаты + размеры региона (скажем 16x16), а в ответе: да это все элемент занимает, отрезок линка с такими-то координатами, да пусто тут все, и т.п..
с возможностями дальнейшего разнообразия, видимо....

А рисование можно сделать и "безотказным". Просто пусть пройти можно будет везде, а наказывать за неправильный проход - рублем.

Ну, пусть он идет под элементом, но дороже...
И пусть 4 разворота на линке будет дороже, чем проход под элементом (нечего петлять как пьяный ежик).
И пусть повороты под элементом, или проход по точкам - совсем дорого будет.
Вся эта система прайсов определит даже некий стиль рисования - я бы так сказал.
Можно даже и сетку менять, если "за очень дополнительные деньги"

А 200x200 - это еще не бедствие, Имхо (опять по памяти - Ампер, кажется, мой элемент на реальных скриншотах катал)

---

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

Вот именно. Если взять двухбайтовый элемент для расстояния и однобайтовый для направления, то получим 200х200х3 = 120000 = 120 Кб. При этом размер схемы будет, скажем, 1400х1400 точек. Сколько там один такой битмап у тебя кушает? Почти 6 Мб !

Зачем тебе Bitmap-ы

Работаем в сетке 7x7 - выравнивание у НАС в среде такое, вроде.
И считам только свои динамические струкуры, помещенные в "буфер" для последующего анализа
Я так делал - видел же...
Объем перебора во чистом поле - чисто экспериментальные данные, и никакого отношения к bitmap-ам не имеют...
И плевать - какое там у кого-то поле по размерам, и в чем оно измеряется.
По большому счету-то.

Это я для сравнения!

А

предупреждать надо: а то я со стула чуть не упал