Статья про WERD, альтернативу ERM

Система WERD (Without ERM Relating Dynamic) – альтернативная платформа для модостроения в Героях III, чьё использование возможно только в моде Master of Puppets (MoP). Для сторонних мододелов может представлять лишь теоретический интерес в области низкоуровневого программирования.
Аббревиатура WERD изначально является палиндромом имени Drew, так как автор платформы страдает ДБГМ и СПГС.

Основу WERD составляет MoP.exe и собственно Werd.dll, написанная на flat assembler-е (fasm) – свободно распространяемом компиляторе языка ассемблера, чьим автором является Tomasz Grysztar.

Упор WERD сделан на скорость и компактность с сохранением достаточной читаемости исходного кода.

Сутью замены ERM является всего один хук, открывающий WERD доступ ко всем ERM-триггерам. По получении номера вызываемого триггера происходит быстрое сканирование (repne scasd) в таблице номеров триггеров. Если найденный триггер соответствует вызванному – вызывается функция, чей адрес расположен в другой таблице (WERD-триггеры) на том же смещении относительно базового адреса блока данных. Таким образом, каждому ERM-триггеру соответствует всего одна процедура.

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

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

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

В исходниках каждый триггер начинается в файле \WERD\Begin\Название_триггера.inc объявлением процедуры и заканчивается в файле \WERD\End\Название_триггера.inc её завершением. В первом файле триггер получает данные и кладёт их в свои локальные переменные. В последнем файле могут находиться некоторые специфические данные триггера (особые функции, свитчи и пр.), но чаще всего там просто завершение процедуры.

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

Каждому триггеру соответствует файл с листингом include-ов – файлов с кодом, который присоединяется к триггеру в процессе компиляции. Листинг начинается с файла из папки Begin и заканчивается файлом из папки End. Файлы с триггерной «начинкой» находятся в папках, структурированных по игровым элементам.

Файлы с архитектурой триггеров также собраны в список include-ов в файле Werd.inc, определяющем порядок их положения в коде.

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

Главной достопримечательностью WERD является её нарастающая коллекция переходников к игровым функциям. Если специфические функции WERD расположены в самой библиотеке, то практически весь доступ к игровым процедурам осуществляется через короткую конструкцию push %Адрес функции%; ret. Остальная работа по оптимизации уже проделана в MoP.exe, как то:
1. Неудобные вог-процедуры с си-соглашением получают stdcall-ные переходники к ним.
2. Функции с постоянными параметрами (вроде ecx = [постоянный адрес]) обрезаются в переходнике по этим параметрам.
3. Частая последовательность вызова одних и тех же процедур для такого же постоянного действия (вроде инициализации DL-диалога) оборачивается в одну функцию с минимальным количеством параметров.
4. Короткие, но важные функции (вроде получения адреса структуры какого-либо игрового объекта или некой математической операции над массивами данных), тоже прописаны в exe.
Описанный подход неоднозначен. С одной стороны, именно эта особенность, главным образом, делает WERD несовместимой с другим exe, а с другой – обуславливает свободу в пределах данного мода. Сам список переходников обёрнут макросом в таблицу, которая служит и самим кодом, и наглядной документацией к нему (параметры вызова подробно комментируются). Это делает Werd.dll чрезвычайно компактной и нетребовательной. Кроме того: таблица переходников может быть экспортирована целиком в другую длл, если таковая появится в моде, и займёт в ней ничтожное пространство.

WERD поддерживает все необходимые соглашения вызова процедур – stdcall, ccall, thiscall, fastcall и стандартный вызов API-процедур – invoke.

Большинство констант, функций, структур, переменных и даже самих source-файлов в WERD имеет русские названия. Причём эти названия обычно очень длинные и подробные. Ассемблер вообще к этому приучает…

WERD – очень разветвлённая система. На настоящий момент её исходники состоят из 55 папок с более тремястами файлов при весе самой готовой библиотеки всего чуть более 20 Кб.

За месяц, прошедший с выхода версии мода Seek & Destroy, система WERD поглотила более 1000 строк ERM-кода в различных участках скрипта, при этом едва увеличив свой объём вдвое.