Оригинальная игра MMDoC была закрыта 31 октября 2016. И до января 2019 в нее невозможно было поиграть. Теперь это возможно с MMDoC Revival.

MMDoC Revival - это мод оригинального клиента MMDoC + новые онлайн-лобби и сервер, созданные с нуля.

Разработка MMDoC Revival не прекращается.
Текущая версия именуется альфой только потому, что еще не весь запланированный функционал реализован.
В MMDoC Revival уже исправлен ряд багов оригинальной игры. И MMDoC Revival стабильнее оригинального MMDoC.



Страница загрузки

* проект развивается не очень быстро, так как основные мои силы и время уходят на Герои 3.

Давно не публиковал здесь инфу.
Большинство обнов до этой касались онлайна. Эта - нет.

5.0 RC61 -> 5.0 RC63 (18.11.2019)

Для тех, кто такой же внимательный, как я: ссылка на гитхаб с сорцами в первом посте.

gamemazahist, отличный враппер.
В список совместимых игр можно добавить HoMM III: Рог Бездны
Однако враппер не совместим с HD-модом для Героев 3 и с разрешениями отличными от оригинального 800x600.
А без HD-мода в Героев 3 сейчас мало кто играет.
В HD-моде мной реализован схожий функционал, но фильтрация производится посредством CPU.
Я давно хотел использовать GPU, но я не шарю в Direct3D/OpenGL а времени и особого желания разобраться не было.

Не мог бы ты поделиться исходниками, для того, чтобы я включил функционал твоего враппера в HD-мод для Героев 3?
Ну а если ты против, то я мог бы рассказать, как добавить поддержку HD-мода в твой враппер.

Он есть же. Первый в списке: Nearest. Хотя я лично все же с SaI в SW поиграл бы.


Ну если ты не пользуешся стретчингом, а играешь в масштабе 1:1, то для тебя смысла нет.
А так смысл в существенном увеличении быстродействия.
Даже на моем бодром ЦП (ноутбучный i7) и разрешением экрана всего лишь 1366х768
c фильтром xBRZ + ... максимальный фпс в героях ниже 60 и это заметно.
Заметны лаги при отрисовке в некоторые моменты (при быстром скроллинге списков, карты; хота в бою начинает пропускать кадры, чтобы уложиться в назначенные тайминги отрисовки).
Более того, считаю в идеале максимальный фпс в героях не должен быть ниже 125, у меня такой фпс выдает только Bilinear SharperX2 (M)

У людей с 4К экраном и слабеньким ЦП вообще все печально.
Вот я недавно, в одном из релизов HD сделал игру DPI aware.
(Для тех кто не в теме, если в винде (Vista и выше) выставить масштаб > 100%, например 150%, то старые виндовые не DPI aware приложения система стретчит со 100% до 150% сама (мыля их при этом). Т.е. в версиях ХД до этой
в таком случае часть работы по масштабированию выполнял ХД, а часть - винда. Теперь же это полностью делает ХД.)

Так мне после этого очень сильно жаловался один пользователь с 4К монитором, что у него даже c фильтром Bilinear SharperX2 появились тормоза до неиграбельности. Решилось это конечно же переключением в 32-bit true режим, в нем в фулскрине при выборе разрешения меньшего чем разрешение экрана картинка масштабируестя стандартными средствами видеокарты.

Протестил на днях несколько десятков разных фильтров.
С удивлением обнаружил, что для героев просто превосходен фильтр SaI.
Запилил несколько его вариантов: SaI + Bilinear Sharper, SaI + Bilinear SharperX2, SaI + Bilinear SharperX3.
И теперь для меня лично это лучший фильтр для разрешений экрана HD и FHD.

Именно текст с ним получается лучше чем с любым из других ХД-шных фильтров.
Картинка тоже довольно балансная получается. Я бы сказал эффектом дизеринга. И довольно гладкая, но не такая прилизанная как с xBRZ.

Тем кому нравится bilinear SharperX2, думаю он тоже понравится.
Скорее всего заменю им текущий UltraSaI в будущем обновлении ХД.

Core i3-6006U - это слишком слабый проц. для xBRZ + Bilinear и FullHD.
попробуй Scale2x... , ну или Bilinear Sharper X2 (M)
К сожалению комфортная игра с xBRZ в HDмоде доступна преимущественно на +- топовых ноутбучных процессорах.
Хотя разным людям кофортен разный ФПС..

не будет


Не будет такого. Герои изначально спроектированы и разработаны так, что состояние игры хранится у клиента и менять это состояние может только клиент, т.к. никакого сервера изначально не предполагалось. Мой лобби-сервер лишь предоставляет канал связи между двумя клиентами, которые обмениваются данными между собой реализованым в 1999 году способом.
Проще написать игру с 0 с учетом клиент-серверной архетиктуры, чем перенести состояние игры и логику на сервер в уже имеющейся с помощью модинга.

100% верного распознавания сделать невозможно, но какие-то вещи по борьбе с этим явлением планируются.

в планах это есть. но сделать это не просто и приоритет у этих задач низкий.

Для режимов с 32-bit True - не корректный.
В режимах с 32-bit True _pcx16_ должен быть на самом деле _pcx32_

т.е. 1 пиксель - 4 байта XRGB8888, а не 2 байта RGB565
размер сканлайна и всего буфера соответсвенно в 2 раза больше.

Если ты вызываешь оригинальный конструктор, то в хд на него стоит хук который устанавливает измененные размеры сканлайна и буфера.
А вот заполняешь ты картинку судя по всему 2х-байтовыми значениями RGB565. Нужно - 4х байтовыми XRGB8888.

узнать битность режима можно например так:

Значение байта по адресу (0x5FA228 + 3) будет равно 2 при оригинальном 16-битном режиме и равно 4 при 32-битном.

правка байта по адресу (0x5FA228 + 3) в ХД применяется в начале вызова функции WinMain по адресу 0x4f80c0


Если помнишь, то в этих (32-bit True) режимах так же не работает цветной эровский текст, т.к. отрисовка символа (fnt::DrawCharacter 0x4B4F00) полностью переписана.

Патчер версии 4.3 + map-файл: скачать

В DIRECT_ HiHook наша замещающая функция должна 100% соответствовать соглашению о вызовах замещаемой.

т.е. если мы ставим хук на __thiscall функцию, то наша должна быть тоже __thiscall, а точнее принимать первый аргумент в ecx, остальные в стеке.
если мы ставим хук на __fastcall, то наша должна принимать аргументы в ecx, edx и стеке.
если на __cdecl, то наша функция должна возвращать управление по retn, а не по retn (4 * колво аргументов в стеке) как это делают __stdcall, __fastcall, __thiscall

В VC++ нет проблем с объявлением __stdcall, __cdecl, __fastcall функций
__thiscall объявить нельзя, но вместо нее можно использовать __fastcall (a1, no_used, a2, ...)

Не знаю как с этим обстоят дела в Делфи/Паскале. С __stdcall проблем не должно быть, __cdecl вроде тоже поддерживается, а вот насчет __fastcall и __thiscall я не уверен.

DIRECT_ HiHook не передает указатель на хук в замещающую функцию и не создает никаких мостов, он передает управление сразу прямо на нашу замещающую функцию.

map сделаю к следующей версии патчера, которая выйдет на днях.

Berserker, в патчере целиком и полностью забито на многопоточность.
Точнее в патчере:
1. нельзя создавать/ставить/отменять патчи/хуки в несколько потоков.
2. нельзя выполнять код с LoHook и HiHook (кроме DIRECT_) хуками в несколько потоков.
можно в несколько потоков выполнять Asm и DIRECT_ HiHook хуки.
3. нельзя пользоваться методами VarInit и VarFind в несколько потоков.


Вообще-то обратно возвращаю.

Здесь последний патчер версии 4.2.9.1, хэдер для C++ версии 4.2 и pas-файл версии 2.1:
скачать патчер SDK

я не понимаю зачем давать пользователю LoHook'a возможность обращаться к адресу затертого кода в мосте
и зачем вызывать такое внутри Handler, ведь на момент вызова этого будет неактуальным и непредсказуемым содержимое регистров.

после return EXEC_DEFAULT в Handler
в мосте происходит следующее:
1. значения всех регистров из контекста (HookContext::eax, ...) копируются в соответствующие регистры
2. выполняется затертый код (затертая команда 1, затертая команда 2, ...)
3. прыжок на HookContext::return_address. Если внутри Handler он не изменялся, то это будет адрес после затёртых команд в исходном коде.
Что тут тебе еще может быть нужно, я не понимаю.


проблем c уcтановкой ЛоуХука на команды изменяющие esp - нет.



Здесь главное то, что после выполнения затертого еще можно выполнить еще какой-то свой код внутри Handler.
Под затертым я имею в виду реально затертое (это может быть джамп другого хука, о котором мы не знаем),
А так-то мы всегда можем в Handler продублировать затираемый оригинальный код манипуляциями с HookContext::eax, ...

переделал свой тест

добавил в тестируемый код pushfd - popfd
и добавил еще 2 варианта





old - это то как реализовано перемещение регистров в стек и обратно в последнем опубликованном patcher_x86 4.2.8
через кучу, т.е. некоторые значения проходят путь: регистр -> куча -> стек -> куча -> регистр.

new - это новая реализация: регистр -> стек -> стек -> регистр

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

Я что-то не понял вопроса.
Всмысле можно ли поставить LoHook который ничего не делает (просто выполняет затертый код)?
Да, можно:

или нужно что-то вроде:

если да, то такое нельзя сделать.
такое есть в WriteAsmHook:
_PI->WriteAsmHook("какие-то команды....; _ExecDefault; какие-то команды...", 0);


для LoHook нет понятия оригинальной (замещенной) функции.
LoHook устанавливается просто на код. Что там за код под ним - не имеет значения.

Я из кода эры не очень могу понять как устанавливается HOOKTYPE_BRIDGE хук.
В самом мосте адрес возврата у тебя не пушится.
Но в контексте он есть, так?
Значит от попадает в стек до выполнения моста, так?
Значит перенаправление на сам мост из оригинального кода идет посредством call?


У меня же перенаправление на мост идет посредством jmp
а адрес возврата помещается в контекст внутри моста.

Второе. Я правильно понимаю что в твоем HOOKTYPE_BRIDGE мосте, если Handler возвращает EXEC_DEFAULT,
то мост игнорирует адрес возврата из контекста и прыгает обратно туда, куда должен по умолчанию?

У меня же в мост прыгает по адресу возврата из контекста , который мы возможно изменили внутри Handler, в любом случае: вернул ли Handler SKIP_DEFAULT или EXEC_DEFAULT

озадачился я вопросом скорости выполнения моста
состряпал тест вот с таким кодом:




скачать тестовый экзешник

результат несколько неожиданный

на моем рабочем ноуте такой:
pushad... : 3074
push edi...: 2386
push eax...: 2590

на лобби сервере для Хоты:
pushad... : 6719
push edi...: 4547
push eax...: 4625

* можно посмотреть в отладчике что тест выполняется честно
* при перестановке местами вариантов результаты теста не меняются

то есть pushad получается самым медленным.
а именно та портянка, которая используется сейчас в патчере - самая быстрая.


***

приведенный мной выше код моста я сократил и убрал перемещение значений esp и регистра флагов через кучу:

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

вобщем теперь переживать из-за размера моста можно будет меньше.

кстати в дампе патчера есть записи
bridge memory - это память выделенная патчером под все мосты.
bridges sizes sum - это суммарный размер всех мостов.

в патчере в мосте лоу-хука до сих пор портянка команд на сохранение каждого регистра
Для все той же обратной совместимости.
Более того, в коде моста много данных в регистр/стек попадают через кучу (временные переменные).
сейчаc код моста вот такой:


Порядок регистров, адреса возврата и регистра флагов здесь продиктован лишь обратной совместимостью.
Да, можно изменив порядок этого всего внутри HookContex сделать короче и красивее.
Но мне лично лень ломать голову как это сделать
я не ASM-нинзя, здесь скорее кто-то вроде MasterOfPuppets нужен.
Предложите ваше решение и я добавлю в патчер "NewFastLoHook" хук. а старый LoHook останется для обратной совместимости.

Но вообще от этой страшной медленной портянки никто, кроме тебя не страдает.
Да и начиная с версии 4 используя PatcherInstance::WriteAsmHook или Patcher::WriteAsmCode можно легко написать низкоуровневый хук точно и тонко самому определив код его моста.



актуального pas-файла нет, так как он уже несколько лет (!) никому не нужен.
можно использовать старый, но, очевидно, не будет доступен добавленный позднее функционал (например Asm-патчи и Asm-хуки)

Здесь последний патчер версии 4.2.8, хэдер для C++ версии 4.2 и pas-файл версии 2.1:
скачать патчер SDK

Сейчас я в отпуске. Вернусь, покажу пример модинга героев 2. Я же начал делать ХД мод для двойки, но запнулся о локализацию, просто обломало ее делать. И работа дальше не пошла, хотя двойка (экзешник с сигнатурами) - благодатнейшая платформа для модинга.

Так нужый батлфилд (bmp) и так достаточно закинуть в папку _HD3_Data\Common, раз уж обсуждение в теме ХД.

Установи Microsoft Visual C++ 2008 Redistributable Package:
https://www.microsoft.com/ru-ru/download/details.aspx?id=29

Чем еще заниматься людям, кторые (утрируя) умеют только пиксели полировать и отлаживать тени? Это художники должны новый функционал реализовывать? C помощью чего, фотошопа?
Вся разработка игры бОльшую часть самой важной и успешной истории в хоте держится на одном(!) человеке. Я в свое время помог с редактором карт, еще человек сейчас сделал редактор шаблонов. Но саму игру на 99,5% делает один человек.