Fallout 2 - Reference Edition: Изучаем и улучшаем движок игры

[Jordan]

Fallout 2 - Reference Edition

---

Приветствую.

 

Некоторое время назад, юзер alexbatalov, на своем гитхабе опубликовал декомпилированный код оригинального движка fallout 2 на си.

 

Сам проект.

https://github.com/alexbatalov/fallout2-re

 

Собственно, и че?

Отвечаю, скомпилировав данный код, возможно собрать оригинальный двиг и играть. Сам автор написал, что еще не перенесено 5% функционала.

 

Игра запускается, и частенько багует, автор исправляет ошибки и полирует код.

 

Я предлагаю, в данной теме обсуждать идеи по изменению кода, возможно добавление нового функционала.

На данный момент, у меня получилось собрать двиг под MSVC 2022, но для этого пришлось физически добавить библиотеки zlib и fpattern. Изменить файл сборки. С zlib получилось немного костыльно, требуется поправить данный вариант.

 

Как решу проблему со сборкой, сделаю форк и опубликую на гитхабе. Я могу конечно сделать коммит включающий zlib код, но думаю, автор отклонит.

 

Ставлю первую задачу для себя.

Сделать запуск игры в окне. Игра юзает старый directx захватывающий эксклюзивный режим экрана. Мои попытки изменить инициализацию directx не дали плодов. Пока экспериментирую.

 

Двиг интересен для изучения функционала игры. С++ пока не возможно использовать для разработки, но я уверен, со временем решим данную проблему.

 

Исходники открывают, все двери к модификации игры, это перенос нативно в Linux с помощью библиотеки SDL2. Добавление новых форматов, png изображений, 32 битный цвет. Нативные высокие разрешения экрана. Изменение геймлея, и чего угодно. Но это будет возможно, после погружения в суровый си код. В принципе код не так страшен.

 

Жду бурного обсуждения. 

 

Ну а пока погружусь сам в изучение движка.

добавлено позже

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

 

Сообщение

https://github.com/alexbatalov/fallout2-re/issues/59

[Mr.Sталин]

Джордан ты как только что из лесу вышел) Код движка давно изучен и лежит в базе IDA (только рекомпилировать нельзя).

 

Последние 5-10 лет не замечал от тебя ни какого рвения по добавлению нового функционала в фоллаут в sfall.

 

Все что необходимо уже добавлено в sfall, и необходимые доработки/улучшения можно делать внутри sfall.

 

Ты это подожди сейчас у тебя пройдет эйфория от конфетки в  виде исходников - и все будет как прежде, нужно просто переждать))) 

добавлено позже

с помощью библиотеки SDL2

говнище а не библиотека. пример этого говнища можно видеть на примере того заброшенного движка на букву F - где в режиме дебага я получил пошаговую стратегию в 5-10фпс на пне4.

в релизе максимум было в районе 30-40 - против до 1000 у ванильного фола.

на эту проблему еще указывал фобос что двиг получился тормозной для стареньких компов. 

[Jordan]

Джордан ты как только что из лесу вышел) Код движка давно изучен и лежит в базе IDA (только рекомпилировать нельзя).

 

Я простой богобоязненный программист на C#. Мне эти ваши хексы и смещения непонятны))

 

Последние 5-10 лет не замечал от тебя ни какого рвения по добавлению нового функционала в фоллаут в sfall.

Сорь не знал, что нужно каждый год было отмечаться в журнале посещений и модификаций фаллоута))

Я больше скажу наверно лет 13-14 не занимался моддингом.

 

Все что необходимо уже добавлено в sfall, и необходимые доработки/улучшения можно делать внутри sfall.

Sfall вещь хорошая, но когда есть непосредственно исходники, лучше. Добавление фич легче, не нужен ассемблер, смещения в движке и т.д

 

Ты это подожди сейчас у тебя пройдет эйфория от конфетки в  виде исходников - и все будет как прежде, нужно просто переждать))) 

Исходники фола, даже на суровом декомпилированном си это клево))

 

говнище а не библиотека. пример этого говнища можно видеть на примере того заброшенного движка на букву F - где в режиме дебага я получил пошаговую стратегию в 5-10фпс на пне4. в релизе максимум было в районе 30 - против до 1000 у ванильного фола. на эту проблему еще указывал фобос что двиг получился тормозной для стареньких компов. 

 

Фол юзает просто бэк буффер памяти и все картинки копируются на нее. SDL2 создает текстуры, на каждый кадр анимации, после чего покадрово воспроизводит. Еще в SDL2 нет пулов памяти, для SDL_Surface. Да есть проблемы для 2D.

[Mr.Sталин]

Тут подумалось: А не придет ли завтра Беседа и не попросит ли прикрыть "ваши" исходники - так как это по сути дизассеблирование + прямое копирование и выкладывание кода в открытый доступ.

добавлено позже

Я простой богобоязненный программист на C#. Мне эти ваши хексы и смещения непонятны))

а что ты тогда забыл в СИ ))

[Jordan]

В России сейчас с этим проще. Объявляем принудительную лицензию и юзаем как хотим) Вообще на изи))

 

У забугорников только с этим проблемы.

добавлено позже

А чё это ты так скромненько выделил ваши исходники?) Что можно скопировать, уже наше)

[Mr.Sталин]

Sfall вещь хорошая, но когда есть непосредственно исходники, лучше. Добавление фич легче, не нужен ассемблер, смещения в движке и т.д

У тебя не правильное или устаревшее предоставление об организации sfall.

Сейчас в sfall можно писать код на c++, а хак в exe делается только как точка входа из exe в код сфала - все просто как два пальца.

По этому я не вижу смысла в этих рекомпилированных исходниках - ну а как референс для вставки кода в sfall годится.

добавлено позже

Ладно разбирайся с исходниками, для меня там все равно ничего нового нет.

 

Кстати попробуй расширить структуру игрового объекта Object - это единственное, что нельзя сделать в sfall (без полной рекомпиляции), добавишь новые поля для для чего нибудь нового.

[Jordan]

У тебя не правильное или устаревшее предоставление об организации sfall.

Сейчас в sfall можно писать код на c++, а хак в exe делается только как точка входа из exe в код сфала - все просто как два пальца.

По этому я не вижу смысла в этих рекомпилированных исходниках - ну а как референс для вставки кода в sfall годится.

добавлено позже

Ладно разбирайся с исходниками, для меня там все равно ничего нового нет.

 

Кстати попробуй расширить структуру игрового объекта Object - это единственное, что нельзя сделать в sfall (без полной рекомпиляции), добавишь новые поля для для чего нибудь нового.

С sfall мы намертво прибиты к оригинальному екзешнику игры. И это реальный стопор.

 

Попробую расширить, но у меня есть предположение, что так как просто файлы хранятся в бинарном формате. Возможно что где то зашито fread sizeof(object). Как буду вечером у ноутбука, посмотрю.

[Mr.Sталин]

С sfall мы намертво прибиты к оригинальному екзешнику игры. И это реальный стопор.

согласен.

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

[Jordan]

согласен.

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

По мне так на си все очевидно, минимум абстракций. Код реально читаем.

 

Не знаю где этот парень сидел, но он сделал отличную работу.

 

Переименовать мы и сами можем. Сейчас современные IDE функциональны.

 

Проблема с исходниками в глобальных переменных. Видел наверно extern var. И так по всему коду. Тяжко отлаживать.

добавлено позже

Сейчас главное сделать фол в окне. И есть подвижки для C++. Может весь код обернуть extern C {}

добавлено позже

Все таки плюс языка си прямолинейность Что написано, то и делает.

[Mr.Sталин]

Все таки плюс языка си прямолинейность Что написано, то и делает.

А что другие, если написано то делают что-то другое?)) может читать просто не умеем.

По факту пока имеем код лапшу.

[Jordan]

А что другие, если написано то делают что-то другое?)) может читать просто не умеем.

По факту пока имеем код лапшу.

Спокойно товарищ, все умеем и как надо, читать и понимать. Код лапша, есть немного. Самая жуть это конечно интерпретатор. 6k строк отборной лапшы))

Меня больше напрягает графическая часть, код инициализации графики, особенно части directx. Ппц как запутано.

Нет другого кода. Как говорится что есть, то есть.

Понятно, что нет цели чик чик и в продакшн. Потихоньку перетягиваь функционал sfal'а в двиг. Но для этого нужно, конвертнуть исходники для компиляции С++.

добавлено позже

У меня есть желание вручную исправить все ошибки при компиляции С++ компилятором. Но мне нужен конечный вариант исходников. А то вложишь силы и время сделаешь. Функции переименуют, добавятся файлы и хрен смержишь.

[Mr.Sталин]

У меня есть желание вручную исправить все ошибки при компиляции С++ компилятором. Но мне нужен конечный вариант исходников.

Да куда ты спешишь там еще 50% (а то и больше) кода надо приводить в удобоваримый вид, переменным не даны имена одни V##

[Jordan]

Добавление полей в Object поломает совместимость с proto файлами. Добавление и изменение структур персонажей, предметов, учитывается при чтении и записи proto файлов. После перевода proto файлов в тексовый формат, возможно будет безопасно расширять данные структуры.

добавлено позже

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

добавлено позже

В принципе это не критично, просто требуется обработать напильником

[Jordan]

Предлагаю информацию о характерихстиках криттеров, предметов, тайлов и сценери хранить в бд sqlite.

 

Возможно и текст лучше хранить в бд.

 

Плюсы очевидны. Легко массово изменять характеристики простыми запросами update. Читать select. Можно делать любые выборки по критерию. Легко создавать новые таблицы, специфичные настройки для геймплея.

 

Минусы нужно чуть подучить sql, как бекенд разработчик скажу, что сложного в языке запросов нет. Упраздняются форматы протофайлов, msg, ini файлы для настройки случайных встреч.

 

Sqlite можно просто вкомпилить в движок, написать удобное api. Загрузить криттера просто select * from critters. И заполнить полученными данными структуру critter в движке.

 

Думаю, что идея не плохая.

добавлено позже

Уточню, ни все могут понимать о чём я говорю.

 

Sqlite это встраиваемая файловая реляционная база данных. Бд это просто бинарный файл, позволяющий хранить любую информацию. Язык запросов использует sql, как редактор можно взять dbeaver.

[Mr.Sталин]

Добавление полей в Object поломает совместимость с proto файлами.

Добавлять надо в конец структуры.

Может ты куда-то не туда добавил, при чем тут протофайлы - я о структуре которая хранится в памяти во время игры и которая сохраняется в карте при сохранении игры.

Хотя может ты движок еще игры не знает.

[Jordan]

Добавлять надо в конец структуры.

Может ты куда-то не туда добавил, при чем тут протофайлы - я о структуре которая хранится в памяти во время игры и которая сохраняется в карте при сохранении игры.

Хотя может ты движок еще игры не знает.

 

Таки да. Как оно в движке устроено, информации в моей голове крохи. Изучаю пока реверснутый движок.

[Jordan]

Мини план на будущее, хочу зафиксировать в каком направлении хотел бы развивать двиг. 

Видение, как бы я хотел улучшить внутреннюю структуру движка.

 

1. proto файлы, map - карты перевести в текстовый формат. json или xml  

Данное изменение позволит отвязать двиг от работы с бинарными файлами и позволит редактировать текстовые файлы другими редакторами. Так же это упрощает парсинг. Позволяет легко добавлять новые атрибуты и расширять формат.

 

2. Убрать из форматов привязку к id. К примеру у тайла есть прототип с его настройками, при загрузке карты, загружается proto.lst и уже по id(номер строки) получает имя файла, и уже загружает прототип. В данных файлах прописывать полное имя, на которое ссылается тайл. В картах тоже указывать не id а имя файла.

Данное изменение упростит добавление новых прототипов и карт. Ресурсов, графики, звуков. Важно обеспечить, что бы движок не лазил в файл регистрации, где бы вычитывал соответствие id -> имя файла. 

Данную концепцию применить ко всем возможным форматам игры. При добавлении города, нужно просто в каталог maps добавить файл NewBestMyMap.json(содержит в себе не только карту, но и координаты на карте, точки перехода), движок при загрузке вычитывает весь каталог карт.

 

3. Разделить прототипы на два файла, proto/critter/base/jordan.json - базовые характеристики(значение стато и скилов), proto/critter/view/jordan.json - имя анимации персонажа.

Возможно добавить возможность наследования статов и скилов. Есть базовый файл кротокрыса, на его основе хотим создать другого более выносливого, можем добавить в текстовый файл имя базового файла + модификатор к примеру здоровья +30%. В итоге Если у базового кротокрыса было 100 hp в новом будет 130.

 

4. Продумать систему модулей для объединения модов. Что бы модули не заменяющие другие файлы, могли работать вместе. Типа как в в играх беседки. Но пока технически не представляю как.

 

5. Возможно заменить встроенные скрипты ssl на lua. Но для совместимости переконвертировать старые скрипты в lua. (Это явно не в первую очередь)

 

6. Мелочи, типа поддержка локализаций из коробки, если у нас картинка с названием на русском, а другая на английском, то лежать они будут по таким путям, art/scenery/russian/my.frm и для английского art/scenery/english/my.frm В зависимости от выбранного языка в настройках, будет загружаться определенный файл. И так для всех ресурсов, звуки, тексты, графика, субтитры для видеороликов, звуковые дорожки.

 

7. Отвязать двиг от винды, и портировать под linux.(SDL2, SFML) 

Плюсом даст, поддержку современных форматов изображений(png, jpeg) Звук (mp3, ogg), Видео.

 

8. Добавить нативные высокие разрешения экрана + 32 битный цвет картинке. Пусть старые фрм остаются в своем качестве, но новые форматы типа png и jpeg будут в 32 битном цвете.

 

9. Новый формат анимации. png + json с описанием кадров.

 

Это уже совсем будущее.

Далее понятно запилить 3D персонажей как в FOnline)) Или вообще добавить 3D с триметрической проекцией.

 

Собственно, пока всё.

добавлено позже

Чуть не забыл, поддержку utf8 для текста + поддержку современных шрифтов ttf.

[Mr.Sталин]

У тебя наполеоновские планы.
Хml полное дерьмо. Чтобы работать с бинарниками проще написать редактор (которые итак уже имеются) а не перелопачивать уже готовое. Конвертор в худщем случае если ты любитель копаться в файлах.
Невижу никакого смысла перекраивать все и вся на другие форматы.
Нус твое желание.

добавлено позже

2. Убрать из форматов привязку к id.

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

6. Мелочи, типа поддержка локализаций из коробки,

Такое в движке частично есть например для интерфейса, картинок - просто об этом не знают.
 

Это уже совсем будущее. Далее понятно запилить 3D персонажей как в FOnline

будущее - это когда уже после 2077 года ?)))
 

добавлено позже

Вся эта затея с этими исходниками просто один большой пиZдес. 

 

Я вижу только один путь это перенос всего функционала sfall из длл в новый ехе - но видя эти исходники на СИ, пропадает всякое желание возни с ними, и убивание тонны времени на это дело.

[Jordan]

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

 

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

 

На мой взгляд нужно вливаться в проект, новый двиг не осилим. А вот улучшить текущий вполне.

добавлено позже

Как раз для этих целей, дочитываю книгу: Майкл Физерс: Эффективная работа с унаследованным кодом.

[Jordan]

Экспериментирую с движком. Так и не получается, запустить в окне. Но получилось запустить в нативном 1366x768

 

добавлено позже

Вот эти строки отвечают за режим в окне

   

 

    if (IDirectDraw_SetCooperativeLevel(gDirectDraw, gProgramWindow, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN) != DD_OK) {

        return -1;

    }

 

Поменял так

 

    if (IDirectDraw_SetCooperativeLevel(gDirectDraw, gProgramWindow, DDSCL_NORMAL) != DD_OK) {

        return -1;

    } 

 

Документация 

https://docs.microsoft.com/en-us/previous-versions/ms785063(v=vs.85)

добавлено позже

Есть подвижки для выпиливания directx для видео и рисование просто в буфер ОЗУ. Это позволит выводить буфер, с помощью GDI, OpenGL, SDL.

И далее по списку, перенос на SDL, управление мышью, клавиатурой.

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

добавлено позже

На днях постараюсь закончить перенос на С++.

Для мержа с основной веткой, буду батником переименовать файлы обратно в .с
После обновления, обратно в .cpp

добавлено позже

Как первое изменение, хочу добавить новый конфиг, для изменения разрешения экрана игры. Будет второй файл fallout2new.cfg

[Mr.Sталин]

Экспериментирую с движком. Так и не получается, запустить в окне. Но получилось запустить в нативном 1366x768

тебе там надо переделать инициализацию DirectDraw7 и еще написать дополнительный код для того чтобы это работало в окне.

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

то что некоторые писали, что там есть смена режимов, то это была их дилетантская некомпетентность.

 

короче открываешь код sfall последней версии и смотришь как там реализован DirectDraw7

вот даже сслыку дам чтоб долеко не ходил https://github.com/FakelsHub/sFall-Release/blob/devUnofficial/sfall/Modules/SubModules/DirectDraw.cpp

думаю разберешься в моем С++ говнокоде))

[Jordan]

Мр.Сталин приобщайся уже к коду, он не кусается.

 

Таких делов натворим:)

добавлено позже

тебе там надо переделать инициализацию DirectDraw7 и еще написать дополнительный код для того чтобы это работало в окне.

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

то что некоторые писали, что там есть смена режимов, то это была их дилетантская некомпетентность.

 

короче открываешь код sfall последней версии и смотришь как там реализован DirectDraw7

вот даже сслыку дам чтоб долеко не ходил https://github.com/FakelsHub/sFall-Release/blob/devUnofficial/sfall/Modules/SubModules/DirectDraw.cpp

думаю разберешься в моем С++ говнокоде))

Спасибо за инфу. Да я не играл в нативном разрешении, но панелька уже уехала. Весь интерфейс захардкожен.

Норм код, мне вообще за говнокод платят.

[Mr.Sталин]

Не моих сил на наполеоновские планы не хватит.))

когда закончат с СИ кодом, исправят все внесенные баги, тогда и попробуем.

а сейчас там мне делать нечего.

 

можешь прикручивать SDL (который я не уважаю)

[Jordan]

Не моих сил на наполеоновские планы не хватит.))

когда закончат с СИ кодом, исправят все внесенные баги, тогда и попробуем.

а сейчас там мне делать нечего.

 

можешь прикручивать SDL (который я не уважаю)

Наполеоновские планы это мои мысли по реорганизации движка. Если я за это возьмусь, то только после полировки уже финальной версии кода. Явно не скоро. Просто буду развивать двиг, изучать код, баги править, фичи из sfall'а переносить.

 

Какой ты видишь альтернативу SDL? Отрисовка будет в буфер, SDL подходит для кроссплатформенности, и в нем так же минуя заморочки с текстурами можно выводить буфер . Будут те же +100500 fps.

добавлено позже

Ещё SDL можно собрать статически, и будет единый exe. Ещё плюс это поддержка большого количества платформ, android тот же. У тебя есть шанс стать android разработчиком.

[Jordan]

При компиляции C++ компилятором, всего обнаружено 351 ошибка. Пока исправил 150. Это простые ошибки, приведение void*. Есть посложнее. Но на сегодня хватит.

добавлено позже

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

добавлено позже

Для лучшего понимания кода, пытаюсь писать тесты насколько это позволяет код. К примеру есть работа с прото файлами. Я вызываю загрузку прото файла и передаю в функцию путь к прошнику. После чего. Я могу вызывать другие функции, которые изменяют или возвращают значения прото файла. Так же проверяю каждый вызов, что он возвращает правильные данные. К примеру читаем криттера, после загрузки мы знаем, что у него сила = 5 и проверяем данный стат. Если значения равны, то все работает как и было, но если нет значит я, при изменении кода, что то поломал.

Особенно написание тестов помогает в понимании происходящего под капотом. И при изменении определенного участка кода с уже написанными тестами, легко выявить какие изменения поломали логику работы, просто запустив написанные тесты.