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

[Nobi]

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

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

Ну допустим. А если мы поместим его ddraw.dll & ddraw.ini в отдельный каталог и будем без переименований загружать ddraw.dll от туда, кофиг тоже подгрузится? (пока не рассматриваем возможный конфликт имен dll у процесса игры)

[randomdude]

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

 

Если бы NovaRain попросил, объяснив, для чего это, думаю, чел из cnc пошел бы навстречу.

[Nobi]

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

чел из cnc пошел бы навстречу.

Он не хочет этим заниматься, потомучто там насрано хардкодом по куче файлов проекта. Если чё я займусь этим не спеша, но у меня это займет очень много времени, потомучто я на c++ почти не писал код

[randomdude]

Имя конфига читается из переменной и может меняться. Один раз запостил ссылку, запощу и второй: https://github.com/FunkyFr3sh/cnc-ddraw/files/14229860/run.game.zip

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

[Nobi]

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

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

Видел уже. Это бессмысленная сущность которая плодит говнокод. По сути создается переменная которая будет считана ровно один раз одной захардкоженой dll. Завтра мы выкинем cnc и заменим например на enb, а этот говнокод останется в sfall, делать запуск через батник ну такое себе дело.

[randomdude]

Так можно в cnc-ddraw.dll добавить немножко кода, который читает имя файла на диске и его же заносит в саму переменную? И все это происходит до первого обращения к конфигу? Если в исходниках такое количество обращений к ddraw.ini по имени, то почему в HEX-редакторе буквально два упоминания ddraw.ini поменял, и вот уже все читается из wardd.ini?

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

[Nobi]

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

и, то почему в HEX-редакторе буквально два упоминания ddraw.ini поменял, и вот уже все читается из wardd.ini?

Компиляторы могут всё это оптимизировать(увидели что строка ddraw.ini повторяется неско раз, записали ее в бинарник 1 раз, а в остальные места воткнули указатели на эту строку). Например они умеют определять что инкремент i++ нахер ненужен в твоём коде и заменяют его на более быстрый вариант ++i и это совершенно разные инкременты. С sfall куда более странная ситуация, у тебя на скрине 5 хардкодов, а в коде их 2-3

---

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

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

[randomdude]

4 часа назад, Nobi сказал:

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

Кроме cnc-ddraw ни один другой враппер ни по здравому смыслу, ни по функционалу для 2D-игр не подходит. На количество файлов в корне игры пофиг, это ни на что не влияет.

 

Я бы сделал ровно одно фиксированное имя с высоким приоритетом — wardd.dll, и все. Если человек кладёт в корень файл с таким именем, то он твердо знает, что делает.

 

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

 

Либо дополнительно приделывать к этому указателю проверки, что он хотя бы на реально существующий и являющийся библиотекой файл указывает. Если нет — опция игнорируется, в лог заносится запись об этом (или вместо окна с игрой вылезает табличка "сторонняя библиотека по пути X не найдена или файл не является библиотекой")

 

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

 

[Nobi]

@randomdude Кстати, по поводу базового разрешения игры. Чистый Fallout заточен на разрешение 640ч480 если выставить больше, то будут видны границы карт и вообще не рекомендуется его менять. Моды UPU/RPU, Nevada, Sonora адаптированы под разрешение 1280x720(1280x960), можно выставить 1920x1080 но уже както мелковато все будет казаться. Плэтому разрешение надо выставлять гдето в этих границах. Как по мне лучше выставить 1280x720 и скалировать его до разрешения экрана.

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

[randomdude]

Цитата

Чистый Fallout заточен на разрешение 640ч480 если выставить больше, то будут видны границы карт и вообще не рекомендуется его менять.

 

Лично мне границы карт никак не мешают, ради частичной косметической маскировки можно включить EDGE_CLIPPING_ON=0

 

Я предпочитаю играть на половине экранного разрешения (или четверти для 4K-мониторов), чтобы можно было получать четкую пиксельную картинку из блоков 2x2 или 4x4 точки монитора на каждую точку игры. То есть на 1080p мониторе у меня 960x540, для 4096x2160 будет соответственно 1024x540, а для 2560x1440 -- 1280x720.

 

Цитата

Моды UPU/RPU, Nevada, Sonora адаптированы под разрешение 1280x720(1280x960)

 

Как именно адаптированы? Понемногу играю в Sonora в 960x540, никаких проблем не встретил. RPU когда-то опять же в 960x540 проходил. Все было отлично.

 

Цитата

Как по мне лучше выставить 1280x720 и скалировать его до разрешения экрана.

 

Да, 1280x720 для нецелочисленного масштабирования предпочтительно по паре простых причин:

 

1. Это самое большое разрешение, в котором еще можно комфортно разглядывать UI и мир игры на мониторах с диагональю 24-28 дюймов. Для чего-то большего уже понадобится телевизор / очень крупный монитор, тогда например и 1366x768 хорошо смотрится.

 

2. Оно без остатка делится на 4, как и большинство нативных разрешений у современных мониторов. Когда source resolution и target resolution делятся на 4, даже если они при этом друг другу целочисленно не кратны, то все равно пусть и немного, но все же улучшается качество масштабирования картинки многими шейдерами. Для сохранения резкого, пиксельного изображения при нецелочисленном масштабировании (non-integer-scaling, когда 1 точка исходника не соответствует блоку 2x2 или 4x4 точек на мониторе) чаще используется шейдер catmull-rom, реже -- очень уж резкие lanczos, lanczos-sharper и т.д. Они как раз получают в 1280x720 некоторый профит (небольшой). Если пользоваться jinc2-modified, то разницы не будет, но jinc2-modified больше "перерисовывает" картинку, нежели пытается отмасштабировать, и у некоторых людей вызывает отторжение. Вообще, jinc2-modified лучше всего показывает себя, когда в исходной картинке достаточно много точек (1440x900 например), и масштабируем мы ее до большого-пребольшого количества точек (3820x2160 например). В более низких source и target resolutions можно уже бесконечно спорить, catmull-rom выбрать или jinc2-modified.

 

Чтобы это все наглядно прочувствовать, советую скачать https://github.com/RedChimera/IWD2EE (установщик базовой игры от GOG мгновенно находится в гугле) и поиграться с их лончером, который при каждом запуске игры показывает всю правду-матку про доступные разрешения встроенного HD-патча и то, насколько мелко и/или искаженно они будут выглядеть при масштабировании до текущего разрешения игры:

 

 

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

 

Если cnc-ddraw однажды будет интегрирован в sFall либо сборки на его основе, я бы изменил сам алгоритм выставления разрешения в sFall по умолчанию.

 

Пусть в ddraw.ini в настройках разрешения по умолчанию будет пустота. В этом случае вьюпорт будет масштабироваться не до экранного разрешения точка-в-точку, а до 1/2 на мониторах с вертикалью 1440p и ниже, и до 1/4 на мониторах выше 1440p (или как-то так).

 

В cnc-ddraw будет при этом стоять по умолчанию Nearest Neighbor, чтобы игрок получал при первом запуске крупную, пиксельную картинку, как будто он запустил игру на старом ЭЛТ-мониторе в 640x480.

 

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

 

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

 

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

 

Если вдруг он попробует переключиться обратно на Nearest Neighbor (и картинку вероятно перекосит, потому что на 1280x720 целочисленно делится лишь 2560x1440), то у него уже на этот момент будет понимание, что делать (вернуться к integer scaling + nearest neighbor либо играть с подходящим шейдером, который уже подобран).

 

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

 

 

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

[QweSteR]

Вы хоть скриншотами делитесь. Интересно же какие изменения в графике.

[randomdude]

Ну я кучу скринов выкладывал на протяжении всего топика. 

 

Основные изменения не в графике, а в удобстве использования и настройки. Тот же фикс CPU в sfall кривой, а в cnc-ddraw — нет. 

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

[randomdude]

Ровно половина от разрешения монитора (960x540 в моем случае), целочисленное растяжение на полный экран до 1920x1080, CATMULL-ROM vs NEAREST NEIGHBOR (то же, что SCALE_2X=1 в патче Мэша) vs JINC2-MODIFIED:

 

https://i.postimg.cc/NsZjdt5T/screenshot1.png

 

Я сам играю с Nearest Neighbor. CATMULL-ROM немного сглаживает картинку, но в целом сохраняет резкий пиксельный вид. JINC-2 довольно сильно перерисовывает. Какой из двух скейлеров дает лучший результат в низких разрешениях -- можно долго спорить.

 

Полное экранное разрешение (1920x1080), вывод изображения точка-в-точку, JINC2-MODIFIED vs. CATMULL-ROM:

 

https://i.postimg.cc/nZCGwGwG/screenshot2.png

 

Поскольку изображение выводится точка-в-точку, CATMULL-ROM предсказуемо никак не изменяет картинку, давая такой же результат, как и Nearest Neighbor. А вот JINC2-MODIFIED распознает шахматный дизеринг (и дизеринг в целом) и сглаживает их (зернистость превращается в мягкие градиенты, в остальном отличий от Nearest Neighbor тоже нет)

 

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

 

 

А теперь случай поинтереснее. Окно игры (viewport) выставляем 1366x768, то есть количество точек в картинке у нас сильно больше стандартного 640x480 и моего предпочтительного 960x540. И растягиваем эту довольно крупную картинку до 1920x1080 двумя фильтрами:

 

https://i.postimg.cc/8DXNTN4V/screenshot4.png

 

Вот тут, отчасти, можно поспорить, что при нецелочисленном увеличении достаточно большого (в точках) окна игры до достаточно большого экранного разрешения JINC2-MODIFIED показывает результат лучше, чем CATMULL-ROM, о чем я писал выше:

 

Цитата

Вообще, jinc2-modified лучше всего показывает себя, когда в исходной картинке достаточно много точек (1440x900 например), и масштабируем мы ее до большого-пребольшого количества точек (3820x2160 например).

 

Фрагмент предыдущего скриншота. Шахматный дизеринг при нецелочисленном масштабировании шейдером CATMULL-ROM выглядит, прямо говоря, не очень; JINC2-MODIFIED превращает его в мягкую тень, что выглядит лучше. Но при этом JINC2-MODIFIED довольно сильно перерисовывает всю картинку, что может оттолкнуть некоторых игроков.

 

 

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

fullscreen=false
maintas=false
windowed=true
border=true
resizable=true
toggle_borderless=false

 

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

 

Mode=1
GraphicsWidth=960
GraphicsHeight=540

 

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

 

https://i.postimg.cc/T2JkYdMv/screenshot6.png

https://i.postimg.cc/8cZBdCNF/screenshot7.png

 

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

 

 

Только при этом еще размером с телевизор?

 

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

 

fullscreen=false
maintas=false
windowed=true
border=true
resizable=true
toggle_borderless=false

 

Пожалуйста, вот вам свободно растяжимое окно с игрой на рабочем столе, которое строго сохраняет пропорции разрешения, указанного в конфиге sFall:

 

https://i.postimg.cc/1sLHhVNV/Screenshot8.png

 

И при этом размер окна свободно меняется мышкой прямо в процессе игры, а изображение внутри окна масштабируется выбранным в cnc шейдером.

 

sFall тем временем продолжает думать, что выводит изображение в режиме DirectX 7 на полный экран. Никакие твики sFall для управления размером окна и режимами экрана больше не нужны, а стало быть, от них больше не будет проблем и побочек (если они у кого-то возникали). Достаточно поставить один раз Mode=1 и дальше конфигурировать cnc-ddraw, как захочешь.

 

Еще часто в адрес Fallout 2 / sFall в интернете попадаются жалобы, что игра перегружает видеокарту и/или процессор, все греется, FPS улетает куда-то в район тысяч, а встроенный фикс CPU в sFall либо работает как-то странно, либо FPS падает до порядка сотен (лол), но при этом картинка начинает дергаться (ага, в игре со стандартным FPS где-то в районе 30!). При этом у большинства людей фикс работает, ничего не перегревается. Phobos77 когда-то писал, что сам алгоритм фикса не вполне доведен до совершенства:

 

Цитата

Seems like the way main loop is implemented in DX9 mode is wrong and needs some fixes. Probably different CPU idle settings needs to go (they seem like ugly half-working hacks) in favor of a proper frame pacing solution.

 

Теперь любые фиксы CPU (привязка к одному ядру и CPU Idle) можно спокойно отключать в sFall, а в cnc-ddraw просто выставить:

 

maxfps=-1
maxgameticks=-2

 

В результате количество "тиков" движка игры и кадровая частота ограничиваются частотой развертки монитора. У меня это 144 Гц, CPU и GPU работают на минимуме.

 

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

 

144 / 4 = 36

 

maxfps=36
maxgameticks=36

 

CPU и GPU теперь вообще едва шевелятся, но предсказуемо курсор мышки в игре теперь двигается рывками (36 FPS, как-никак).

 

Однако подкручивая эти два параметра под конкретную игру или конфигурацию железа, можно дооптимизировать все до абсурда. Лично у меня и с привязкой параметров к частоте обновления экрана железо холодное: нагрузка на CPU с кучей бегающих кругом NPC держится в районе 2-3%, нагрузка на GPU в районе 1%. Если у кого-то на дефолтных значениях курсор мыши в игре двигается недостаточно плавно, то параметр maxgameticks можно сделать выше частоты развертки монитора, например 240 или 288, или еще каким-нибудь вообще не привязанным к частоте числом, которое подбирается экспериментально. Делать maxgameticks неограниченным не рекомендуется -- CPU может перегрузиться.

 

Работает cnc хоть на Windows 11, хоть на доисторической Windows 2000.

 

Внедрение cnc-ddraw также очень облегчит жизнь разработчикам sFall, т.к. не придется тратить силы на поддержку и улучшение фиксов, которые корректно работают лишь для 90% игроков, а у оставшихся 10% творится что-то непонятное. Те же самые фиксы через cnc-ddraw работают корректно для 99,9% людей.

 

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

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

[randomdude]

Просьба к кому-нибудь заинтересованному и неленивому проверить вот что: у меня параметр FOG_OF_WAR=1 в sFall 5 работает и в HiResMode, и с внешним мэшевским HRP, то есть пока в параметре 1, все NPC и враги вне поля зрения моего персонажа автоматически скрываются вообще в любом из этих режимов. При этом FOG_LIGHT_LEVEL=1, как и любые другие значения, не работают: никакого собственно тумана войны на экране не появляется ни в режиме от Mash, ни в HiResMode, как ни бейся.

 

Лыжи мои не едут или проблема все-таки в моих кривых руках?

 

Похоже, sFall 5 принудительно работает в HiResMode, просто туда были портированы частично функции HRP от Мэша (в т.ч. видимость NPC и врагов в зависимости от линии обзора героя), но вот допустим сам туман войны (черная завеса) портирован не был. При попытке пропатчить Сонору f2_res_patcher.exe она попросту ломается.

 

Интересный выбор в сборке от Foxx, получается на игру с внешним HRP она вообще не рассчитана, а довольствоваться нужно портированными из внешней HRP функциями. А я-то думал, что в sFall 5 параметр HiResMode=0 просто автоматически подгружает f2_res.dll независимо от того, пропатчен экзешник или нет.

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

[Nobi]

Блять, в движке или sfall интегрировано умное скалирование. ставишь Mode1 1280x960, а оно растягивается до разрешения монитора 1280x1024 ставишь Mode6 1280x720 и там вообще черти что, и ничего толком не поделать. NovaRain морозится и никак нехочет посодействовать. Пойду к Сталину спрашивать как вырубить скалирование это

[Nobi]

@randomdude Загляни на гитхаб, я сделал тестовый билд который перед запуском врапера выгружает d3dx9 если такой обнаружится у процесса игры

[Nobi]

Неофициальный билд sfall+cnc(sfall несколько отличается от версии NovaRain). Просто распакуйте в каталог с игрой и зайдите в каталог wrapper, там запустите и покрутите конфигуратор(некоторые настройки хранятся в соседнем ini и не отображаются в конфигураторе). Все это дело работает в DD7 Mode 0 или 1(предпочтительнее) при попытке поставить Mode 2/3/4/5/6 он будет автоматически выставлен в 1 при условии что существует путь \wrapper\ddraw.dll Если в каталоге с игрой будет f2_res.ini то настройки Mode и Resolution будут в приоритете считываться sfall от туда, а Resolution sfall будут както вспомогательно использоваться. Поэтому советую прописать 1280x720 в оба конфига

 

https://www.mediafire.com/file/gbq1j9kf4wmi21b/sfall-cnc.7z/file

 

Все отличия от версии NovaRain можете посмотреть здесь

https://github.com/egornovivan/sfall/commit/ed0d11da52bc772101da42891575461ea1785a35

их там немного и связаны с расчетом Mode

 

---

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

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

4:3
640x480
960x720
1280x960

16:9
960x540
1280x720

16:10(8:5)
960x600
1280x800

5:4
640x512
960x768
1280x1024

5:3
960x576
1280x768

3:2
960x640
1280x853

 

Изменено 24 февраля пользователем Nobi
Перезалил архив с полным паком libretro/glsl-shaders

[Nobi]

Перезалил архив с полным паком libretro/glsl-shaders, тестируйте, скриншотьте и делитесь результатами. Не все шейдеры могут работать, в CNC еще недоконца поддержку реализовали.

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

[randomdude]

Я немного приболел и отпал от дискуссии.

 

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

 

Цитата

Не все шейдеры могут работать

 

Многопроходные не будут работать, их можно узнать по разрешению .glslp в отличие от .glsl. Требующие версию OpenGL выше той, что в cnc-ddraw (она там 3.3 вроде, нет?), тоже не должны работать.

[Nobi]

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

разрешена только его загрузка из субдиректории под именем ddraw.dll

Только так. Там у него уже привязан какой-то функционал на переименование. Там услышал от него про COM объекты, а это муторная штука с самого ее появления.

[randomdude]

Да я читал тот коммент. Да, для некоторых старых Settlers нужно переименовывать в dinput.dll, но конфиг должен сохранять название ddraw.ini.

 

Но я так и не понял: а что мешает в случае переименования в dinput.dll задействовать именно по этому (я так понимаю особому) имени тот самый особый функционал, а по любому другому имени -- стандартный?

 

Как синхронизация имени ddraw.ini с input.dll, дающая в результате dinput.ini, может что-то сломать в COM-объектах? Это же просто имя конфига, а особый функционал привязан, я так понимаю, к имени библиотеки.

 

Задачу можно разбить на три разных правила:

 

1. Имя конфига всегда совпадает с именем библиотеки.

 

2. Если имя библиотеки из особого списка (dinput.dll, etc.), библиотека работает по-особому.

 

3. Во всех остальных случаях библиотека работает по-обычному.

 

2 и 3 друг друга дополняют, а 1 с ними вообще никак не пересекается.

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

[randomdude]

Возвращаясь к FSR. Есть один суперпопулярный мод для Diablo II (обычной, не римейка) по имени Project Diablo II (PD2), у них там встроен в игру специально для D2 созданный враппер с кучей продвинутых функций, включая  многопроходные шейдеры, и вот там FSR доступен. Ну вот можно на примере D2 посмотреть своими глазами, как эта штука апскейлит старое доброе 2D: 

 

 

 

 

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

[randomdude]

Поскольку Project Diablo II ориентирован на мультиплеер с разделением на сезоны, для одиночной игры я воспользовался одним из популярных субмодов для игры в одиночном режиме: https://github.com/Lukaszpg/PD2-Single-Player-Plus-mod

 

И вот он ваш FSR 1.X, просто двухпроходный шейдер общего назначения:

 

https://i.postimg.cc/BqNv9LJj/FSR.jpg

 

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

 

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

 

Старый добрый CATMULL-ROM придает игре вид, очень близкий к картинке на ЭЛТ-мониторе в нативном для игры разрешении:

 

https://i.postimg.cc/YtHgtFBR/CATMULL.jpg

 

Шейдеров в моде -- мама не горюй, правда все на языке SLANG:

 

https://i.postimg.cc/8PW0M6Zw/shaders.jpg

 

От любых продвинутых скейлеров движущиеся элементы картинки жестко штырит.

 

 

 

 

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

[Nobi]

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

жестко штырит.

Рекомендую попробовать VHS из libretro, вот там действительно штырит

[randomdude]

ASCII-фильтр еще радикальнее, он рисует на экране текстовыми символами.

 

Правда в Diablo II везде, кроме второго акта, так темно, что играть в этом фильтре физически невозможно. А искать glsl-вариант, чтобы попробовать в Fallout, мне лень.

 

FSR к старым 2D-играм не подходит вот почему: спрайты мелкие, а 8-битная палитра приводит к совершенно разному распределению зерна (хаотичный дизеринг) в соседних кадрах анимации. FSR поэтому перерисовывает каждый кадр немного по-разному, и кажется, что поверхность спрайта "кипит", как вода в чайнике. Поскольку статичные объекты по определению состоят из 1 кадра, с ними этот эффект не наблюдается. Как раз всю статику FSR апскейлит очень достойно.

 

https://i.postimg.cc/Y0SDXV5K/fsr-diablo.jpg

 

FSR мог бы давать хорошую картинку в играх с крупными спрайтами и палитрой минимум 16, а лучше 32 бита.

 

Навскидку могу вспомнить ZAX: The Alien Hunter; сделанную по заказу Interplay ролевую игру Lionheart (на системе S.P.E.C.I.A.L кстати); и, наконец, смешанную 2D/3D ролевку Temple of Elemental Evil. В последней от рождения ну очень мелкий масштаб, и играть точка-в-точку было некомфортно даже на старом мониторе 1280x1024. К сожалению, для нормальной игры в ToEE требуется фанатское расширение движка Temple+, которое помимо поддержки 16:9 само масштабирует картинку через голимый Bilinear. Сама игра на DX9, а Temple+ оборачивает её в DX11. Cnc-ddraw там в конвеер вклинивать некуда, а dxwrapper и dgVodoo умеют тоже только bilinear.

 

Было бы здорово предложить разработчику dxwrapper тоже приделать поддержку шейдеров (хотя бы Catmull-ROM) чисто ради масштабирования готового кадра в таких вот тайтлах, но нет моральных сил начинать уговоры и объяснять, почему он должен заморачиваться таким ради двух с половиной игр. Все-таки dxwrapper это в первую очередь про 3D-тайтлы, где обычно масштаб и зум камеры -- существующий функционал движка, а масштаб UI обычно лечится уже фанатскими HD-патчами.

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