Осваиваем Jass: Глава 9, Глава 10
26-04-2024»9. Полярные координаты (ликбез)
Все достаточно просто. Если у вас есть две точки A и B, координаты которых нам известны. Как вычислить координаты третьей точки C, находящейся на заданном расстоянии R от точки A в направлении к точке B? Чтобы было понятнее, нарисуйте себе на бумаге точки A, B, выберите какой-то отрезок R длинна которого меньше AB. Точка C – находится на пересечении отрезка AB и окружности, проведенной из точки A радиуса R. Теперь должно быть понятнее.
Итак, зачем нам может понадобиться искать точку C? Как в примере, рассмотренном выше. Юнит-цель движется из произвольной точки A в точку B. Каждые 0.05 секунды мы должны вычислить следующее положение юнита и переместить его на какое-то расстояние в направлении точки B. Для того чтобы вычислять позицию точки C используются полярные координаты.
Итак, что такое обычные координаты ты знаешь. Они задаются двумя координатами X и Y. Но есть еще один способ записать координаты точки. Нарисуй координатные оси, выбери произвольную точку A. Соедини точку A и начало координат O. Пуская длинна AO=r, а угол, который образует AO с началом координат – равен a. Тогда полярные координаты точки называется пара чисел (r, a). Т.е. полярные координаты задаются расстоянием точки до начала координат и углом. Это просто еще один способ задать координаты точки. Можно через (X,Y) можно через (r, a).
В war3 есть встроенные функции для вычисления полярных координат. Например, можно записать такое действие
Код:
Set p = Point with polar [offset ((Center of (Playable map area)) offset by 256.00 towards 50.00 degrees)]
p – переменная типа точка. После выполнения действия, в точке p будет точка, полученная из точки ЦЕНТР КАРТЫ (Center of (Playable map area)), путем перемещения последней на расстояние 256 под углом 50 градусов. Представили?
Полярные координаты очень удобны, если требуется организовать движение по кругу или движение по произвольной прямой. Например действие цикла
Код:
For each (i) from 1 to 10, do (Actions) Цикл Действия Set p = ((Center of (Playable map area)) offset by i*100 towards 50.00 degrees) <создать юнит в точке p>
Приведет к тому, что на расстоянии 100, 200, 300... -1000 от центра карты под углом 50 будет создано 10 юнитов.
Если же мы сделаем так:
Код:
For each (i) from 1 to 10, do (Actions) Цикл Действия Set p = ((Center of (Playable map area)) offset by 1000 towards 36*i degrees) <создать юнит в точке p>
То будет создано 10 юнитов, расположенных на окружности радиуса 1000. Один будет под углом 36, второй 2*36... последний под углом 10*36=360=0 градусов.
Вот что такое полярные координаты точки.
Впрочем, в игре функции для вычисления полярных координат устроены не самым лучшим образом, но об этом будет сказано ниже.
Пересылаю также сценарий paint, в котором демонстрируется, как можно при помощи полярных координат рисовать отрезки и окружности.
» 10. Оптимизация: утечки памяти
Читатель, некоторое представления на эту тему ты уже имеешь. Например, известный факт, что если не удалять созданные спецэффекты, то игра через некоторое время начнет сильно тормозить. Поэтому, даже если спецэффект мгновенного действия и через некоторое время уже не виден, его все равно нужно удалять. Почему так происходит? Потому что каждый спецэффект - это игровой объект. Когда мы создаем новый спецэффект, он попадает в память. Если его не удалять, то он останется в памяти до конца игры.
Аналогичная история с юнитами в ТД, Дотах или Аеонах. Умершие юниты должны быть удалены действием Remove Unit, чтобы не занимать место в памяти.
Оказывается, что такая же ситуация наблюдается и с остальными игровыми объектами. Предметы, декорации, регионы, точки, группы юнитов, плавающий текст, модификаторы видимости - все они с тем же успехом способны засорить память. Да, конечно объект типа точка занимает в памяти гораздо меньше места, чем юнит - в точку нужно записать только координаты X и Y, а в юнит - все его параметры. Но, вообще говоря, утечки в памяти склонны к накоплению. И постепенно игра становится все более тормознутой.
Показателен в этом смысле мой сценарий Air War - там где летает вертолет, управляемый стрелками. Передвижение вертолета реализовано примерно тем же методом, который рассматривался в прошлом сообщении, т.е. события с малым периодом. Но когда я выпустил первую версию, я понятия не имел о том, что нужно оптимизировать код и удалить утечки памяти.
Результат не заставил себя ждать. Через 2 минуты работы сценария, начиналось такое торможение, что дальнейшая игра не имела смысла. Я догадывался об утечках памяти, пытался сделать все проще и эффективнее. Удалось увеличить период игры с 2-х до 5 минут. Да и то, при условии, что играет 1 человек, а ведь чем больше - тем хуже. Разгадку утечки помог найти Alexey B.H.
Дело было в том, что для вычисления координат юнита я использовал стандартные операции worldedit с полярными координатами. А сделаны они, как оказалось, очень коряво. Каждый раз, когда ты используешь функцию point with polar offset, в игре создается новый объект типа точка. Обычно, даже не один, а два объекта. А теперь представь, что у нас работает периодический триггер, запускаемый 20 раз в секунду. И при каждом запуске, создаются новые объекты, которые не будут удаляться до конца игры. 40 точек в секунду, все равно что 80 параметров типа real. А если функцию полярных координат применять не один, а несколько раз в периодическом триггере (к примеру, чтобы вычислить положение камеры), да еще и вычислять координаты для 4-ех игроков - то... Получаем торможение игры.
Вариант устранения утечки подсказал Какодемон. К примеру, если мы хотим вычислить полярные координаты точки, полученной из точки p заданной положения юнита u при угле a равном углу между точкой p и какой-то точкой p2. Для этого можно воспользоваться действиями:
Код:
set p = GetUnitLoc(u) set a = AngleBetweenPoints(p, p2) call MoveLocation(p, GetLocationX(p) + 50 * CosBJ(a), GetLocationY(p) + 50 * SinBJ(a))
Теперь давай проанализируем. Сначала мы переменной p присваиваем положение юнита u. Следующим действием мы ПЕРЕМЕЩАЕМ точку p в другое место. А что это за место? Вообще, в чем суть команды MoveLocation?
Если бы мы написали
Код:
call MoveLocation(p, 10, 15)
то координаты точки p стали бы (10,15)
Если бы мы написали
Код:
call MoveLocation(p, GetLocationX(p) + 50, GetLocationY(p) + 60)
то точка p сместилась бы на вектор (50,60) относительно текущего положения.
А форма записи
Код:
call MoveLocation(p, GetLocationX(p) + r* CosBJ(a), GetLocationY(p) + r * SinBJ(a))
означает, что точка p сместится в точку, полученную пересечением окружности радиуса r и луча, проведенного из точки p под углом a. Т.е. это и есть по сути полярные координаты.
Если известно положение текущей точки (X,Y) и нужно найти координаты точки, полученной из текущей при смещении в направлении a на расстояние r – то ее координаты будут (X+r*cos(a), Y+r*sin(a)). Это все известные в математике факты.
Но в чем преимущество нового метода по сравнению со стандартной функцией вычисления полярных координат? Преимущество в том, что МЫ НЕ СОЗДАЕМ НОВУЮ ТОЧКУ, чтобы вычислить полярные координаты. Вместо этого мы ПЕРЕМЕЩАЕМ СУЩЕСТВУЮЩУЮ ТОЧКУ.
Есть конечно еще один нюанс. Обрати внимание на команду:
Код:
set p = GetUnitLoc(u)
Присваиваем точке p положение юнита u. Но переменная со ссылкой на объект и сам объект - это разные вещи. До этого действия, переменная p была пустой. Объект точка с положением юнита не существовал. После действия, переменная p начала ссылаться на какую-то точку. Какой вывод? Игра создала объект типа точка и сделала на него сслыку в переменной p. Т.е. даже когда ты используешь элементарную функцию - определит положение юнита, в игре создается объект. И он тоже засоряет память - и это тоже станет заметно в триггерах с малым периодом.
Чтобы окончательно избавиться от утечки, необходимо применить действие для удаления объекта типа точка из памяти. В триггерах ты такой команды не найдешь. В jass эта команда выглядит следующим образом:
Код:
call RemoveLocation(p)
Можешь посмотреть, как это сделано в примере, который я выслал в прошлый раз.
Ну, вроде с утечкой из-за точек разобрались. Но, увы, есть и другие виды утечек. Группы юнитов. Вообще-то есть переменные типа unit group. Это из той же серии. Переменная есть ссылка. А на что ссылается переменная unit group? На некий объект. Делаем выводы: объекты, на которые может ссылаться переменная unit group могут создаваться по ходу игры. И не только могут, но и создаются. И засоряют многострадальную память :).
Каждый раз, когда ты применяешь функцию pick every (unit in unit group) and do actions - ты в качестве unit group указываешь определенную функцию. Например, [units of type] или [units in range matching conditions]. Вот тут и скрывается зло. Именно из-за таких функций создаются объекты, которые будут торчать в памяти (кстати, во втором случае еще и точка может выплыть). И, как ты догадываешься, в триггерах с малым периодом - это означает торможение.
Так что если хочешь создавать, к примеру, огонь, который каждые 0.25 секунд наносит повреждения всем юнитам в такой-то области, нужно уметь бороться с утечками. А борьба будет просиходить по схеме:
Создай переменную, например ug типа группа.
Перед действием pick every unit нужно занести в переменную ug группу, которую мы будем использовать. Например: set ug = [units in range matching conditions]
Во время действия pick every unit в качсестве группы указываем переменную ug.
После действия pick every unit вставляем команду:
Код:
call DestroyGroup(udg_ug)
- уничтожить группу из глобальной переменной ug.
Итак, подведем итог: в большинстве сценариев, утечки могут возникать из-за
юнитов (создаем много и не удаляем)
спецэффектов
функция для работы с точками
функций для работы с группами
Могут быть и другие варианты, но они встречаются реже.
Утечки особенно опасны, для триггеров с малым периодом.
Читатель, если удалить все основные утечки, то для 99,99% сценариев больше ничего не нужно оптимизировать. Но, как оказалось, существуют и другие виды утечек. Например, куда девается локальная переменная после того, как триггер кончил исполнение? На самом деле они продолжают сидеть в памяти. И хотя занимают они очень мало, но на протяжении длинной игры, их может накопиться порядочно. Чтобы этого избежать, имеет смысл обнулять локальные переменные после окончания действия триггера (по крайней мере, переменные объектного типа).
Ты наверное замечал уже это в примере, который я присылал. В конце триггера идут строки типа
Код:
set i = 0 set r = 0 set s = ""
А как обнулять переменные со ссылками на юниты, точки и пр.? Есть способ. Для всех объектных переменных ноль это null.
Т.е. мы пишем
Код:
set p = null set u = null
и т.д. И переменные обнуляются.
Есть еще одна интересная возможность увеличить ресурсы памяти для длинных сценариев. Для этого нужно в какой-нибудь триггер с событием Map Initialization добавить команду:
Код:
call DoNotSaveReplay()
- Эта команда заставит war3 не писать реплей игры. А значит, снизит ее загрузку.
Примечание. Мой друг картостроитель, прочитал про утечки и начал думать, что же с этим теперь делать? Глянул на свой проект и приуныл. Столько всего оптимизировать... Раньше для него не было проблемы утечек, а теперь пришлось думать, что с этим делать. А я думаю, может быть и не стоит так уж усердствовать? Во всяком случае не все сценарии требуют дотошно оптимизировать и удалять все утечки. В первую очередь, конечно, должны оптимизироваться сценарии для сетевой игры и сценарии, где есть триггеры с малым периодом. Остальные – надо смотреть по обстоятельствам. Если есть торможение, можно попробовать от него избавиться.
Вообщем, jass поможет вам решить проблемы, которые до его изучения не существовали. 
Покончив с оптимизацией, мы наконец перейдем к одному из самых полезных аспектов jass.
К статье прикреплен файл:paint.w3x
|
| Категория: JASS / AI скрипты учебники | Добавил: imDarkCount (26-04-2024 в 15:12:17)
|
| Просмотров: 2789
| Рейтинг: 3.5/4 |
|
|
