Модуль карты

Пытаюсь написать Алгоритм Брезенхэма для окружности вроде бы адаптировал код из С++ в QSP однако на выходе получается не круг а овал.

!---Рассчёт круга---!
X1 = 7
Y1 = 7
R = 5
!R - радиус, X1, Y1 - координаты центра
x = 0
y = R
delta = 2 - 2 * R
error = 0
:loop
if y >= 0:
	$вывод['<<X1+x>>_<<Y1+y>>_0'] = '<td style="width: 36px; hight: 36px; background-image: img/loc/<<$maproof[''<<вывод_x>>_<<вывод_y>>'']>>"><a href="EXEC: gs ''Обработка клика'',<<вывод_x>>,<<вывод_y>>" ><img src="img/editor/select.png"></a></td>'
	$вывод['<<X1+x>>_<<Y1-y>>_0'] = '<td style="width: 36px; hight: 36px; background-image: img/loc/<<$maproof[''<<вывод_x>>_<<вывод_y>>'']>>"><a href="EXEC: gs ''Обработка клика'',<<вывод_x>>,<<вывод_y>>" ><img src="img/editor/select.png"></a></td>'
	$вывод['<<X1-x>>_<<Y1+y>>_0'] = '<td style="width: 36px; hight: 36px; background-image: img/loc/<<$maproof[''<<вывод_x>>_<<вывод_y>>'']>>"><a href="EXEC: gs ''Обработка клика'',<<вывод_x>>,<<вывод_y>>" ><img src="img/editor/select.png"></a></td>'
	$вывод['<<X1-x>>_<<Y1-y>>_0'] = '<td style="width: 36px; hight: 36px; background-image: img/loc/<<$maproof[''<<вывод_x>>_<<вывод_y>>'']>>"><a href="EXEC: gs ''Обработка клика'',<<вывод_x>>,<<вывод_y>>" ><img src="img/editor/select.png"></a></td>'
	error = 2 * (delta + y) - 1
	if delta < 0 and error <= 0: x += 1 & delta += 2 * x + 1 & jump 'loop'
	error = 2 * (delta - x) - 1
	if delta > 0 and error > 0: y -= 1 & delta += 1 - 2 * y & jump 'loop'
	x += 1
	delta += 2 * (x - y)
	y -= 1
	jump 'loop'
end

Может кто-нибудь здесь разбирается в алгоритмах и найдёт ошибку в коде?
Хотя возможно QSP просто не очень удачно округляет какие-нибудь значения.
Растягивается круг по горизонтальной оси.

Bumbr,
у тебя опечатка. “hight” вместо “height”.

Долго мучился, но всё-таки добавил динамический радиус обзора.
Пока видимая область выделяется зеленым в целях теста. Радиус обзора фиксирован на 4 клетки из-за некоторых артефактов на других радиусах. Позже, когда исправлю этот недостаток алгоритма радиус будет напрямую зависеть от восприятия персонажа (radius = pPER). Минус системы в том, что при поиске пути, и без того несовершенном и кривом, персонаж пока учитывает непроходимые объекты о которых по идее не знает.
Позднее введу несколько слоев видимости (Не исследован, исследован, видим), либо вообще сделаю непроходимые объекты видимыми всегда.

Тест работы с картой

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

Чем сложнее, тем веселее)

Bumbr:

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

Для чего переписывать алгоритм поиска пути? Если я правильно помню из всяких RTS, типа majestic и spellforce, юниты знают об окружающей действительности больше игрока и выбирают путь без учёта затенённых областей. В Spellforce2 точно помню можно было ткнуть иголкой мышью в тёмное место и ждать, пока герой или юнит до туда доползёт. Правда при прокладке маршрута не учитываются другие препятствия, вроде нападающих со всех сторон орков, но это уже другая история.

Решил не трогать пока поиск пути.
Теперь обзор может быть любого радиуса, одна на радиусе в 10 клеток (максимальный запланированный) в чистом поле время обработки достигает пугающих 1.7 секунд на моём компе. Откровенно слабо представляю как это исправить. Возможно, если круг не рассчитывать, а задать вручную для всех 10 радиусов это уберёт лишнюю нагрузку. Муторно, не элегантно, но работать должно лучше.
Добавил тестирование обзора на пустой карте с расчетом затрачиваемого времени. Радиус обзора теперь задается вручную.

Тест работы с картой

Bumbr:

достигает пугающих 1.7 секунд

Т.е. ты вернулся к тому же, что и было в начале, когда карта мерцала, разве что без мерцания.

Надо уменьшать количество циклов.
Если я правильно понял, при сдвиге на одну клетку всякий раз пересчитываются все координаты всех клеток круга. Это нецелесообразно. Достаточно пересчитывать только координаты клеток окружности. Круг всегда сдвигается относительно героя. Значит тебе достаточно сдвинуть окружность - это как минимум избавит от пересчёта координат клеток по всей площади круга, как максимум - тебе будет достаточно просчитать круг (а вернее только координаты клеток окружности) один раз и перерисовывать только местоположение героя и окружности.
Если не понятно вот картинка.

Дело в том, что обзор рассчитывается построением линий от персонажа к точке на окружности, до первого препятствие. Поэтому нельзя просто сдвинуть обзор вместе с игроком. Сейчас убираю циклы расчета окружностей и заменяю их кучей вручную прописанных вызовов функции расчета линии до нужных точек. На радиусе в 6 клеток выигрываю около 100 миллисекунд. Добавил дополнительную проверку в прорисовке линии, чтобы не обрабатывать уже видимые клетки. Может придумаю как еще сократить время.

Bumbr:

от персонажа к точке на окружности, до первого препятствие.

Поясни, зачем это вообще нужно? Действительно ли это необходимо в игре?

Aleks Versus:

Bumbr:

от персонажа к точке на окружности, до первого препятствие.

Поясни, зачем это вообще нужно? Действительно ли это необходимо в игре?

Ну так ведь:

Bumbr:

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

Уж ты-то должен это понимать:

Aleks Versus:

Вот я ни одной игры ещё не написал, но под завязку увлечен QSP уже больше пяти лет. Ну не знаю, как это объяснить. Любовью создавать себе проблемы и решать их?

Olegus t.Gl.,
подловил. :=D

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

Пригодится она при исследовании случайно сгенерированных локаций, типа подземелий.
Заменил расчёт окружности заранее рассчитанными координатами. Расчет радиуса в 11 клеток занимает теперь примерно от 877 миллисекунд до секунды. Однако этот радиус фактически полностью покрывает видимый экран и еще вылазит на соседние. Можно сделать максимальным радиусом 5. Он рассчитывается теперь за 350 миллисекунд примерно и обеспечивает достаточный радиус обзора. Хотя это и нежелательно. Тут еще надо уточнить что это цифры для персонажа в чистом поле. На реальной карте препятствия будут ограничивать обзор, что снизит время рассчета.

Сделал радиус обзора равным восприятию делённому на 2 с округлением к большему.
Дописал в алгоритм движения динамическую задержку, вместо фиксированной ранее. Динамическая задержка позволила поглотить часть времени потраченного на расчет обзора, хотя теперь на при максимальном восприятии разницы между шагом и бегом почти не заметно.
Тест работы с картой

Любопытно)
Я сейчас пишу игру код схожей направленности (хотя и в разы проще обсуждаемого) и торможения во время выполнения циклов у меня почти нет. Хотя один из циклов генерации карты (пусть в нем и всего два действия) выполняется где-то 80000-100000 раз (его можно сократить во многие разы, но я не сразу это понял). Задержка где-то секунда полторы. Обзор (кругообразный - 6 по прямым, 4 - по диагоналям) и выведение массива-карты из 3000 ячеек 30*100 вообще осуществляется почти мгновенно. Может дело в компе? Древний комп наверное с такими вещами будет не очень то хорошо справляться. У меня то четырехъядерный. Но, есть один непонятный момент для меня. Выведение вышеописанного массива с 3000 изображений jpg 10*14 (вместо текстовых символов) ВНЕЗАПНО занимает 1-1.5 секунды. Т.е. лаг у меня вызывает не код, а вывод данных на в экран - в зависимости от того, какие данные выводятся. Почему это происходит? Из-за того, что плееру нужно дополнительное время чтобы обратится к внешним данным? Я в таких вещах мало понимаю, для меня это ну очень странно выглядит…

Сделал такой прикол: отображение “графикой” только того, что находится в зоне видимости, а всего остального - символами. Рассмеялся, когда с запозданием понял что сделал по сути тот же трюк что применяется большинстве графических игр=)
зы Зона видимости (как и “подземелье”) довольно кривые, но я над ними особо и не работал. Как, впрочем, и над чем-либо еще.

Stag_Beetle,
ты делаешь карту в “классическом” плеере. Bumbr в AeroQSP. В этом всё различие.