Редактирование движка Опции

[Орион]

Интересует конкретные идеи/возможности, как декомпилить двиг игры и .dll библиотеки, с вшитыми .cpp файлами, через которые можно было бы восстановить множество отключённых фич. Например, открытие дверей в машине перед "усаживанием" за руль. Хекседикальные вьюверы - фигня. Кроме правки байтов и возможности зануливания от них проку мало, в отношении сталкера. Нашёл оч полезную утилиту и смог дизассемблить xrGame.dll нашёл в нём e"\stalker\patch_1_000*\xr_3da\xrgame\cardoors.cpp и все строки в библиотеке, но, увы, не смог сам файл вытащить из библиотеки. Полагаю, если научиться декомпилить и, собственно, компилить обратно .exe и .dll библиотеки ядра и двига игры - можно сделать прорыв в модостроении.. например вернув хотя бы возможность открывать двери/капоты/багажники в машинах И еще много чего, без необходимости издеваться в скриптах. Так же интересует - возможно ли сделать к сталкеру некий расширитель скриптового/с++ языка, как например к Обливиону OBSE?

p.s. если кого интересует утилита для декомпила - велкам в личку.

[Zagolski]

Как можно было додуматься переделать xray 1.6 на id tech?

Кстати, я давно задумывался, что мотивировало разрабов в id tech использовать forward render? Все поголовно почти на отложенных сидят, а эти отцы-основатели другой дорогой пошли. Или они самые хитро-умные?

Сообщение отредактировал Zagolski - 04.09.2019, 07:59

[iOrange]

Все поголовно почти на отложенных сидят

1 - не все и не поголовно
2 - про какую версию idTech речь? В idTech 6 у них F+, при чем очень грамотно сделанный. На старте так же была возможность переключиться на deferred, но там ФПС был ниже.

PS. Тот же новый Control тоже Hybrid Forward. Мало кто в наше время классический deferred юзает.

[Zagolski]

idTech 6, он родимый. Под Forward я имел в виду современный, т.е. F+, кластерный и т.д. Старый вариант в учет не беру. В любом случае на нем нужно z-prepass делать, а это 2x geometry pass. Ну да, сейчас в основном юзают Tiled Deferred: 1x geometry pass + tiled lighting. Я больше склоняюсь к тому, что на id tech в основном коридорные шутеры лепят, а там особо открытых детализированных пространств нет, возможно их Forward устраивает. Не знаю, все ж тяжко выходит два раза геометрию рисовать, когда ее много. А может Umbra хорошо помогает...

[iOrange]

на id tech в основном коридорные шутеры лепят, а там особо открытых детализированных пространств нет

Вроде F+ сначала на Just Cause обкатали, а там пространства приличные.

В любом случае на нем нужно z-prepass делать, а это 2x geometry pass

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

Чистые варианты в любом случае в проигрыше. Deferred - огромный удар по bandwidth, лимит на материалы (да, есть способы обходить) + прозрачку один хрен в форварде рисовать. А для этого надо держать еще раз шейдеры для форварда (со всем лайтингом и делами).

И тут начинаешь замечать как блистает F+ - вся необходимая инфа удобно в кластерах, минимум овердроу, единый рендер пайплайн для всего. В препасе есть все что нужно для MB и SSR, актуальный HiZ и прочие вкучняшки.
Кстати с F+ ты по максимуму развязан в плане контроля VGPR pressure и можешь резать на куски как хочешь. С дефередом ты зажат в этом плане и молишься на scheduler и тот факт что ты все равно texture bound.

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

Сообщение отредактировал iOrange - 04.09.2019, 21:16

[xrModder]

Я в отчаянии

Это старый луа, в нем нет поддержки х64. Надо его выкидывать и брать Luajit (2.x) http://luajit.org/download.html
Возьми luajit + luabind из ОГСР, других реальных вариантов нет.

можно не брать новый луажит, а добавить несколько custom_converter<__int64>(u32) (или как там он называется, не помню) в луа_бинд. основные проблемы с луа были именно при использовании незарегестрированных типов, __int64 один из них.

Как исправить код xrLua для компиляции под x64?

Лог компиляции xrLua

Предупреждение 1 warning C4244:
инициализация: преобразование "lua_Integer" в "int", возможна потеря данных
H:\Sources\xrLua\src\lbaselib.c 215 1 xrLua

Предупреждение 2 warning C4244:
инициализация: преобразование "lua_Integer" в "int", возможна потеря данных
H:\Sources\xrLua\src\lauxlib.c 268 1 xrLua

Предупреждение 3 warning C4267:
return: преобразование из "size_t" в "int"; возможна потеря данных
H:\Sources\xrLua\src\lauxlib.c 308 1 xrLua

Предупреждение 4 warning C4267:
=: преобразование из "size_t" в "int"; возможна потеря данных
H:\Sources\xrLua\src\lauxlib.c 473 1 xrLua

Предупреждение 5 warning C4244:
=: преобразование "lua_Integer" в "int", возможна потеря данных
H:\Sources\xrLua\src\ldblib.c 322 1 xrLua

Предупреждение 6 warning C4244:
функция: преобразование "__int64" в "int", возможна потеря данных
H:\Sources\xrLua\src\lcoco.c 279 1 xrLua

Предупреждение 7 warning C4334:
<<: результат 32-разрядного смещения неявно преобразуется в 64-разрядное значение (предполагалось 64-разрядное смещение?)
H:\Sources\xrLua\src\lgc.c 289 1 xrLua

Предупреждение 8 warning C4244:
функция: преобразование "lua_Integer" в "long", возможна потеря данных
H:\Sources\xrLua\src\liolib.c 428 1 xrLua

Ошибка 9 error C1189:
#error : "No support for this architecture (yet)"
H:\Sources\xrLua\src\ljit_backend.c 36 1 xrLua

Предупреждение 10 warning C4244:
функция: преобразование "__int64" в "int", возможна потеря данных
H:\Sources\xrLua\src\ljit_core.c 110 1 xrLua

Ошибка 11 error C1189:
#error : "No support for this architecture (yet)"
H:\Sources\xrLua\src\ljit_dasm.c 38 1 xrLua

Предупреждение 12 warning C4244:
функция: преобразование "lua_Integer" в "int", возможна потеря данных
H:\Sources\xrLua\src\ljitlib.c 119 1 xrLua

Предупреждение 13 warning C4267:
=: преобразование из "size_t" в "int"; возможна потеря данных
H:\Sources\xrLua\src\ljitlib.c 200 1 xrLua

Предупреждение 14 warning C4334:
<<: результат 32-разрядного смещения неявно преобразуется в 64-разрядное значение (предполагалось 64-разрядное смещение?)
H:\Sources\xrLua\src\ltable.c 320 1 xrLua

Предупреждение 15 warning C4334:
<<: результат 32-разрядного смещения неявно преобразуется в 64-разрядное значение (предполагалось 64-разрядное смещение?)
H:\Sources\xrLua\src\ltable.c 373 1 xrLua

Предупреждение 16 warning C4244:
=: преобразование "ptrdiff_t" в "int", возможна потеря данных
H:\Sources\xrLua\src\lstrlib.c 114 1 xrLua

[xrModder]

Убрал такой код из ljit_dasm.c и ljit_backend.c:

Код

#if defined(__i386) || defined(__i386__) || defined(_M_IX86)
---
#else
#error "No support for this architecture (yet)"
#endif

Теперь компилируется, но чувствую, что это не правильно. Я запутался

[atanda]

Плохая идея редачить external библиотеку.

[Tron]

Бладжад, если так все очень плохо, может стоит взять обычный lua, а не luajit?

Ну будут у тебя скрипты медленней выполняться, но можно замутить другие плюшки.. например объекты (один раз скомпилированный скрипт можно юзать несколько раз)

Я, честно, не понимаю смысла делать еще 1 форк.

И да, luajit x64 поддерживается, только в 2.05

[cjayho]

Я, честно, не понимаю смысла делать еще 1 форк.

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

Сообщение отредактировал cjayho - 05.09.2019, 09:33

[Zagolski]

И тут начинаешь замечать как блистает F+ - вся необходимая инфа удобно в кластерах, минимум овердроу, единый рендер пайплайн для всего. В препасе есть все что нужно для MB и SSR, актуальный HiZ и прочие вкучняшки.

Я и сам ярый сторонник форвард и всегда радел за него. У deferred костыль на костыле. Однако странно, что большинство ААА игр сидях на отложиках. idTech тем не менее выделяется, один из немногих. Хотя конечно это извечный спор - какой из них лучше. И все же, при наличии огромных открытых детализированных пространств в игре, да еще и тесселированных, стоит посматривать в сторону деферреда. А вообще стоит другим разрабам с idTech 6 пример брать, действительно грамотный двиг получился.

Сообщение отредактировал Zagolski - 05.09.2019, 16:08

[iOrange]

Однако странно, что большинство ААА игр сидях на отложиках

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

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

Ну опять же - Just Cause наглядно показал что не обязательно

А вообще стоит другим разрабам с idTech 6 пример брать, действительно грамотный двиг получился.

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

А большинство ААА студий пилит движок "на все случаи жизни", что и выливается в .... UE4

[XR_CPU_PIPE.DLL]

Короче вырезаем сей всратый luajit и luabind
или юзаем ключи -nojit и -keep_lua
И не трахаем себе мозг с этой фигнёй.

[ForserX]

XR_CPU_PIPE.DLL, оххх. Был у меня опыт запуска на этих ключах. Не посоветую остальным.

XR_CPU_PIPE.DLL, оххх. Был у меня опыт запуска на этих ключах. Не посоветую остальным.

[XR_CPU_PIPE.DLL]

оххх. Был у меня опыт запуска на этих ключах. Не посоветую остальным.

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

Сообщение отредактировал XR_CPU_PIPE.DLL - 06.09.2019, 16:35

[ForserX]

Но зачем крутить новый луа если старый справлялся

Сильно ошибаешься.

[XR_CPU_PIPE.DLL]

Да? И в чём же? Аж интересно стало.

[Zagolski]

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

[XR_CPU_PIPE.DLL]

Кто то поделитесь шейдерами dx 10 от сталкер чн 1.5.1.0

[Winsor]

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

какой именно? Конкретный пример? Кое что я переносил, но это в основном "утилитные" функции. Некоторые вещи специально в скрипты были вынесены для "гибкости".

[Zagolski]

К примеру амк-шный алайф, укрытия от аномалий, касательно ТЧ. Да вообще все, что тяжелое. Оставить в скриптах диалоги, да инфопоршни, что с квестовой частью связано. Хотя в оригинальных версиях в скриптах и так мало функционала, я больше про моды толкую.

Или вот простой пример, это встречается повсеместно:

Код

        local obj
        for i=1,65535 do
            obj = alife():object(i)
            ---
        end

Лучше один раз залезть в двиг, провести в нем нужные расчеты и вернуть результат, чем обращаться туда >65k раз. Тут же конкретный батлнек.

Сообщение отредактировал Zagolski - 09.09.2019, 13:35