DS XXI
Local Pro
Вторую неделю корчую всякие недоработки на карте !xxx2. Удалил большой кожух-коробку вокруг карты, исправил пару десятков утечек пространства, последние из них оказались самыми труднонаходимыми. Когда-то чтобы найти утечку, я терял часы свободного времени, а бывало так и бросал дело, от того, что начинало казаться, что это слишком долго и трудно.
Я пробовал искать по пунктирным линиям, клубящимся по уровню, когда в редакторе Hammer щёлкаешь в меню Map->Load Pointfile или когда набираешь в консоли игры команду pointfile. Часто линии уходят в стены вроде бы и рядом от места утечки, а просвета между блоками не заметно, и не поймёшь где именно.
В этот раз опять пришлось вспомнить надёжный способ, которым быстро находишь проблему. Он известен как метод интервалов, когда материал делится на две части, выявляется, в какой части проблема, и ту часть опять делим пополам, чтобы узнать, где там скрывается проблема. И так ведём разделение до победного конца над проблемой.
Допустим компиляция в hlbsp прошла плохо и вместо "BSP generation successful" выдала ошибку вроде такой:
Проблема в деталях:
В движках игр, родственных Quake (в т.ч. Half-Life), предварительно просчитывается невидимая непроходимая и непростреливаемая структура стен, короче говоря — каркас границ столкновений (clip hull). Этих каркасов в Half-Life создаётся по четыре (в Quake по 3) для просчёта
| столкновений с точечным объектом | нулевой размер | "hull 0" |
| столкновений с игроком в полный рост | размер цилиндра 32x32x72 | "hull 1" |
| столкновений с крупным объектом (монстром) | размер цилиндра 64x64x72 | "hull 2" |
| столкновений с игроком на корточках | размер цилиндра 32x32x36 | "hull 3" |
Ошибка "LEAK in hull 0" означает утечку пространства в каркасе границ столкновений для точечных объектов (в игре есть малосущественное исключение: когда задаёшь "размер точки" объекту типа func_pushable, то вместо точечного там обсчитывается минимальный объём 16x16x16). Очевидно, что самым подробным будет каркас для просчёта реакции на точечные объекты, а чем крупнее объект берётся, тем более грубой будет объёмная структура и сильнее будут срезаться некоторые углы, потому что, например, не везде, где пролезет точечный объект, пройдёт и игрок на корточках. Иначе говоря, в место утечки может завалиться точечный объект, а возможно даже более крупный. И тогда при просчёте падения или движения свободного полёта он улетит опасно далеко для работы игрового движка — для того это и отслеживается при компиляции карты.
Способ исправления методом интервалов:
Смотришь на виде сверху — в плоскости осей X0Y — положение обозначенного в ошибке объекта (в нашем примере с x=2520, y=-1533), до которого добежала утечка. Одну половину уровня временно закрываешь огромным брашевым параллелепипедом. И компилируешь только первыми двумя компиляторами hlcsg и hlbsp. Для ускорения компиляции в настройки к hlbsp можно дописать параметр -leakonly. Т.к. их работа проходит быстро, то секунд через 5, на крайний случай минуты через полторы уже решаешь по принципу "недолёт-перелёт" что делать дальше: если нет утечки, уменьшаешь параллелепипед, если есть — увеличиваешь. И продолжая так сканировать гранями временного блока, не проходит и пятнадцати минут, как ты уже смотришь на источник заморочек и обрадованно думаешь: "Попался, который скрывался!"
Ещё как вариант можете попробовать программку LeakMarker, которая рисует красный блок в месте утечки. Хотя она тоже не панацея.
