Fo2: Как подружить CnC ddraw и sfall (враппер и шейдеры)

randomdude · 9 февраля

Бью челом. Есть такой враппер cnc-ddraw, и есть в нем возможность грузить кастомные glsl шейдеры для масштабирования картинки, в том числе всякие умные. Еще он умеет подменять внутриигровой курсор системным, что обеспечивает на удивление плавную и точную работу мышью (в sFall ни один из режимов работы с мышью такого не дает). Пользуюсь им в множестве старых игр типа Arcanum, использую кастомные шейдеры.

Cnc-ddraw отлично работает с родным, непачтенным fallout2.exe. Он бы и с sFall заработал бы, но вот незадача: cnc-ddraw сам выглдяит, как пара файлов ddraw.dll и ddraw.ini.

В связи с чем прошу добавить в sFall поддержку дополнительного враппера:

1) если sFall находит в корне игры файл sfall.ini, то все настройки sfall берутся оттуда, а не из ddraw.ini (fallback-имя для файла, когда нужно потесниться ради чьего-то еще ddraw.ini)

2) возможность указать в конфиге путь до следующей в цепочке фейковой ddraw.dll, куда будут идти все вызовы, обычно идущие в настоящий ddraw; сам ddraw.dll от cnc-ddraw можно переименовать во что угодно, лишь бы предназначенные для ddraw,dll вызовы передавались бы по цепочке туда.

3) по понятным причинам если указан дополнительно сторонний враппер, то sFall принудительно переходит в режим DX7 и отключает все связанные с DX9 функции, потому что весь постпроцессинг и оборачивание вызовов DirectDraw переходит в руки cnc-ddraw.

Аналогичным образом cnc-ddraw спокойно ставится в цепочку, например, с HD-модом для Heroes of Might and Magic III -- в моде выбирается классический режим без дополнительного оборачивания, в результате все QoL-эффекты мода присутствуют, а вот графические вызовы идут в фейковый ddraw.dll от cnc-ddraw, и весь постпроцессинг картинки переходит в руки cnc-ddraw. Хотелось бы что-то подобное для sFall...

По идее, с фоллаутами должно получиться как-то так:

ddraw.dll -- компонент sFall

ddraw.ini -- конфигурация cnc-ddraw под своим обычным именем, которое, увы, никак не поменять

sfall.ini -- альтернативное имя для конфигурации sFall: наличие такого файла проверяется перед тем, как пытаться загружать конфигурацию из ddraw.ini

ddraw2.dll -- переименованный ddraw.dll из комплекта cnc-ddraw, путь до которого указан в sfall.ini в качестве пути до следующего в цепочке фейкового ddraw

Игра обращается к ddraw.dll, тот делает свою работу и дальше по цепочке передает вызовы в ddraw2.dll, а ddraw2.dll уже решает сообразно своим настройкам, во что их оборачивать: DX9, OpenGL, GDI, или даже голый системный \SysWOW64\ddraw.dll (в последнем случае, конечно, игру перекосит).

Сам я привык играть со включенным 2X Scaling без постобработки, мне очень нравятся крупные резкие пиксели. Но поиграться с GLSL шейдерами очень бы хотелось. А вот для тех, кто терпеть не может пиксели, возможность масштабировать картинку через lanczos, catmull или jinc была бы настоящим подарком: в sfall настраиваем, допустим, 1366x768, выключаем 2X Scaling, и эту маленькую картинку на большой монитор (хоть 2К, хоть 4К) масштабирует уже шейдер из cnc-ddraw, a sFall продолжает заниматься чисто вопросами QoL и расширенного функционала.

В отличие от лежащих в интернете десятков готовых шейдеров GLSL, я нигде не нашел в формате .FX кода для lanczos, catmull, jinc и им подобных. Поэтому единственной альтернативой является встроенный в sFall линейный фильтр. Увы: он выглядит страшнее ядерной войны и даже с банальным catmull-rom рядом не лежал. Да и нет никакого смысла встраивать все это в sFall, если можно просто тупо в режиме DX7 передавать все вызовы дальше по цепочке в отдельную библиотеку, которая специально посвящена постпроцессингу (а такая библиотека давно существует и показывает отличные результаты, в том числе и в цепочке с другими врапперами)

Все-таки нашел, буду разбираться, но предложение свое пока что оставлю. Ибо GLSL -- сила, а еще cnc-ddraw умеет оборачивать DX7 в DX9 и DX12 (!)

Только что испытал на актуальной сборке Fallout Sonora от Foxx (sFall 5.0.6.2)

[Main]
HiResMode=1
[Graphics]
Mode=4
GraphicsWidth=1920
GraphicsHeight=1080
TextureFilter=0

Запускаю -- все работает, фильтром Nearest Neighbor аккуратно растягивает картинку на весь экран.

Далее добавляю

GlobalShaderFile=sharpen.fx

И все снова работает. Вообще все стоковые шейдеры из .\data\shaders работают.

Дальше кладу в .\data\shaders вот эти два файла

https://raw.githubusercontent.com/guestrr/WinUAE-Shaders/master/Lanczos-HiRes-SmartRes.fx

https://raw.githubusercontent.com/guestrr/WinUAE-Shaders/master/Jinc2-SmartRes.fx

И пробую что-то вроде:

GlobalShaderFile=Jinc2-SmartRes.fx

Не работает, на запуске мертвое зависание с черным экраном, приходится делать Alt-Tab и из консоли выполнять "taskkill /im:FSonora+DLC.exe /f"

Любой масштабирующий шейдер приводит к такому результату, а вот идущие в комплекте с sFall работают как часы, да и без них игра работает идеально.

Ради смеха ставлю с нуля английский Fallout 2 от GOG и, не применяя идущего в комплекте (древнего и протухшего) HD-патча, просто скидываю в корень игры cnc-ddraw с нужными мне шейдерами, но уже в формате GLSL. Все с первого раза запускается, 480p апскейлится до 1080p не страшным bilinear, а допустим jinc:

https://i.postimg.cc/65CXwxF9/1.png

https://i.postimg.cc/TxS3mdQ5/2.png

https://i.postimg.cc/tqg2F0d2/3.png

Pyran · 9 февраля

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

sFall это твик движка, а не враппер с шейдерами. sFall тоже умеет работать с шейдерами.

Чтобы картинка не была мелкой или зернистой, можно выбирать не FHD)QHD, а обычное HD.

А вот отключать sfall и передавать работу cnc, звучит, как: отключите двигатель самолета и передайте управление гребцам.

Есть еще ddrawwrapper версии 0.50 и он тоже запускает Fallout 2, файлы тоже имеют название ddraw.dll/ini, но это не делает его заменой sFall. Автомобиль с турбонаддувом, но без двигателя никуда не поедет.

9 часов назад, randomdude сказал:
[Main]
HiResMode=1
[Graphics]
Mode=4
GraphicsWidth=1920
GraphicsHeight=1080
TextureFilter=0

Так это стандартная настройка в sfall.

(Ручками, через меню игры или sf-configurator). И описано в faq.

9 часов назад, randomdude сказал:
GlobalShaderFile=sharpen.fx

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

9 часов назад, randomdude сказал:

не применяя идущего в комплекте (древнего и протухшего) HD-патча

Такой протухший, что дает самый простой метод включения и настройки разрешения и четкую картинку, а еще, именно его используют в свежих версиях sFall, но без внешнего файла конфигурации в виде "f2-res-config.exe". Сравните файлы.

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

Кстати, тут про уже есть тема про шейдеры, xBrz и прочие, думаю, лучше это обсуждать там.

randomdude · 9 февраля

Цитата

sFall это твик движка, а не враппер с шейдерами.

Когда я в sFall включаю режим DX9, происходит именно wrapping (оборачивание) вызовов ddraw в вызовы DX9. Разработчик вам то же самое скажет...

Цитата

sFall тоже умеет работать с шейдерами.

Правильно, потому что sFall -- это, помимо прочего, еще и враппер. Он использует DX9-шейдеры в формате .fx. Можно отключить оборачивание вызовов в DX9, оставив классический ddraw, и тогда оборачивания не будет, но не будет и шейдеров.

Цитата

Чтобы картинка не была мелкой или зернистой, можно выбирать не FHD)QHD, а обычное HD.

Я проще делаю -- включаю X2Upscale и получаю изображение из четких, контрастных квадратиков блоками 2x2 пикселя. Масштаб на большом мониторе получается, примерно как Fallout выглядел на 17" ЭЛТ мониторе в те года, когда вышел. Мне очень нравится такая картинка, я вообще люблю пиксели.

Но вот захотелось поиграть с фильтрами масштабирования Lanczos, Catmull, Jinc. Рендерить вьюпорт в 1366x768 точка-в-точку и потом растягивать до 1920x1080 одним из этих фильтров. Выглядит специфически, и я уверен, что такое многие предпочли бы тому, как привык играть я (просто крупные квадратики без фильтрации)

Цитата

А вот отключать sfall и передавать работу cnc, звучит, как: отключите двигатель самолета и передайте управление гребцам.

А где я вел речь про отключение sFall? Я говорил про отключение той части его функционала, которая как раз работает, как враппер. Это можно сделать уже сейчас -- просто поставив Mode=3 или ниже. Вместо оборачивания вызовов ddraw в DX9, они просто будут (с необходимыми изменениями) передаваться в настоящий .\SysWOW64\ddraw.dll, то есть как была игра на DX7, так и осталась, ничего не оборачивается по желанию пользователя.

И вот тут можно было бы эти необернутые вызовы направлять не в оригинал ddraw.dll, а еще в одну подставную библиотеку, выполняющую роль собственно враппера, где и GLSL шейдеры поддерживаются, и .FX, и даже оборачивание в DX12.

Более того, я прямо привел пример того, что двигатель самолета ни в коем случае не отключается: "в результате все QoL-эффекты мода присутствуют, а вот графические вызовы идут в фейковый ddraw.dll от cnc-ddraw". Просто на примере одной из игр, где так можно делать.

Цитата

Так это стандартная настройка в sfall.

Я ее процитировал, чтобы было видно, что враппер работает (Mode=4), если его отключить -- шейдеры работать не будут. Скажем так, умыл руки, потому что дальше мой пост рассказывает про то, как jinc / lanczos не работают.

Цитата

Обычный шейдер, который включается в настройках. Все делается используя sfall. Но бездумное включение, может ухудшить картинку.

Я немного разбираюсь в шейдерах... Почему и поднял весь этот вопрос. Как я уже написал в своем предущем посте, sharpen.fx и все остальные идущие в комплекте с sfall шейдеры отлично работают (пока включен встроенный в sFall враппер). Но среди них нет ни одного масштабирующего. Масштабирующий шейдер в sFall ровно один, и он контролируется параметром TextureFilter. Выглядит, как обычная билинейная фильтрация, то есть ужасно в сравнении с Lanczos, Catmull, Jinc и многими другими.

Цитата

А в гог и стим положили огрызок от sfall, со всем вытекающим.

Поэтому я и называю его протухшим -- они этот огрызок положили в 2015, что ли, году, а актуальный sfall обновляется постоянно. Я даже выяснять не хочу, что делает этот огрызок, если свежий sfall без него отлично работает.

На всякий случай повторю вопрос. Лежащие по умолчанию в .\data\shaders шейдеры у меня работают все, как и должны. Но там нет скейлеров.

А как заставить в sFall работать нормальный масштабировщик, например один из этих:

https://raw.githubusercontent.com/guestrr/WinUAE-Shaders/master/Lanczos-HiRes-SmartRes.fx

https://raw.githubusercontent.com/guestrr/WinUAE-Shaders/master/Jinc2-SmartRes.fx

На самом деле, проще всего поставить Mode=0 и подключить к sFall паровозиком cnc-ddraw, потому что в таком сценарии то, чем занимается sFall, вообще перестает как-либо пересекаться с тем, чем будет заниматься cnc-ddraw. А в папку Shaders у cnc-ddraw можно набросать любых что .FX, что .GLSL шейдеров -- работать будут все. cnc-ddraw для этого и сделан как бы...

Но вот незадача, у cnc-ddraw тоже библиотека и файл конфигурации называются ddraw.dll и ddraw.ini, а первым в цепочке должен обязательно идти sFall. То есть библиотека sFall должна сохранить название ddraw.dll, но при этом дальнейшие вызовы (при условии, что отключен встроенный враппер sFall, то есть Mode ниже 4) направлять не в .\SysWOW64\ddraw.dll, а в какой-нибудь ddraw2.dll, которым будет переименованная библиотека cnc-ddraw. А поскольку файл конфигурации cnc-ddraw по злой случайности называется ddraw.ini, то sFall еще будет вынужден в этом сценарии иметь fallback-имя для своего файла конфигурации, которое проверяется первым, на случай, если нужно занять ddraw.ini каким-то не имеющим отношения к sFall сторонним файлом.

Есть такой враппер dxwrapper, предназначен в основном для старых игр, использующих Direct3D стандартов DX7 и DX8, то есть абсолютно в Fallout бесполезный, но у него в документации хорошо объясняется, как с помощью RealDllPath к dxwrapper можно паровозиком цеплять еще сколько угодно других произвольных .dll, в том числе с другими врапперами: https://github.com/elishacloud/dxwrapper/wiki/Configuration

Цитата

By default when DxWrapper is wrapping a dll it will load the Windows System dll. However, if you need DxWrapper to load a different dll you can list that dll here. A use case for this would be if you want to use DxWrapper alongside some other wrapper like dgVoodoo or an existing game dll with the same name.

Note: this option only works if you either rename DxWrapper to match the name of the file you are wrapping (such as d3d8.dll or ddraw.dll) or if you are using this setting on the stub dll. To use this setting on the stub dll you will need to create a new ini file that matches the name of the stub dll and add this setting into that ini file.

Я этим много пользовался и продолжаю пользоваться в старых 3D-играх... Чего-то подобного, конечно, хотелось бы и от sFall. В смысле -- возможности перенаправлять вызовы в совершенно произвольную указанную пользователем библиотеку и читать настройки из файла с именем, отличным от ddraw.ini (наперед ddraw.ini, а если такое имя не найдено -- то как обычно из ddraw.ini)

Изменено 9 февраля пользователем randomdude

Pyran · 9 февраля

10 минут назад, randomdude сказал:

Поэтому я и называю его протухшим -- они этот огрызок положили в 2015, что ли, году, а актуальный sfall обновляется постоянно. Я даже выяснять не хочу, что делает этот огрызок, если свежий sfall без него отлично работает.

Определитесь, что вы считаете тухлым, старый, но рабочий sfall от Timeslip v2.1 (если к нему докинуть его же ddraw.ini) или Hi-res patch от Mash v4.1.8 (который исправно выполняет свои функции)...

17 минут назад, randomdude сказал:

А как заставить в sFall работать нормальный масштабировщик, например один из этих

Перейти в тему шейдеров не пробовали?

randomdude · 9 февраля

42 минуты назад, Pyran сказал:

Определитесь, что вы считаете тухлым,

Забудьте...

42 минуты назад, Pyran сказал:

Перейти в тему шейдеров не пробовали?

Вопрос был риторическим — я просто привел способ убедиться, что масштабирующие шейдеры в sfall не работают (а идущие в комплекте со sfall — работают, но среди них нет масштабирующих). Мне самому причина такой ситуации понятна.

Поэтому я просто подожду тут мнения разработчика, что он думает про целесообразность введения в sFall аналога функции CustomDllPath из dxwrapper. Плюсы такого решения я описал: sfall продолжает работать расширением движка, а вся постобработка, если пользователь так пожелает, сможет проводиться в cnc-ddraw с оборачиванием, на выбор пользователя, в: DX9, DX12, OpenGL, GDI.

Изменено 9 февраля пользователем randomdude

Pyran · 9 февраля

2 минуты назад, randomdude сказал:

росто подожду тут мнения разработчика

долго будете ждать

2 минуты назад, randomdude сказал:

Вопрос был риторическим

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

randomdude · 9 февраля

Цитата

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

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

1. Математически не предназначен для работы с 8-битной палитрой. При этом не играет роли, в каком графическом режиме запущена игра: 32bpp, 16bpp, 8bpp. Играет роль только то, сколько реальных оттенков будет рисоваться на экране. Мы с вами прекрасно знаем, что все ресурсы Fallout используют палитру в 256 оттенков, за исключением может новых говорящих голов из модов. Скармливая xBRZ такую палитру, вы всегда будете получать эффект, как будто кто-то дрожащей рукой очень тонким маркером "дорисовал" недостающие детали. Картинка не только становится более детальной, но и вместе с этим приобретает плохо передаваемое словами поганое качество.

2. Графика Fallout очень богата как на градиенты, так и на жесткий dithering (те самые фирменные "шум" и "зернистость"). Это сочетание -- вообще не то, для чего создавался xBRZ. Проверено на множестве старых игр. Лет 5 назад этот xBRZ пытались прикручивать ко всему, что плохо лежало, на него была мода. Закончилось тем, что им сегодня никто не пользуется, т.к. он не панацея. Создавался xBRZ вообще для масштабирования текстур на эмуляторах старых приставок, строго под определенные условия и особенности исходного материала.

3. sFall для постпроцессинга факультативно использует оборачивание (wrapping) вызовов ddraw.dll (2D-библиотека из комплекта DirectX 7) в вызовы DirectX 9, и уже в русле DirectX 9 прогоняет картинку через шейдеры формата FX. В данном сценарии это, мягко говоря, не самое оптимальное решение как с точки зрения быстродействия, так и с точки зрения результатов. То, что шейдеры FX отлично работают в ReShade, ENB и тому подобных расширениях для 3D-игр на основе DX9/11/12, абсолютно не значит, что они будут так же хорошо работать в нашем сценарии. Чтобы объяснить детально, мне понадобилось бы тут напечатать огромную простыню на 20 параграфов, поэтому прошу верить на слово. В разнообразных врапперах, ориентированных на старые 2D-игры, неспроста рекомендованный бэкенд -- OpenGL с его форматом шейдеров GLSL. У многих врапперов есть опция вывода через DirectX 9 (или даже 12), но все равно предпочтительный API неизменно OpenGL. Этому есть причины.

Как вы верно подметили, sFall это в первую, вторую и третью очередь -- расширение движка игры, дающее игре дополнительный функционал начиная от мощной поддержки модов и заканчивая возможностью компоновать окно игры (window compositing) так, чтобы UI и окно обзора образовывали прямоугольник такого размера и с таким aspect ratio, как хочет игрок. После того, как прямоугольник X точек на Y точек сформирован согласно желаниям игрока, sFall отправляет его на рендеринг одним из методов, который выбирается с помощью параметра Mode. Режимы с 4 по 6 дополнительно запускают встроенный в sFall враппер, который транслирует вызовы ddraw в DX9 и может рендерить конечный кадр множеством хитрых способов. Но вот это лишнее, потому что (по моему субъективному мнению) с задачей рендеринга и постпроцессинга гораздо лучше справится cnc-ddraw. Просто потому, что cnc-ddraw специально создан с целью трансляции ddraw из DirectX 7 в DirectX 9. Arcanum, Command & Conquer, Diablo и еще масса старых 2D игр -- cnc-ddraw существует специально для них, постоянно улучшается и обновляется.

А сейчас позвольте мне вам продемонстрировать, как это может работать на практике.

Я на коленке пропатчил cnc-ddraw 6.1 и SFALL 5.0.6.2 из этой сборки так, чтобы они работали вместе, как я и хотел. Делать так при каждом обновлении cnc-ddraw или SFALL -- долго и нудно, но в качестве демонстрации сойдет.

Ссылка для скачивания: https://www.mediafire.com/file/wredrdnfpvxt7ax/sfall-cnc-patched.zip/file

Структура содержимого архива:

.\Shaders\fallout-jinc2\fallout-jinc2.glsl	; подкрученный специально под палитру и стиль графики Fallout шейдер JINC2
.\ddraw.dll 					; пропатченная библиотека SFALL 5.0.6.2 из актуальной сборки Sonora от Foxx
.\ddraw.ini 					; отредактированный файл конфигурации SFALL 5.0.6.2 
.\f2_res.ini					; оттуда же, изменены 2 строки
.\wardd.dll 					; пропатченная библиотека cnc-ddraw 6.1
.\wardd.ini 					; файл конфигурации пропатченного cnc-ddraw
.\wardd.exe					; утилита конфигурации пропатченного cnc-ddraw (внимание: затрагивает только базовые параметры, для тонкой настройки нужно редактировать wardd.ini вручную)

Можно сразу все это распаковать в корень свежеустановленной сборки и играть, а можно распаковать без .ini-файлов поверх какого-нибудь другого мода на основе SFALL 5.0.6.2 и отредактировать тамошние .ini таким образом.

f2_res.ini:

GRAPHICS_MODE=0 		; Работаем только с нативными режимами sFall
SCALE_2X=0			; Категорически не нужно в этом сценарии

ddraw.ini:

[Main]
HiResMode=1 		; Само собой разумеется
[Graphics]
Mode=1 			; Не включаем враппер, перенаправляем все вызовы в wardd.dll
GraphicsWidth=1066 	; Чтобы картинка в игре выглядела достаточно крупно
GraphicsHeight=600 	; приблизительно в пропорциях, как на ЭЛТ мониторе
			; или как вариант помельче:
			; GraphicsWidth=1280
			; GraphicsHeight=720
TextureFilter=0 	; это уже не забота sFall
LimitFPS=0		; это уже не забота sFall

Про настройки wardd.ini можно почитать на гитхабе проекта

Если вкратце, то wardd.ini в архиве настроен так:

1. Рендерер -- OpenGL (вроде необходим 3.3, но могу и соврать)

2. Шейдер масштабирования -- fallout-jinc2

3. Максимальный FPS в игре ограничен текущей частотой обновления монитора (автоопределение)

4. Максимальное количество "тиков" ограничено текущей частотой обновления монитора (автоопределение)

5. Вертикальная синхронизация принудительно включена

6. Полноэкранный режим, включен фикс для беспроблемного Alt-Tab на любых ОС

7. Размер viewport в точках берется таким, каким его создает sFall (в моем примере это 1066x600, что составляет 16:9) и растягивается с помощью шейдера fallout-jinc2 на весь экран со строгим сохранением пропорций. Если указанное в настройках sFall разрешение viewport'a больше, чем текущее разрешение монитора, то cnc-ddraw наоборот, сожмет созданный sFall'ом viewport с помощью того же шейдера до текущего экранного разрешения (и все станет мелким-мелким, но все равно поместится). При этом разрешение монитора может быть любым, хоть 2560x1440, вручную его нигде указывать не надо. Достаточно в ddraw.ini задать размер viewport'а в точках так, чтобы его aspect ratio приблизительно совпадал с aspect ratio монитора, иначе по краям будут черные полосы. Размер viewport'a должен быть достаточно маленьким, чтобы UI и все элементы игры выглядели достаточно крупно -- для 16:9 это будут режимы 1066x600, 1280x720 и 1366x768.

В 1920x1080 у меня это выглядит как-то так:

https://i.postimg.cc/mT7WGyCT/Sonora1.png

https://i.postimg.cc/D2dtDfs6/Sonora2.png

https://i.postimg.cc/bpDjmhvD/Sonora3.png

Четкие шрифты, фирменное зерно и дизеринг, четкие очертания, более-менее плавные градиенты. Игра в 1920x1080 выглядит настолько близко к оригиналу в 640x480, насколько это возможно. Грамотно подобранные шейдеры GLSL -- это штука посильнее "Фауста" Гёте! Хотя, конечно, сам я предпочитаю играть без постпроцессинга с банальным SCALE_2X=1

Возможна проблема: на некоторых компьютерах после выхода из игры процесс "Sonora+DLC.exe" может оставаться невидимо висеть в бэкграунде, поэтому игра в следующий раз уже не запустится. Решение: убивать заснувший процесс консольной командой "taskkill /im:FSonora+DLC.exe /f" с админскими правами.

А чтобы не было таких вот побочек, нужно вместо патчинга .dll на коленке просто один раз встроить в sFall возможность перенаправлять вызовы в произвольную библиотеку + возможность читать конфиг sFall из файла, чье имя отличается от ddraw.ini, потому что ради одной игры разработчик cnc-ddraw не станет сам приделывать к своей библиотеке встречные костыли.

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

Изменено 9 февраля пользователем randomdude

Pyran · 9 февраля

1 час назад, randomdude сказал:

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

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

А пробовали нечто подобное провернуть с sfall 4?

Шейдеры были, наверно с момента появления sfall и убирать их особенно из sfall5 extended, и прочих версий никто не будет, но реализовать поддержку... Стоит поговорить с авторами обоих версий sfall, возможно, что и получится.

randomdude · 9 февраля

Цитата

Прежде всего, выделю все это в отдельную тему.

Как удобно, так и делайте.

Цитата

А пробовали нечто подобное провернуть с sfall 4?

Нет, но скорее всего тоже прокатит. А в каких обстоятельствах sfall4 строго необходим?

Цитата

Шейдеры были, наверно с момента появления sfall и убирать их особенно из sfall5 extended, и прочих версий никто не будет,

Их не надо убирать, их просто не имеет смысла развивать и дальше поддерживать. А были они там потому, что в тот же самый cnc-ddraw поддержку GLSL добавили не очень-то и давно. Все давно хотели шейдеров в 2D, каждый реализовывал как мог.

Цитата

Стоит поговорить с авторами обоих версий sfall, возможно, что и получится.

Нужно им отослать (возможно несколько раз подряд для верности) вот эту ссылку и попросить ознакомиться, как работает параметр RealDllPath во враппере dxwrapper. Сам dxwrapper для Fallout абсолютно бесполезен, это просто иллюстрация, как это реализовано в другом проекте.

В случае с sFall алгоритм будет очень простым:

1. Когда fallout2.exe запускается, он загружает фейковый ddraw.dll от Sfall, который выполняет произвольный код, а любые "рисовальные" вызовы либо отправляет по назначению в .\SysWOW64\ddraw.dll, либо вообще оборачивает в DX9 и дальше этим занимается d3d9.dll Так вот, первым делом этот произвольный код должен проверять, нет ли в корне игры конфига с альтернативным именем, например sfall.ini или ddraw2.ini или как-то еще. Если такой файл есть, это значит, что имя ddraw.ini занято чем-то еще, и конфигурацию sfall должен читать из этого файла со специальным именем, а ddraw.ini игнорировать. Если в корне игры присутствует лишь ddraw.ini, то очевидно это стандартный конфиг sfall и настройки нужно читать из него. Вообще, если название ddraw.ini создателям sFall непринципиально, можно навсегда переименовать конфиг sFall в "sfall.ini" и так впредь и оставить, чтобы не бодаться с cnc-ddraw.

2. В конфиге sFall должна быть переменная CustomDllPath. Если она не пустая, то все вызовы, которые фейковый ddraw.dll отправляет либо настоящему .\SysWOW64\ddraw.dll, либо оборачивает в DX9, начинают направляться уже не туда, а вот этой самой библиотеке с таким именно именем. Библиотека cnc-ddraw может называться как угодно, например ddraw2.dll, на ее работоспособность это не влияет. Вопрос только в том, чтобы игра, хоть напрямую хоть через целую цепочку костылей, свои вызовы отправляла именно в ddraw2.dll.

3. Как только CustomDllPath заполнена, независимо от параметра Mode насильно включается Mode=1, отключается SCALE_2X, включается GRAPHICS_MODE=0 и далее по списку -- любые манипуляции с рендерингом на стороне sFall отключаются, включая манипуляции с FPS, вертикальной синхронизацией, режимом "Single CPU" и всем, что умеет делать cnc-ddraw. Предел работы с графикой для sFall в этом сценарии -- это компоновка viewport'a чтоб было X точек на Y точек, панель сообщений шириной Z точек, скомпоновал viewport -- все, дальше просто шлешь ddraw-вызовы, но к библиотеке с произвольным именем из CustomDllPath.

При соблюдении этих условий библиотеку cnc-ddraw можно будет переименовывать во что угодно, а ее конфиг будет всегда называться ddraw.ini, но конфликта имен с sFall не будет, потому что его конфиг будет называться уже как-то по-другому.

Аналогичным образом можно будет цеплять вместо cnc-ddraw всякие DXVK for Windows и массу всяких других мулек, которые я не хочу перечислять, потому что в отличие от cnc-ddraw их полезность для движка Fallout равна нулю. Но мало ли что еще придумают крутого, а у sFall уже поляна накрыта.

Изменено 9 февраля пользователем randomdude

Pyran · 9 февраля

35 минут назад, randomdude сказал:

Нет, но скорее всего тоже прокатит. А в каких обстоятельствах sfall4 строго необходим?

sfall4 и sfall5 это два параллельно развивающихся проекта (если грубо), есть нюансы из-за которых от 5ки отказываются.

35 минут назад, randomdude сказал:

В случае с sFall алгоритм будет очень простым:

Я бы предпочел, чтобы sfall отрабатывал как он должен, а дополнительно, при режиме, допустим 7 и необходимых файлов CnC-ddraw, включался cnc-ddraw с нужными параметрами и шейдерами.

Будем смотреть, кто что скажет.

randomdude · 9 февраля

Цитата

Я бы предпочел, чтобы sfall отрабатывал как он должен, а дополнительно, при режиме, допустим 7 и необходимых файлов CnC-ddraw, включался cnc-ddraw с нужными параметрами и шейдерами.

А я именно это и предлагаю. Если CustomDllPath не указан, то все вызовы из sFall'овской фейковой ddraw.dll просто будут идти тем же путем, каким они идут сейчас. При этом в корне игры спокойно могут продолжать лежать cnc-ddraw.dll (назвать можно как угодно) и ее ddraw.ini: они просто не будут работать, если не перенаправлять вызовы от sFall'овской библиотеки к ним. А перенаправлять туда или не перенаправлять, решает только sFall исходя из того, что написано в его конфигурации. Если совсем утрировать мои три пункта, то нужно:

1. Файл конфигурации sFall перманентно переименовать во что-то вроде "sfall.ini", чтобы не было конфликта имен с конфигом cnc-ddraw, ведь его имя "ddraw.ini" прописано прямо в библиотеке cnc-ddraw. Я тупо перепатчил его на wardd.ini, но вообще так дела не делаются.

2. Приделать к sfall.ini новый параметр CustomDllPath, если он не пустой -- это значит, что все вызовы нужно дальше передавать по цепочке в библиотеку, имя которой указано в этом параметре. Сейчас вместо CustomDllPath я просто несколько упоминаний ddraw.dll (настоящей!) внутри фейковой ddraw.dll заменил на "wardd.dll", и все вызовы по цепочке пошли к ней, а уже от нее к настоящей \SysWow64\ddraw.dll. Но опять же, так дела не делаются.

3. Если CustomDllPath не пустой, значит, мы включили cnc-ddraw, и ряд параметров sFall автоматически переводится в режим совместимости с cnc-ddraw независимо от того, что там еще написано в sfall.ini: например, включается принудительный Mode 1, отключаются любые операции с координатами окна, его размером, ограничения FPS, etc. etc. etc., потому что все это передается под контроль cnc-ddraw.

Обнуляем CustomDllPath в sfall.ini, и cnc-ddraw отключается, а все остальные параметры в sfall.ini начинают работать как обычно. Пишем что-то в CustomDllPath, и нужный нам Mode=1 и все прочее включается, даже если по факту Mode указан какой-то другой. Ну, чтобы ради переключения между cnc-ddraw и обычным режимом не нужно было каждый раз целый ряд параметров в конфиге руками переключать туда-обратно. Короче, включение и выключение cnc-ddraw сводится к наличию чего-то в параметре CustomDllPath, либо пустоты в нем.

Помимо красивого масштабирующего шейдера, у cnc-ddraw основной профит -- это то, что один раз в настройках sfall указываешь 1280x720 (по дефолту именно эта цифра, кстати), и окно игры с соблюдением пропорций автоматически растягивается на любое разрешение монитора. С одним только голым sfall приходится вручную подбирать цифры, потом еще решать нужен ли SCALE_2X, нужно ли получившееся окно дорастягивать с помощью линейного фильтра, а если нужно -- то это нужно еще и Mode 4/5/6 включать, и т.д. и т.п.

Цитата

есть нюансы из-за которых от 5ки отказываются.

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

Я как играющий без стретч-фильтров с банальным SCALE_2X этим вопросом озаботился только потому, что последнее время кого ни познакомь с Fallout и его модами -- у них прямо шок и почти истерика от крупных квадратных несглаженных пикселей (на ЭЛТ мониторах они были точно такими же, просто сам монитор и разрешение были гораздо меньше).

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

/EDIT/ Во, совсем забыл! Чтобы курсор в игре двигался очень плавно, в wardd.ini выставляем такие значения:

fullscreen=true
windowed=true

border=false

Либо запускаем wardd.exe и выбираем режим borderless:

Работать будет лишь у 99% пользователей, в крайне редких случаях это почему-то приводит к проблемам.

У меня нормально работает, курсор в игре бегает как по маслу.

Ну и Alt-Tab в режиме Borderless мгновенный.

Изменено 9 февраля пользователем randomdude

randomdude · 11 февраля

Ну что, немного хороших новостей.

Автор cnc-ddraw подсказал, как можно уже сейчас задавать для конфига cnc-ddraw любое произвольное имя без всяких патчей.

Просто запускаем игру батником, предварительно задав environment variable с нужным именем конфигурации:

set CNC_DDRAW_CONFIG_FILE=.\cnc-ddraw.ini && fallout2.exe

Библиотека cnc-ddraw при этом может называться как угодно, главное чтобы sFall умел в нее перенаправлять вызовы (это уже вопрос к разработчикам sFall)

Вот только сделать установку этой переменной не через батник, а как часть функционала sFall, не получится: чтобы библиотека cnc-ddraw смогла прочесть свой конфиг, переменная окружения должна быть задана до того, как будет запущен основной процесс игры. А sFall по определению начинает работать после запуска игры.

Изменено 11 февраля пользователем randomdude

Pyran · 11 февраля

Если cnc пофигу на sfall, то можно ли запускать их параллельно? В каком-нибудь где sfall в режиме 0?

randomdude · 11 февраля

Я уже не знаю, как проще объяснить...

Когда запускается исполняемый файл игры (fallout2.exe или варианты этого имени в зависимости от мода), он по идее должен подгружать .\SysWOW64\ddraw.dll, эта библиотека отвечает исключительно за 2D-рисование на экране силами DirectX 7. У Windows есть такая особенность, что если в одной директории с исполняемым файлом лежит одноименная библиотека, то все вызовы от исполняемого файла автоматически перенаправляются в нее. Сделано специально, чтобы если той или иной программе нужна строго определенная версия библиотеки, отличная от имеющейся в системных файлах Windows, то можно просто подкинуть нужную версию в директорию с самой программой и наслаждаться.

Библиотека sfall специально названа ddraw.dll, чтобы fallout2.exe подгружал ее вместо оригинала. В этой библиотеке есть некоторый уникальный код, который вообще не имеет отношения к работе с графикой, а расширяет функционал движка. Все "рисовальные" вызовы тоже попадают в эту подставную библиотеку, и она попросту перенаправляет их в оригинал, хранящийся в .\SysWOW64\ddraw.dll, с учетом всех изменений, которые пользователь указал в ddraw.ini (например, произвольное разрешение окна игры, модификации интерфейса и т.д.) Если включены Mode от 4 до 6, то вызовы дополнительно преобразуются (функционал враппера) и перенаправляются вроде в d3d9.dll, которая уже по указке sFall обрабатывает картинку шейдерами .FX, растягивает линейным фильтром и т.д., то есть игра начинает работать через DX9 вместо DX7.

Если мы используем cnc-ddraw, который сам ждет на входе вызовы DX7, то Mode 4/5/6 в sFall нам уже не нужны, в нашем примере про них можно забыть. Поэтому в конфиге sFall выставляется Mode=1, то есть полноэкранный режим DX7 без манипуляций с API и параметрами окна. А вот дальше нам нужно как-то сделать так, чтобы вызовы от фейковой ddraw.dll из sFall попадали следующим шагом не в .\SysWOW64\ddraw.dll, а в библиотеку cnc-ddraw, которая уже все транслирует в нужный API и, в нашем конкретном случае с использованием шейдеров GLSL, перенаправит видоизмененные вызовы в .\SysWOW64\opengl32.dll, который и будет выполнять всю работу по рисованию на экране.

Пока что это можно сделать только одним способом: пропатчить ddraw.dll от sFall так, чтобы конечной целью перенаправления вызовов DX7 из него была не .\SysWOW64\ddraw.dll, а какая-нибудь .\SysWOW64\wardd.dll. Поскольку библиотеки с таким именем по такому пути в Windows сроду не было, то игра будет искать wardd.dll в той же директории, где находится исполняемый файл игры. Поэтому библиотека cnc-ddraw переименовывается в wardd.dll, кладется в одну директорию с fallout2.exe, а ddraw.dll от sFall банально редактируется в hex-редакторе таким образом:

1. Первое упоминание ddraw.dll не трогаем, т.к. имеет отношение к управлению вводом с мыши и чему-то еще, но не имеет к графике:

(если тронуть, игра сломается)

2. Упоминание в фразе "Cannot load the original ddraw.dll" -- просто текст сообщения об ошибке, ни на что не влияет, и редактировать его смысла тоже нет:

3. Еще три упоминания настоящей ddraw.dll -- это то, что нам нужно, меняем их на wardd.dll:

Все! Теперь подставная ddraw.dll от sFall, когда ей нужно обратиться к .\SysWOW64\ddraw.dll, вместо этого будет вызывать .\SysWOW64\wardd.dll, но поскольку по такому пути этого файла нет, wardd.dll будет браться из папки с fallout.exe... а под таким именем там лежит библиотека cnc-ddraw, которая дальше уже все сделает сама. Ну а чтобы sFall пытался обращаться к .\SysWOW64\wardd.dll, нам нужно выбрать Mode=1, и мы делаем именно так.

Чтобы не заниматься патчингом библиотеки sFall, необходимо, чтобы разработчики sFall приделали к ddraw.ini параметр, который в режимах, отличных от Mode 4/5/6, а лучше всего -- только в Mode 1, заставлял бы sFall все вызовы DX7 отправлять не .\SysWOW64\ddraw.dll, а в библиотеку с любым произвольным именем, например cnc-ddraw.dll. Поскольку в системных файлах Windows библиотеки с таким именем не бывает, игра ее будет подгружать из папки с fallout2.exe, как в примере выше.

Пока такого параметра в конфиге sFall нет, придется редактировать sFall'овский ddraw.dll, как показано выше. Иначе никак.

Следующий этап -- головняки с конфигурацией cnc-ddraw. Конфиг sFall называется ddraw.ini, и конфиг cnc-ddraw тоже называется ddraw.ini. В моем случае я отредактировал библиотеку cnc-ddraw (которую назвал wardd.dll, как показано выше), просто заменив оба упоминания ddraw.ini на wardd.ini:

Теперь можно переименовать конфиг cnc-ddraw в wardd.ini и класть в директорию игры рядом с ddraw.ini от sFall'a, и все худо-бедно будет работать.

Чтобы графическая утилита настройки cnc-ddraw (не особо нужная) тоже работала с новым именем wardd.ini, в ней тоже делаем две замены:

Дополнительно я переименовал утилиту конфигурации cnc-ddraw в wardd.exe, чтобы не забыть, что она пропатчена на работу с нестандартным именем конфигурации wardd.ini

После этого в Mode=1 вызовы DirectX7 начинают идти по цепочке:

.\Fallout2.exe ➤ .\ddraw.dll (sFall) ➤ .\wardd.dll (cnc-ddraw) ➤ .\SysWOW64\opengl32.dll

Cобственно opengl32.dll нам и рисует на экране, заодно масштабируя изображение с помощью шейдера JINC2, который дает хорошую картинку. При этом fallout2.exe продолжает думать, что он рисует на экране через .\SysWOW64\ddraw.dll, что нам и нужно.

Проблема такого решения в том, что нужно при каждом апдейте sFall или cnc-ddraw патчить их заново, но еще большая проблема в том, что какие-то ссылки на ddraw.dll могут храниться в .dll'ках не простым ASCII текстом, а в другой кодировке, которая в HEX-редакторе будет выглядеть тарабарщиной и которую потому невозможно будет найти. Приведенный мной выше метод редактирования абсолютно не гарантирует, что после таких правок игра будет работать, как от нее ожидается. У меня никаких проблем не было, вроде игра работает отлично, но кто ж его знает? И будет ли метод работать с будущими версиями sFall и cnc-ddraw?

По поводу имени конфига cnc-ddraw разработчик ответил, как я процитировал выше: при запуске fallout2.exe через батник, предварительно задающий определенную переменную окружения (например CNC_DDRAW_CONFIG_FILE=.\wardd.ini), библиотека cnc-ddraw будет искать свои настройки уже именно в этом файле. То есть внесения изменений в файлы cnc-ddraw можно избежать уже сейчас таким вот способом.

А вот перенаправление вызовов из sFall в cnc-ddraw пока что достижимо лишь редактированием библиотеки sFall. Нужно приделывать к sFall параметр, который позволит в режиме DX7 (Mode 1 как минимум) все вызовы направлять не в .\SysWOW64\ddraw.dll, а в библиотеку с именем по выбору пользователя. Ну типа:

CustomDllPath=.\wardd.dll

Изменено 11 февраля пользователем randomdude

randomdude · 11 февраля

Можно даже вместо CustomDLLPath сделать все совсем лениво и с защитой от дурака: если в папке с игрой лежит cnc-ddraw.dll (пусть это будет специальное фиксированное имя для этой библиотеки), то вызовы перенаправляются туда, если такого файла нет — в .\SysWOW64\ddraw.dll

Конфиг sFall фиксированно переименовываем в sfall.ini, чтобы не бодался с ddraw.ini от cnc-ddraw, и дальше просто учимся жить с тем, что имя одного файла изменилось, а под старым именем там теперь другой новый файл.

По итогу получается:

ddraw.dll — sFall

sfall.ini — конфиг sFall

cnc-ddraw.dll — cnc-ddraw

ddraw.ini — конфиг cnc-ddraw

И больше ничего не придётся патчить, и разработчику cnc-ddraw ничего не придётся менять!

В таком раскладе в Mode 1/2/3 мы будем получать все эффекты cnc-ddraw:

.\Fallout2.exe ➤ .\ddraw.dll  ➤ .\cnc-ddraw.dll ➤ .\SysWOW64\opengl32.dll

А в Mode 4/5/6 — привычную работу sfall в режиме враппера DX9, в то время как cnc-ddraw даже не будет запускаться:

.\Fallout2.exe ➤ .\ddraw.dll ➤ .\SysWOW64\d3d9.dll

Для получения обычных Mode 1/2/3 достаточно будет временно переименовать cnc-ddraw.dll во что-то ещё, например _cnc-ddraw.dll, и в конфиге выбрать Mode 1/2/3:

.\Fallout2.exe ➤ .\ddraw.dll ➤ .\SysWOW64\ddraw.dll

Но обычные Mode 1/2/3 в наши дни нужны лишь в каких-то экзотических случаях... Кому такое нужно, наверняка осилит переименование одного файла папке с игрой. Остальные в Mode 1/2/3 по умолчанию будут получать cnc-ddraw, а в Mode 4/5/6 — просто sFall в режиме DX9.

Это самое простое и сердитое решение как для разработчика sFall, так и для пользователей.

Изменено 11 февраля пользователем randomdude

Pyran · 11 февраля

2 часа назад, randomdude сказал:

Я уже не знаю, как проще объяснить...

За развернутый и доходчивый ответ - спасибо.

Немного попозже, сделаю краткую инструкцию, по манипуляциям и файлы с текущими версиями.

2 часа назад, randomdude сказал:

Mode=1

...если верить логу sfall, то этот режим не используется, т.е. у нас есть 0, 4, 5, 6.

2 часа назад, randomdude сказал:

просто заменив оба упоминания ddraw.ini на wardd.ini

И все ниже сказанное... Раз отредактировано, то не такая уж и проблема (только, если обновлять, и то и другое).

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

Одного искать на NMA, другого не GitFlic

Чтобы менять ddraw.ini на sfall.ini и саму библиотеку, то в прошлых версиях редактировался сам ехе игры...

Временное переименование cnc-ddraw, перед запуском, тоже считаю не самым приемлимым.

randomdude · 11 февраля

1 час назад, Pyran сказал:

...если верить логу sfall, то этот режим не используется, т.е. у нас есть 0, 4, 5, 6.

Когда я ставлю Mode=1, какой режим используется? Однозначно не 4/5/6, потому что cnc-ddraw работает с вызовами DX7 на входе, а 4/5/6 это враппер DX9, который дальше по цепочке звонит вообще в d3d9.dll, а не в ddraw.dll или wardd.dll.

1 час назад, Pyran сказал:

И все ниже сказанное... Раз отредактировано, то не такая уж и проблема (только, если обновлять, и то и другое).

Если регулярное штопание обновившихся .dll-ок в блокноте не приводит к проблемам с игрой (предстоит выяснить), и авторы модов и сборок на это согласны, то проблема отпадает. Что в каком файле менять, я выше объяснил.

1 час назад, Pyran сказал:

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

Одного искать на NMA, другого не GitFlic

Я кое-что попросил у создателя cnc (чтобы библиотека искала конфиг под таким именем, как названа сама, т.е. abcdef.dll будет искать настройки в abcdef.ini), а вот с разработчиками sfall пусть пообщается кто-то другой. Моё предложение они сами могут заметить в этом топике, осмыслить и отреагировать. Либо другие люди опробуют новый шейдер, оценят и донесут до разработчиков.

1 час назад, Pyran сказал:

Чтобы менять ddraw.ini на sfall.ini и саму библиотеку, то в прошлых версиях редактировался сам ехе игры...

Вот это вообще не понял. Имя конфига sfall хранится в ddraw.dll от sfall, fallout2.exe про существование ddraw.ini ничего не знает.

1 час назад, Pyran сказал:

Временное переименование cnc-ddraw, перед запуском, тоже считаю не самым приемлимым.

Переименование нужно в этом сценарии только для возврата к обычным Mode 1/2/3, а 4/5/6 работают как обычно что с cnc, что без него: ни в одном из этих режимов cnc не задействован и существование или отсутствие его файлов не учитывается. Четвёртый или пятый раз одно и то же разными словами объясняю...

В текущем варианте с пропатченными файлами удаление или переименование wardd.dll (который cnc-ddraw) приводит к тому, что в Mode 1/2/3 игра просто перестаёт запускаться, пока не откачены все правки в ddraw.dll (sfall).

После патчинга остаётся выбор либо cnc в Mode 1/2/3, либо sfall в режиме DX9 в 4/5/6. Обычный режим DX7 ломается.

Возврат от cnc к обычному DX7 временным переименованием файла — легче, чем временная замена ddraw.dll на непатченную.

Но обычный DX7 нафиг никому не нужен — на Windows 10 и 11 он либо работает плохо, либо вообще не работает; а DX9 в Mode 4/5/6 либо OpenGL через cnc-ddraw работают везде, включая Win XP SP3.

Изменено 11 февраля пользователем randomdude

randomdude · 11 февраля

Так, проверил в ProcessExplorer и увидел там примерно то, что ожидал (последняя сборка Sonora от Foxx на основе sFall 5)

С пропатченными файлами и cnc-ddraw в Mode 0/1/2/3 игра запускается в DX7, после чего вызовы DX7 перехватываются cnc-ddraw, оборачиваются в OpenGL и дальше все работает через OpenGL с шейдерами и прочим.

При этом в Mode 0 экран мигает и переключается в режим 8-битного цвета, плюс напрягает комментарий из ddraw.ini по поводу Mode 0: "if the high-resolution patch is disabled", то есть явно нам Mode 0 в данном случае не вполне подходит.

В Mode 1 все работает, как надо, потому что "for DX7 fullscreen mode", а дальше уже cnc-ddraw этот fullscreen на свое усмотрение превращает либо в окно, либо в полноэкранный режим, либо в полноэкранное окно без рамки, но fallout2.exe и sFall об этом ничего не знают и не должны. Это правильно.

Mode 2 & 3 появляется черное окно и все виснет, что тоже ожидаемо: это оконные режимы DX7, и управление окном средствами sFall конфликтует с управлением окном средствами cnc-ddraw. Однако библиотеки и в этом случае загружаются все те же самые.

Во всех случаях настоящий .\SysWOW64\ddraw.dll не загружается, как и следовало ожидать, ведь перехватывающий вызовы DX7 модуль cnc-ddraw транслирует их в вызовы OpenGL, которые дальше направляются в glu32.dll и opengl32.dll.

* * *

Теперь пробуем в Mode 4/5/6. Как ни странно, cnc-ddraw при этом тоже загружается:

Связано это, скорее всего, с тем, что sFall что-то химичит с вводом/выводом (мышка?) через библиотеки DirectInput, а для их загрузки требуется обращение к

.\SysWOW64\ddraw.dll, вместо которого загружается .\wardd.dll (cnc-ddraw). При этом cnc-ddraw транслирует вызовы DirectInput (это DX7) в вызовы DirectInput 8 (это DX8), видимо для большей совместимости с современными ОС или чего-то такого, благо фиксов input/output в cnc-ddraw хватает:

А вот рисованием на экране в Mode 4/5/6 занимается DirectX9, потому что sFall в этих режимах работает как враппер DX7 в DX9:

И никаких упоминаний OpenGL, потому что cnc-ddraw вообще в этих режимах не вмешивается в вывод изображения на экран.

Но по-хорошему, cnc-ddraw вообще не должен загружаться в Mode 4/5/6 ни в какой роли, а для этого, как я многократно повторял выше, нужно изменять поведение sFall: если в папке с игрой лежит cnc-ddraw.dll (или задана переменная CustomDLLPath), то все вызовы DirectX 7 направляются туда, в противном случае -- сразу в .\SysWOW64\ddraw.dll

Однако с патченными файлами этого не добиться, поэтому cnc-ddraw в Mode 4/5/6 загружается и транслирует DirectInput в DirectInput 8, хотя его никто об этом не просит, ведь в Mode 4/5/6 мы хотим видеть только чистый sFall.

* * *

Теперь попробуем Mode 0/1/2/3 в чистой сборке Sonora от Foxx без пропатченных мной файлов. Сразу видим запущенные Fallout2.exe и фейковый ddraw.dll, то есть sFall:

После чего все вызовы направляются в настоящий ddraw.dll от DirectX 7:

Тест проводился на Windows 7, а на Windows 10 или 11 меня бы ждали зависания и вылеты, потому что DX7 в них заменен на встроенный прямо в саму винду враппер от Microsoft, который работает настолько плохо, что из-за этого и пришлось изобретать все эти cnc-ddraw, dxwrapper, dgVoodoo и Mode 4/5/6 в sFall.

Также загружается простой ~~советский~~ dinput.dll от DX7 и никаких намеков на dinput8.dll, потому что cnc-ddraw у нас в цепочке отсутствует, а sFall ввод/вывод в режиме DX7 предсказуемо ни во что не преобразует, продолжая пользоваться библиотеками DX7.

* * *

Ну и наконец пробуем запустить игру в Mode 4/5/6 без cnc-ddraw. Снова в начале видим Fallout2.exe и sFall:

Но никакого .\SysWOW64\ddraw.dll нет и в помине, потому что sFall работает враппером и транслирует рисование в DirectX 9:

Ввод/вывод по-прежнему обслуживается через dinput.dll из набора библиотек DirectX 7:

Библиотека dinput8.dll предсказуемо отсутствует, потому что трансляцией из DirectInput в DirectInput 8 у нас занимается cnc-ddraw, а его в чистой установке сборки нет.

* * *

Что наблюдаем в итоге: все, как я говорил, с той лишь оговоркой, что при игре с пропатченными файлами даже в Mode 4/5/6 происходит трансляция DirectInput в DirectInput 8 силами cnc-ddraw, что абсолютно не мешает, но по-хорошему случаться не должно: по нашему замыслу для cnc-ddraw специально выделен Mode 1, а в Mode 4/5/6 мы предпочли бы видеть чистый sFall как на уровне рендеринга графики, так и на уровне работы со вводом/выводом.

Режимы 0, 1, 2, 3 отлично работают как минимум в sFall 5, причем именно таким образом, как сказано в комментариях к конфигу:

; 0 - for old 8 bit fullscreen (if the high-resolution patch is disabled)
; 1 - for DX7 fullscreen mode
; 2 - for DX7 windowed mode
; 3 - for DX7 fullscreen windowed mode

То есть по старинке через DirectX 7, который наглухо сломан в Windows 10 и 11, при этом будучи не особо нужным даже в Windows XP.

Почему я и предлагаю превратить режимы DirectX 7 (точнее режим Mode 1) в режим cnc-ddraw, из-за полной бесполезности DirectX 7 в 2024 году.

А кому он будет нужен, тот может просто удалить или переименовать cnc-ddraw.dll, или какое там за ней выделенное имя закрепят разработчики sFall.

Для игры же в обычном sFall без cnc-ddraw остаются режимы 4/5/6, осталось только отучить cnc-ddraw цепляться к вводу/выводу в этих режимах.

P.S. Описание библиотеки sFall стоило бы изменить с полной белиберды

Reimplementation of game engine Fallout 2 v1.02 US

на простую английскую фразу:

Fallout 2 v1.02 US game engine reimplementation

чтоб если кто увидит, не подумал, что это писал индус.

Изменено 11 февраля пользователем randomdude

randomdude · 11 февраля

В режимах Mode 0/1/2/3 при добавлении в наш конвеер cnc-ddraw, похоже, вообще перестают работать следующие параметры в f2_res.ini

GRAPHICS_MODE=
SCALE_2X=
SCR_WIDTH=
SCR_HEIGHT=

Допустим, я наигрался с шейдерами, хочу поиграть с крупными пикселями. Включаю один из режимов DX9 в ddraw.ini и обязательно меняю размер viewport'a на текущее экранное разрешение 1920x1080 (если просто поставить 0x0, то при включении SCALE_2X в f2_res.ini у меня игра вылетает с ошибкой).

Mode=4
GraphicsWidth=1920
GraphicsHeight=1080

Теперь будут учитываться упомянутые выше настройки в f2_res.ini, поэтому дублирую там свое настоящее экранное разрешение, включаю SCALE_2X, а режим графики ставлю на 0 (управление режимами через sFall):

GRAPHICS_MODE=0
SCALE_2X=1
SCR_WIDTH=1920
SCR_HEIGHT=1080

С учетом SCALE_2X=1, 1920x1080 по факту превращается в 960x540 из квадратиков размером 2x2 экранных пикселя каждый; поэтому сравним полученное изображение с тем, которое выдает cnc-ddraw в разрешении 960x540 с фильтрацией шейдером jinc2-fallout.glsl:

https://i.postimg.cc/dFpmf36G/comparison.png

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

Но в этом случае я ограничен фактическим разрешением 960x540 (то есть 1920/2x1080/2)

А если я хочу масштаб помельче? Тут, увы, для меня единственным вариантом остается снова включить cnc-ddraw (Mode 1) и задать размер viewport'a 1280x720, после чего картинка будет растянута до 1920x1080 далеко не целочисленным фактором (integer scaling), поэтому масштабирование с помощью шейдера необходимо:

https://i.postimg.cc/Y7Rj4sG0/cnc-ddraw.png

Удивительно, но растяжение 1280x720 до 1920x1080 предложенным мной шейдером выглядит гораздо лучше, чем растяжение 960x540 до 1920x1080.

Если масштаб в режиме SCALE_2X не устраивает, остается играть только так.

Изменено 11 февраля пользователем randomdude

randomdude · 12 февраля

Сравнение cnc-ddraw OpenGL JINC2 shader и sfall DirectX9 SCALE_X2 в 960x540 отмасштабировано до 1920x1080: https://i.postimg.cc/ys9YX1Y1/screen00001.png

Cnc-ddraw OpenGL JINC2 shader в 1280x720 отмасштабировано до 1920x1080: https://i.postimg.cc/mRsd2Vzm/attal.jpg

Cnc-ddraw OpenGL JINC2 shader в 1366x768 отмасштабировано до 1920x1080: https://i.postimg.cc/xY6KDPKJ/screen00002.png

randomdude · 12 февраля

Тест режима SCALE_2X силами cnc-ddraw.

Полностью отключаем в f2_res.ini вмешательство в графику:

GRAPHICS_MODE=0
SCALE_2X=0
SCR_WIDTH=0
SCR_HEIGHT=0
COLOUR_BITS=8
REFRESH_RATE=0
WINDOWED=0
WIN_DATA=0

В ddraw.ini включаем Mode 1 и выставляем разрешение, равное строго половине разрешения монитора:

HiResMode=1
Mode=1
GraphicsWidth=960	; 1920/2
GraphicsHeight=540	; 1080/2
TextureFilter=0

Кладем фильтр nearest-neighbor в .\Shaders\nearest-neighbor\nearest-neighbor.glsl

Прописываем его в wardd.ini:

shader=Shaders\nearest-neighbor\nearest-neighbor.glsl

(либо выбираем в списке через графическую утилиту настройки cnc-ddraw)

Запускаем игру и видим то же самое, что и при SCALE_2X=1, только не нужно включать Mode 4/5/6 и дополнительные функции f2_res.ini

https://i.postimg.cc/YkCzR0WN/png.png

Помимо OpenGL в cnc-ddraw есть еще ряд режимов трансляции/враппинга.

Например, режим DirectX 9 аналогичен Mode 4/5/6, но в нем доступны лишь 4 фиксированных шейдера:

Собственные шейдеры в режиме DirectX 9 cnc-ddraw загружать не позволяет. Все четыре доступных в этом режиме шейдера легко получить и в OpenGL, скинув нужный .glsl файл в .\Shaders\имя-шейдера\имя-шейдера.glsl

Выбираем Nearest Neighbor, запускаем игру, получаем DirectX 9 (аналог Mode 4) в режиме SCALE_2X, как на скриншоте выше. Переключение между режимами в cnc-ddraw проще и удобнее, чем манипуляции с ddraw.ini и f2_res.ini.

На компьютерах с Windows 10 или 11 также будет доступен режим DirectX 12, его преимущества или недостатки перед DirectX 9 мне неизвестны.

Ладно, допустим на нашем компьютере видеокарта вообще не обеспечивает аппаратного ускорения. Ну, например, мы играем в виртуальной машине или собрали какой-то нереально древний винтажный компьютер. В cnc-ddraw есть еще режим рисования без аппаратного ускорения через библиотеку gdi32.dll

Эта штука использует исключительно процессор, отличается большей, нежели ddraw, совместимостью с современными ОС, а в качестве алгоритма масштабирования тоже использует Nearest Neighbor. Постобработка в режиме GDI недоступна, чего и можно ожидать от чисто программного рендерера.

Запускаем игру и убеждаемся, что все выглядит так же, как и в OpenGL и DirectX 9.

К сожалению, если заданное в ddraw.ini разрешение не является ровно половиной от разрешения монитора, то фильтр Nearest Neighbor начинает выглядеть безобразно:

https://i.postimg.cc/Dv5CWSYC/ne-ne.png

Поэтому в режиме софтварного рендеринга GDI нормально поиграть получится только в стиле SCALE_2X строго на половинке от разрешения монитора. Впрочем, это относится к фильтру Nearest Neighbor независимо от выбранной библиотеки рисования. Само собой, встроенный в sFall SCALE_2X ведет себя точно так же.

Вот так с помощью cnc-ddraw можно легко воссоздать любые режимы рендеринга, доступные в "голом" sFall, включая чисто софтварный. Но предпочтительнее OpenGL, ведь он позволяет загружать любой произвольный шейдер в виде .glsl-файла.

P.S. Трансляция DirectInput в DirectInput 8 в cnc-ddraw действительно для того, чтобы некоторые игры не ломались в Windows 10 и 11, потому что на dinput.dll там порой начинается адище, а dinput8.dll работает без проблем.

Изменено 12 февраля пользователем randomdude

Nobi · 12 февраля

В 09.02.2024 в 16:16, Pyran сказал:

А вот отключать sfall и передавать работу cnc, звучит, как: отключите двигатель самолета и передайте управление гребцам.

Такое вполне возможно даже реализовано в sfall, он как минимум умеет дочерним процессом запускать exe файлы, так что вполне может и другие dll подгружать если нету конфликта в виртуальной адресации процесса игры

В 09.02.2024 в 17:57, randomdude сказал:

Поэтому я просто подожду тут мнения разработчика,

А он тут забанен. Можете на инглише спросить у второго разраба на гитхабе https://github.com/sfall-team/sfall

Изменено 12 февраля пользователем Nobi

randomdude · 12 февраля

Цитата

Такое вполне возможно даже реализовано в sfall, он как минимум умеет дочерним процессом запускать exe файлы, так что вполне может и другие dll подгружать если нету конфликта в виртуальной адресации процесса игры

Нужно, чтобы все вызовы из библиотеки sfall перенаправлялись в библиотеку cnc-ddraw строго в таком порядке, параллельная подгрузка ничего не даст (в этом посте все разжевано)

Цитата

А он тут забанен.

Ну форум-то он читать может? Самостоятельно повторить шаги и оценить профит в состоянии?

Цитата

Можете на инглише спросить у второго разраба на гитхабе https://github.com/sfall-team/sfall

Уже спросил. Более того, там кто-то 4 года назад сетовал, что sFall'овский враппер DirectX 9 вызывает перегрев GPU и загоняет FPS в порядки сотен и тысяч, а ограничение FPS средствами sFall вызывает тормоза. В качестве решения этот кто-то предлагал импортировать функционал cnc-ddraw либо dgVodoo прямо в sFall, на что был получен ответ: ищите того, кто займется адаптацией кода.

Мое решение: не скрещивать ужа с ежом, а просто грузить cnc-ddraw прицепом после sFall, предварительно залочив sFall в Mode 1 и отключив все функции sFall, затрагивающие рендеринг и постобработку. Это решение работает, как я продемонстрировал выше. Но приходится грубо редактировать обе библиотеки, sFall и cnc-ddraw, в HEX-редакторе. Просьба внести некоторые правки в cnc-ddraw разработчику отправлена, он подумает (также он подсказал готовое решение запуском игры через батник, да и вручную по моему примеру патчить никто не запрещает). Посмотрим, что ответит NovaRain. Если придется ему еще раз пересказывать весь этот тред на английском, будет весело.

Изменено 12 февраля пользователем randomdude

Nobi · 12 февраля

@randomdude умеет ваш cnc-ddraw в FSR 1.x ? Я кстате слышал что на ретроарч его реализовали в виде шейдера(хотя разрабы амуде утверждали что это невозможно сделать)

Кстати, а как OBS Studio в такой связке chainload себя будет вести? Он ведь тоже там свою dll инжектит :scratch_one-s_head: С оконным вариантом там все понятно, а вот на фуллскрине...

(инжектор там вроде отдельным exe идет, можете попробовать им cnc-ddraw инжектить, но это как я понял не самый хороший вариант)

Изменено 12 февраля пользователем Nobi

randomdude · 12 февраля

Понятия не имею. Он точно умеет в любые single-pass шейдеры формата GLSL в API OpenGL. Какая там версия OpenGL, тоже не разбирался (как минимум 3.3)

Вот тот самый порт FSR2 на OpenGL: https://github.com/JuanDiegoMontoya/FidelityFX-FSR2-OpenGL

По ссылке меня встречает огромная простыня про сборку библиотеки. Это намекает о том, что сама технология как-то завязана на железо AMD, то есть библиотека говорит с драйвером видеокарты от AMD, передает ему данные, GPU их жует, возвращает драйверу, драйвер -- библиотеке, библиотека -- glsl коду.

cnc-ddraw реализует GLSL-шейдеры общего назначения, которые будут работать на любом GPU с поддержкой OpenGL определенной версии.

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

Видеокартой AMD, тем более с поддержкой FSR, не располагаю.

На YouTube находится видео, где продемонстрирована работа FSR в RetroArch как раз с рисованной 2D-графикой, а точнее пиксель-артом. Выглядит немногим лучше xBRZ, то есть отвратительно. Учитывая, что графика Fallout сочетает элементы фотореализма с поджаренной до хрустящей корочки олдовой 8-битной палитрой, жестким дизерингом, зернистой картинкой и ручной доработкой многих спрайтов на манер пиксель-арта (привет кактусам и деревьям), и все это в 480p, то при прогонке через FSR, скорее всего, игра будет выглядеть как-то так

Я бегло почитал описание технологии FSR и, пусть может и ошибаюсь, делаю вывод, что изначально на входе у этой штуки должно быть что-то в достаточно высоком разрешении (допустим 1080p, с целью дальнейшего масштабирования до 4К) и в 32-битном цвете, т.к. любые артифакты сжатия палитры (то самое зерно) и сопутствующие им художественные решения (дизеринг рассыпной, как на многих объектах в Fallout, и шахматный, как движок Fallout изображает тени) будут истолкованы FSR так, что на результат апскейла будет больно смотреть.

Но это только мои догадки. Вот тут показывают работу технологии на стареньком GeForce 1000 серии, а по ссылке из комментариев говорится, что в первую очередь FSR должен поддерживать сам движок игры.

В плане 2D-игр, скорее всего, интереснее будет посмотреть на работу этого шейдера, но когда мы находим его в репозитории RetroArch, то сразу же видим формат GLSLP, то есть это многопроходный шейдер, состоящий из нескольких, и cnc-ddraw это пока не поддерживает (сам разработчик на гитхабе еще в 2018 открыл самому себе тикет "добавить поддержку многопроходных шейдеров", и с тех пор этот воз и ныне там).

Забегая вперед, скажу, что готов поставить свои деньги на то, что и этот шейдер будет давать ужасные результаты, если через него прогонять картинку Fallout, которая сочетает множество условностей 2D-арта (жареная скудная палитра, дизеринг, элементы ручной обрисовки) с изометрией и спрайтами, отлитыми с 3D-моделек. Его предназначение -- контрастная 2D картинка в стиле пиксель-арт, то есть всякие платформеры эпохи SNES и более ранних приставок. Но даже сегодня в 2D по сравнению с оригинальными квадратиками, IMHO, картинка через этот ScaleFX получается отвратительная. Пиксели просто оплавились и оплыли, как свеча, а где там улучшение?

Вообще, когда речь заходит о крайне сложной 2D-графике эпохи 1995-2000, где все отрисовано с 3D, переведено в 2D, как правило в изометрии, и все это еще в ограниченной палитре -- самое лучшее, на что можно рассчитывать, это... пролистайте тему наверх, где я выкладывал скриншоты работы шейдера jinc2-fallout, который я тоже в этом треде выкладывал. Результаты не фантастические, но в отличие от всех этих xBRZ и ScaleFX, картинка хотя бы не выглядит, как будто ее трясущейся рукой алкаш 1000 раз обвел с помощью маркера.

Изменено 12 февраля пользователем randomdude

Войти

Fo2: Как подружить CnC ddraw и sfall (враппер и шейдеры)

Рекомендуемые сообщения

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Ссылка на комментарий

Для публикации сообщений создайте учётную запись или авторизуйтесь

Создать аккаунт

Войти

Последние посетители 0 пользователей онлайн