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

[Орион]

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

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

[Diesel]

PS. Но это уже оффтоп. Извиняюсь.

Ну, да. BFG (модератора) не хватает.

А из CE3 можно в х-ray что нибудь украсть? Или там несовместимость 100%?

Охота воду такую же видеть в Сталкере, как в CE2-3
А физику можно хотя бы поменять?

Сообщение отредактировал Дизель - 14.05.2019, 23:10

[NanoBot-AMK]

Вопрос смены компилятора реально достаточно актуальный.
Вес установщика GCC 8.2.0 x86-32 = 86М
Вес установщика GCC 8.2.0 x86-32 = 106М
При этом x86-32 часто генерирует более оптимальный код. Интерес именно возможности оптимизации под конкретный процессор. Т.е. например у меня получается практически гениальный код - -march=athlon-xp
И ещё компиляторы типа gcc любят хороших программистов, а вот VS201* их просто ненавидят, т.е. M$ любят сранных говнокодеров которые очень хреново представляют работу современных процессоров.

Что такое плохой код, это код который потенциально выполняется медленно, медленней чем мог.
Например сортировка, раньше лидировала "Быстрая сортировка / Quicksort". А сейчас "Поразрядная сортировка / Radix sort".
Которая позволяет добиться очень высокой скорости на современных процессорах. Эээ порядка 100'000'000 двордов за 0.6 сек при 3 ГГц при хорошей оптимизацией на i7. При плохой, медленней в два три раза.

Что мне нужно во обще от XRay'я.
Онлайне до 500-1000 сложных объектов ака сталкеров при 50-60 FPS, в моделях 256 костей, в танках - гусеницы, это отдельные приатаченые объекты с полной физикой, можно из РПГ перебить гусеницу и она слетит с танка, если танк подчиняясь скрипты или командам ГГ продолжает движения, то реалистично начинает вращаться на месте. Сбитую гусеница можно захватить гравиприводом и она будет реалистично работать как артефакт "плёнка", да движок по дефолту многое поддерживает, ему надо помочь, чтобы он стал ещё быстрей и реалистичней.
Так, что ещё, что ещё? Ах да, реалистичная физика ударной волны, и сама физика детонации взрывных объектов. CExplosive. Вроде ерунда, но будучи правильно реализованной очень хорошо ложится на геймплей, в игре всегда есть что-то взорвать, разрушить для продолжения геймплея. Взрыв гранаты может вызвать детонацию взрывных объектов которые расположены в непосредственной близости, это вроде как уже реализовано, но работает довольно хреново.
Так, что ещё? Пока всё.

Сообщение отредактировал NanoBot-AMK - 15.05.2019, 02:28

[iOrange]

Один я ничего не понял?

[NanoBot-AMK]

Самое главное танки без проблем преодолевали ЖД пути. У тебя застревали танки на путях? У меня застревали.
Это просто быстрое описания модернизации XRay'я что тут может быть непонятно.
ЗЫ
Да, описывал под хмелем, ну и что?

Сообщение отредактировал NanoBot-AMK - 15.05.2019, 16:12

[Diesel]

Самое главное танки без проблем преодолевали ЖД пути. У тебя застревали танки на путях? У меня застревали.
Это просто быстрое описания модернизации XRay'я что тут может быть непонятно.
ЗЫ
Да, описывал под хмелем, ну и что?

Какие танки в x-ray? Ты там кого нагородил? В гробу я видел такие танки, без движущихся гусениц.

Бросай пить.

[Kontro-zzz]

В гробу я видел такие танки, без движущихся гусениц.

А ты на них не смотри, на гусеницы.

[iOrange]

сранных говнокодеров которые очень хреново представляют работу современных процессоров

А вы хорошо себе ее представляете? Очень сомневаюсь.
Современный процессор - это практически черный ящик, в котором ваши ассемблерные инструкции декодируются в наборы микроинструкций, которые выполняются в произволном порядке и результаты фиксятся по ходу дела.
Или до сих пор верите, что написанные вами ассемблерные инструкции выполняются в том порядке, в котором вы их записали?

[ForserX]

Товарищи танкисты, Дизель, NanoBot-AMK, вы надоели. Хотите 256 костей? Окей. Берите шейдер скина, там есть переменная с размером массива в 65*3. (Емнип) 65 костей. Умноженное на ротацию, размер и позицию. Дальше идут варианты скиннинга. Оттуда убирается 3 индекса, вроде бы под рут кость, емнип. По мимо этого, вам нужно увеличить в движке маску костей. Если же опять лень изучать, то возьмите vismask от KD87. Профит. Правленый SDK есть в ОГСР. Если же вас он не устраивает, я могу в MeshEditor окси вам заплатку сделать.

Идём дальше. GCC/Clang(aka llvm)/CMake и прочее. По тестам GCC по вероятным ошибкам проиграл остальным. На первом месте идёт кланг. НО! Не забывайте про Intel Compiler. Пока он превосходит в оптимизации остальные. К тому же, вам придется изрядно потратить нервы на шаблонах, ибо весь двиг точился под MSBuilder, плюс ещё потребуется портировать всё это дело под C++11/C++14. Если лень разбираться, то смотрим ветку Premissive в окси. Там я это почти закончил. Мб на днях добью

При этом x86-32 часто генерирует более оптимальный код. Интерес именно возможности оптимизации под конкретный процессор.

Это лично у меня вызывает флешбеки с временами, когда код писался на ассемблере под конкретные процы. Хорош, а? Пишите нормальный CPUID и работайте с Intel intrinsics. Будем вам и SSE, AVX, AES, FMA, 3DNow! и прочее.

Сорри, сгорело, если где-то неправ, то можете закидать меня.

[Diesel]

Товарищи танкисты, Дизель, NanoBot-AMK, вы надоели. Хотите 256 костей? Окей. Берите шейдер скина, там есть переменная с размером массива в 65*3. (Емнип) 65 костей. Умноженное на ротацию, размер и позицию. Дальше идут варианты скиннинга. Оттуда убирается 3 индекса, вроде бы под рут кость, емнип. По мимо этого, вам нужно увеличить в движке маску костей. Если же опять лень изучать, то возьмите vismask от KD87. Профит. Правленый SDK есть в ОГСР. Если же вас он не устраивает, я могу в MeshEditor окси вам заплатку сделать.

Идём дальше. GCC/Clang(aka llvm)/CMake и прочее. По тестам GCC по вероятным ошибкам проиграл остальным. На первом месте идёт кланг. НО! Не забывайте про Intel Compiler. Пока он превосходит в оптимизации остальные. К тому же, вам придется изрядно потратить нервы на шаблонах, ибо весь двиг точился под MSBuilder, плюс ещё потребуется портировать всё это дело под C++11/C++14. Если лень разбираться, то смотрим ветку Premissive в окси. Там я это почти закончил. Мб на днях добью

Сложно и нерентабельно.
Предлагаю порыться в шейдерах намокания поверхностей от дождя. Там есть движение развёртки. Вот эту самую фичу надо перенести на динамику и сделать движение развертки туды-сюды и привязать скорость движения развертки хотя бы к трансмиссии техники.

Сообщение отредактировал Дизель - 15.05.2019, 20:05

[ForserX]

Сложно и нерентабельно.
Предлагаю порыться в шейдерах намокания поверхностей от дождя. Там есть движение развёртки. Вот эту самую фичу надо перенести на динамику и сделать движение развертки туды-сюды и привязать скорость движения развертки хотя бы к трансмиссии техники.

Займись! Костыльно, но может помочь.

[macron]

Какие танки в x-ray? Ты там кого нагородил? В гробу я видел такие танки, без движущихся гусениц.

Я seq-текстуркой делал движущиеся (без остановки) гусеницы. Если в движок добавить фишку/колбек мгновенной смены текстуры, то вообще по желанию будет стоять или двигаться вперед/назад.

Сообщение отредактировал macron - 15.05.2019, 21:22

[Xottab_DUTY]

Идём дальше. GCC/Clang(aka llvm)/CMake и прочее. По тестам GCC по вероятным ошибкам проиграл остальным. На первом месте идёт кланг. НО! Не забывайте про Intel Compiler. Пока он превосходит в оптимизации остальные. К тому же, вам придется изрядно потратить нервы на шаблонах, ибо весь двиг точился под MSBuilder, плюс ещё потребуется портировать всё это дело под C++11/C++14. Если лень разбираться, то смотрим ветку Premissive в окси.

Или основную ветку OpenXRay, где всё уже работает под GCC и CMake.

[NanoBot-AMK]

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

[Молния в вакууме]

Или основную ветку OpenXRay, где всё уже работает под GCC и CMake.

Братан, а есть где-нибудь инструкция как заменить обычный луабинд на тот что используется в OpenXray? Я пару раз пробовал, но всё что-то не идёт. То functor не мог найти, потом нашел что-то и что-то там ещё вылезло.
Просто я тоже собираю GCC(MinGW), и обычный луабинд им собирается из рук вон плохо, больше 10 тысяч предупреждений.

PS Заглянул недавно в дискорд а там твои сообщения за сентябрь с вопросом как работает фс в Xray2. D= Это ещё актуально?

[NanoBot-AMK]

Ладно.
То есть GCC компилятор не является лучшим? Но он генерируется хороший код, Я ЖЕ ПРОВЕРЯЛ идаПРО, Я БЫ НЕ СМОГ ТАКОЙ БЫСТРЫЙ КОД СОЗДАТЬ. Чёто с капслоком намудрил ладно. Я имею ввиду что нужен максимально быстрый код, быстрей просто не бывает, что тут не понятно.

[Молния в вакууме]

NanoBot-AMK, GCC хороший компилятор.
По моему опыту чуть генерит код чуть медленее чем майкрософтовский. LE вместе с xrCDB собранным студией у меня генерировал аи-сетку быстрее чем с xrCDB собранным GCC, но там незначительно.
С другой стороны GCC не выкидывает фокусы в виде програм работающих не так как написано в исходниках при включении оптимизации, в отличии от.
Так что в целом GCC точно не хуже MSVC.

А самое главное он легально бесплатный, интеловский придётся пиратить.

[RayTwitty]

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

Ты конечно же мерил ФПС? Насколько быстрее с быстрым кодом?

[iOrange]

Но он генерируется хороший код, Я ЖЕ ПРОВЕРЯЛ идаПРО, Я БЫ НЕ СМОГ ТАКОЙ БЫСТРЫЙ КОД СОЗДАТЬ

Дабы успокоить мое любопытство - не покажете ли сравнение? 2 небольших кусочка - один от MSVC, второй от GCC.
Буду очень благодарен.

[Xottab_DUTY]

Братан, а есть где-нибудь инструкция как заменить обычный луабинд на тот что используется в OpenXray?

Только коммиты nitrocaster'а, к сожалению.

PS Заглянул недавно в дискорд а там твои сообщения за сентябрь с вопросом как работает фс в Xray2. D= Это ещё актуально?

Я уже перестал её изучать, но, в целом, до сих пор актуально. Ибо там довольно интересная фс, может пригодится)

[xrModder]

Ладно.
То есть GCC компилятор не является лучшим? Но он генерируется хороший код, Я ЖЕ ПРОВЕРЯЛ идаПРО, Я БЫ НЕ СМОГ ТАКОЙ БЫСТРЫЙ КОД СОЗДАТЬ. Чёто с капслоком намудрил ладно. Я имею ввиду что нужен максимально быстрый код, быстрей просто не бывает, что тут не понятно.

Переписать код на каком то языке ассемблера и собрать. Быстрее уже точно не будет.