Might and Magic 6,7,8 (модернизация и модификация)

mmtool,
После пропатчивания mm7.exe версии 1.0.0.1 от Буки в software mode при запуске игры экран чернеет, потом вываливается в рабочий стол. В D3D режиме игра запускается в левом верхнем углу, потом окно увеличивается на весь экран, появляются лица команды, панель справа, можно ходить, вызывать книги, заклинания, но на самом игровом экране отображается только последнее вызванное окно, например после загрузки остается заставка с прогресс-баром, после вызова меню - картинка меню. Лоды перепаковывал вторым батником, но результат тот же.

 

А сколько изменений показывает при патчинге? Должно быть 609 для версии 1.0.01. Софтваре режим вообще по идее работать не должен при нормальном патчинге - отключается принудительно, несмотря на настройки, поскольку не готов еще.

 

У меня делается 563 изменения. Маловато, да?

 

Да, маловато, что странно. Поэтому и баги. Может версия не совсем та, что у меня, или патч какой применялся. Нужен непатченный экзешник (по почте или через личку), чтобы разобраться, в чем проблема.
<добавление>
Кстати, не все, похоже, знают, что в интернете есть сайт mm6rus.narod.ru, где есть практически полная информация по играм MM6-8, плюс различные редакторы, утилиты и патчи.

 

mmtool, поставил патч, пропатчилось как надо, все 609 изменения, играется отлично!

 

Ну и хорошо Это поможет и другим при возникновении проблем с патчингом. В аттаче поправка к патчу - откат пяти изменений. Исправляет баг с надеванием гидрокостюмов, который я обнаружил несколько дней назад. Одеваться не хотели в патченной версии. А при использовании обходного маневра (одевание и переход в водную зону в непатченной версии, а потом загрузка патченной) становились невидимыми, из-за чего под водой становилось доступным одевание доспехов и прочего инвентаря. Там проверка в интерфейсной процедуре шла, что и вызвало ошибку. Так что теперь на 5 изменений меньше должно показывать.
Больше ничего не изменилось, поскольку 0.2.7 последняя из версий, вышедших в виде консольного патчера (и потому в ней только критические баги будут фиксится до выхода следующей). Следующая будет уже в виде .dll с GUI-фронтендом к ней. Так можно будет подвязываться ко всем нужным процедурам, участкам кода и переменным .exe и потом в удобной форме их использовать в .dll, корректировать результаты, добавлять новый функционал, выносить различные скрытые настройки в GUI-конфигуратор и т.п. И software-режим фиксить, а то там код и различные буферы надо расширить-добавить, а при простом патчинге место под это нет, плюс неудобно.
Пока идет подготовительная исследовательская работа для минимизации применение метода "научного тыка" в будущем. Прогресс в подписи (чтобы сообщений лишних не делать). До 100% ждать конечно не придется, достаточно скоро возобновлю выкладку патчей и понемногу начну делать редактор (начав со стадии вьювера-просмотрщика в целях тестирования-изучения форматов ресурсов).
На этом пока всё.

 

Просьба только к GUI свистелки и перделки не прикручивать! Жду одну кнопку (патчить) и два сообщения — "удалось" или "не удалось".
Я вообще за консоль, но я в меньшинстве, знаю

 

Прикручу флаг, герб, гимн и лидера в ушанке! Пущай буржуи трепещут! Если серьезно, то GUI нужен для возможности удобной настройки всяких режимов и опций, которые я собираюсь вынести/ввести в .exe. А также (потенциально) для оперативного отслеживания и изменения того, что происходит внутри игры (.exe) в каждый момент времени. Плюс .bat-ники многие уже и запускать не умеют.

 

Все работает - по крайней мере, пока.Спасибо, ждем новых версий
ЗЫ С Пасхой всех!

 

Начал работать над редактором (пока в виде вьювера). В аттаче самая начальная версия 0.0.1 - не более чем небольшой тест, ибо малоюзабельна и имеет массу ошибок. Надо положить в папку MM7 (и вроде MM8 тоже поддерживается). Кое-как рендерит в OpenGL трехмерные модели закрытых помещений, с минимальными возможностями перемещаться в пространстве для их просмотра. Выкладываю просто чтобы показать, что MM-работы идут. Нормальные версии пойдут начиная со следующей.

 

программа для просмотра карт mm6-8
http://sites.google.com/site/angelddeath/

 

Следующая версия вьювера. Теперь с нормальной камерой, которая управляется клавиатурой, теми же клавишами, как в MM-играх - ходьба, вращение, полет, взгляд вниз-вверх. Мышь для обзора (free look) не подключал, поскольку на неё редактирование (выбор, перетаскивание объектов и т.п.) в будущем повешу.
Уже более-менее поддерживает все версии MM6-8 (надо положить в папку с игрой и запустить). Пока только трехмерные объекты (т.е. для indoor - модели пещер и т.п., для outdoor - здания, колодцы и прочее). Если при входе в карту ничего не видно - надо покрутиться-подвигаться, может просто объектов в области видимости нет.
Вообще outdoor-карты (открытые области) похоже редактировать легче всего будет. Все эти модели зданий и т.п. со всех карт в принципе можно отправить в библиотеку редактора, затем зачистить от них выбранную карту и расставить по новому где нужно (или добавить к старым картам). Да и моделировать проще. В отличие от внутренних помещений (indoor), где практически всё сшито вместе, разве что отдельные комнаты в качестве запчастей попользовать можно.

2angeld: Вещь хорошая, но редактирования не хватает, хотя первая версия 2005 годом датируется. Поэтому я редактор и затеял (в том числе и под впечатлением от MapViewer-а, о чем укажу в Acknowledgments при появлении в программе About-окна).

 

- добавил генерацию земной/водной поверхности для outdoor-карт MM6-7 (у MM8 поддержку lod-формата с описанием тайлов надо доработать, несколько отличается). Поверхность в игре сделана на основе обычной карты высот 128x128, на квадраты которой натягивается по тайлу (текстуре). Соответственно проблем с редактированием не будет. Пока тормозно отрисовывается (вывожу все квадраты, без отсечения по полю зрения), но хоть карты стали узнаваемы. По краям воды полоска - это вроде-как прозрачная зона (перекрытие), пока не поддерживается, потому и цветная.
- исправил баги с невозможность загрузки отдельных indoor-карт (возникали из-за неучета того, что у полигонов может быть прописано 0 вершин в ресурсах).
Спрайты и места генерации монстров будут в следующей версии, но это уже не проблема, поэтому буду нарабатывать инфраструктуру для редактирования (изменения и сохранения).

 

angeld, mmtool, это всё хорошо, но почему бы не вести разработку всех этих вьюверов, редакторов и прочих улучшалок, в режиме открытой разработки? Чтобы не плодить лишние сущности, не выполнять по несколько раз работу, которую уже сделали до этого, и кооперировать усилия, чтобы до конца разобраться в устройстве движка, облагородить его и выпустить всякие SDK для мододелов? А не бросить на полпути, как это обычно бывает...

 

По ресурсам игры давно уже есть открытая разработка - MM8LevelEditor (http://mm8leveleditor.sourceforge.net). На Java, с открытыми исходниками. Когда стартовала, не в курсе, на сайте указан март 2004 года для версии 3.00. Много чего из ресурсов разобрано, используется немногочисленными моддерами как основной рабочий инструмент в настоящее время. Если есть желание, его можно использовать как основу для собственных разработок. Хотя там достаточно много чего не разобрано, а кое-что разобрано с ошибками, но почти всё основное в принципе есть, так что можно наверное даже обойтись без исследования .exe. Проект, кстати, остановился в 2005 году - несмотря на открытость.

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

Проект я не брошу - по крайней мере еще ни один не бросал, не доделав хотя бы основной функционал. В крайнем случае выложу исходники, кроме закрытых частей, которые непосредственно редактора мало касаются. Вот по скорости и регулярности разработки ничего обещать не могу, других дел полно. Но ведь MM-играм уже по десять лет, даже несколько месяцев суммарных задержек мало что изменит.

Но вообще-то сделать клон MM-игр на основе одного из бесплатных движков может быть более простой задачей, чем сделать редактор и SDK для оригинальных игр. Мне просто это не особо интересно - интереснее сделать свой движок, хотя бы и в рамках редактора для начала.

 

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

 

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

Выбивания программы с ошибкой могут возникать из-за проблем с размерами различных буферов памяти, некоторые из которых жестко прошиты в программе вместе с данными. При прямом патчинге .exe для их увеличения приходилось искать потенциально свободное место в сегменте данных .exe (например, вместо данных SW-режима и т.п.). Что при определенных условиях, видимо, и вызывает ошибки. Это уже обсуждалось на английском форуме. Хотя я вторую половину игры MM7 прошел под патчем в 1024x768 и меня ни разу не выбило. Может это только в более высоких разрешениях наблюдается...

Решением проблемы (если она в размерах буферов) должна стать версия патчера с внешней .dll (+GUI для управления), где можно и дополнительного кода сколько угодно и какого угодно добавить, и памяти выделить сколько надо. И вообще делать с игрой что угодно, перехватывая и подменяя участки кода (или корректируя входные/выходные данные) уже известных процедур через .dll. Софтовый режим, кстати, тоже из-за недостатка памяти под буферы не работает. Я давно знаю, где и что изменить (для MM7 по крайней мере), но из-за того, что в софтовом режиме буферы в несколько раз больше, чем в D3D, для них не удалось найти места вообще.

Все эти паттерны и прочий прямой фиксинг не актуален и не перспективен, ничего большего, чем уже сделанное, из этого не выжать. Даже элементы интерфейса перемещать толком не получиться по элементарной причине - большинство его параметров зашито в код, а не в данные. Соответственно, если например в процедуру передается какое-нибудь значение (X,Y,ширина, высота), не большее 255 (т.е. байтовое), то используется оптимальная для этого инструкция - push byte_value. Которая занимает ровно два байта - байт на код инструкции и байт на значение. И без ручной переделки таких участков кода передать значение большее байта (0-255) не получиться. А их очень много в разных сочетаниях. Плюс еще масса оптимизаций из той же оперы. Например, арифметические расчеты с помощью инструкции lea, где константы (которые надо поменять) вшиты в саму структуру этих инструкций, и т.п.

Так что патчер на самом деле - это не только набор исправлений неких констант, но и набор заплаток и переделок таких оптимизированных участков кода (иногда перекодированных вручную, иногда генерящихся автоматически для простых оптимизаций). Причем у разных версий .exe они зачастую разные в одном и том же месте кода. Поэтому я сохранил и панели на более-менее стандартных местах - нижнюю с x=0 координатой, правую - с y=0 координатой - чтобы не переделывать все передачи таких координат кодом типа xor eax,eax; push eax), и т.п. Если так патчить всё остальное в .exe (переписывая все участки оптимизаций), это будет несколько тысяч изменений и масса затраченного времени. .dll-подход более продуктивен, и через него уже можно будет начинать делать всё "так как бы хотелось" (в том числе через config-файлы, а может даже и через скрипты).

 

Ну, можно было бы создать новую секцию и переносить излишки туда, но да это ещё больший гемор, чем сейчас. Собсно пробежался в дебаггере на предмет вылетов, да, там где-то переполнение при открытии спелбука во время подгрузки целого списка каких-то tab5a, sbbb00 (как понимаю всех этих иконок интерфейса), причем это случается, только на больших разрешениях (у мну 1280x1024) и одновременно больших картах (например, в центре эратии) со 100% результатом, в этом куске:

Код:

.text:004270EF                 mov     edi, [ebx]
.text:004270F1                 cmp     dword ptr [esi+1D4D8h], 0
.text:004270F8                 lea     ecx, [edi+1]
.text:004270FB                 mov     [ebx], ecx
.text:004270FD                 jz      loc_42718A
.text:00427103                 mov     ecx, [esi+1D4CCh]
.text:00427109                 and     al, 0FCh
.text:0042710B                 add     eax, 4
.text:0042710E                 add     ecx, eax
.text:00427110                 mov     [ebp+Size], eax
.text:00427113                 cmp     ecx, [esi+1D4D0h]
.text:00427119                 jbe     short loc_427146
.text:0042711B                 push    eax
.text:0042711C                 push    [ebp+Source]
.text:0042711F                 push    offset aIdSSizeI ; "Id: %s  Size: %i"
.text:00427124                 call    _printf
.text:00427129                 add     esp, 0Ch
.text:0042712C                 mov     ecx, esi
.text:0042712E                 push    offset aMemory  ; "Memory"
.text:00427133                 call    sub_426E67
.text:00427138                 cmp     dword_71EE10, 0
.text:0042713F                 jnz     short loc_427146
.text:00427141                 call    sub_46841F

По адресу 427119 он перестает прыгать и далее через пару колов ведет на messageboxa с фразой "всё плохо", спрашивает про автосейв и выходит.

Печально, в своё время в planescape`е было попроще, но там directdraw.

Ну, раз такие наполеоновские планы, то ждемс первого релиза. Если будут нужны тестеры, то свисти

 

Это запрос блока памяти из локальной кэш-памяти игры. При старте игра берет из heap ~16 Mb для D3D режима или ~27 Mb для SW, и затем использует для подгрузки/выгрузки в нужные моменты различных элементов из ресурсов и прочих подобных целей. Если дело в кэше, то его без проблем можно расширить до любых пределов, поскольку создается на куче, а не лежит в сегменте данных. Я ранее этого не делал, поскольку не думал, что с этим проблемы могут быть (и у меня их не было). Но возможно в высоких разрешениях на больших картах туда слишком много чего грузится единовременно для скорости отрисовки картинки, и места не хватает (особенно в случае улучшенных текстур из .hwl). Попробую сам добиться ошибки. В любом случае в ближайшее время (завтра, наверное) выложу патч (0.2.7fix2) с увеличенным раза в три кэшем на предмет проверки.

В Planetscape-е может переменными пользовали вместо констант при создании интерфейса. В MM почти все параметры интерфейса (и много чего прочего) являются константами, вшитыми в сам код, и из-за этого жестоко прооптимизированными компилятором. Из-за этого их зачастую бывает очень проблемно и найти, и изменить. Тут не важно, directdraw (SW режим его использует, вообще-то) или direct3D, дело в стиле кодирования (массированное использование констант).

Планы не наполеоновские, дело только во времени. Все основные процедуры уже известны (>50% от общего количества, т.е. за исключением всякой расчетной мелочевки, которую использовать отдельно смысла нет), надо только доделать перехват их всех через .dll (чем я постепенно и занимаюсь). Что конечно нудная рутинная работа - наподобие патчинга разрешения, делавшегося ранее. Но более-менее одноразовая, и в дальнейшем можно будет с удобствами делать расширение/усовершенствование игры на языке высокого уровня, без всякой возни с низкоуровневым кодом, патчингом и т.п. (причем для всех mm6-8 одновременно при желании - большинство процедур у них одинаковые).

Пока это не сильно быстро делаю просто потому, что редактор важнее, и надо хотя бы что-то приблизительное собрать, чтобы нормальные моды было более-менее удобно делать. Никакие .exe-навороты не изменят того, что сами оригинальные игры многие RPG-шники либо почти наизусть знают, либо хорошо помнят. Соответственно, переигрывать без существенных изменений в их контенте станут лишь очень немногие - несмотря ни на какие усовершенствования .exe. Тому свидетельством небольшой интерес ко всяким патчерам и большой интерес к модам (даже с малым количество изменений) на зарубежных форумах, например. У нас трудно сравнить, поскольку существующие моды делаются на английском, с которыми у нас не очень многие дружат - но тоже самое скорее всего.

В любом случае работа долговременная, быстрых результатов ждать не следует, будут постепенное движение в заданном направлении, о котором можно будет судить по выкладываемыми версиям (если более месяца ничего не будет, значит, работы временно приостановлены из-за полного отсутствия свободного времени). Если кто-то сможет сделать что-то быстрее (тот же редактор), тем лучше, я тогда больше внимания стану уделать работам по .exe. Ну или наоборот. На английском форуме, кстати, довольно много людей присутствует (в том числе наших), которые тоже над MM работают - в той или иной области. Если есть желание, можно с ними попробовать совместно делать что-то для скорейшего достижения результата.

В общем, заболтался я тут Перехожу в обычный режим...

 

Хм, вызвал и у себя такой баг. Выставил в окне 1600x1200 (в полноэкранном моник не держит), вылетело сразу. Видимо, кэша не хватило уже на старте - в отличие от более низких разрешений, где переполнение возникало только при определенных условиях. В аттаче патч с увеличенным размером кэша (т.е. +1 исправление). Надеюсь, что вылетов больше не будет, поскольку 1600x1200 снова работает нормально. Спасибо за тестирование