Исходный код S.T.A.L.K.E.R: Shadow of Chernobyl под Visual studio 2019

[Deathman 906]

В 18.08.2024 в 16:18, NanoBot сказал:

А тут гранатомёты ковыряли? На гитхабе быстро не посмотреть из-за ограничений на 1000 файлов. Я исправил оружие, теперь у меня гранатомёты работают без ошибок и многих ограничений, все классы умеют стрелять очередями, и пистолеты и гранатомёты, кроме ПГ. Быстро адаптировать свой код к этой сборки, сам не могу, если что.

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

[Злобная реклама]

[Degrus 0]

где найти чистый исходный код? не модифицированый

[Deathman 906]

В 04.07.2025 в 19:57, Degrus сказал:

где найти чистый исходный код? не модифицированый

Откатись на несколько коммитов к началу

[Mawrak 1 009]

Deathman тут делались какие-то правки по памяти по сравнению с ванилью? Собираюсь оптимизировать оперативку, и в ходе тестов обнаружил в данном движке повышенное использование RAM при продолжительной игре, чего не наблюдается, например, на стимовских бинах.

Для сравнения я запускаю свою сборку игры на одной и той же машине, с одинаковым юзером, и оставляю её на один час, замеряя в начале и в конце потребление оперативки. Запускал на стимовских бинах и на этих (с единственной правкой от меня - адаптация к стим архивам). Налюдаются следующие стабильные паттерны (числа усредненные но примерно одинаковые каждый отдельный тест):

Steam сразу после запуска - 1860 MB
Steam через час игры при бездействии игрока - 1780 MB

S.T.A.L.K.E.R.-SHOC-VS2019 сразу после запуска - 1860 MB
S.T.A.L.K.E.R.-SHOC-VS2019 через час игры при бездействии игрока - 2220 MB

То есть в режиме idle (игрок ничего не делает) за час игры данные бины заметно нагружают RAM, в то время как Steam версия вроде бы даже наоборот освобождает лишнюю память.

Собственно, вопрос - во-первых, что это вообще может быть? И во-вторых, это различия между Steam и GoG так проявляются, или это особенность конкретно данного движка для VS2019?

Изменено 17 августа, 2025 пользователем Mawrak

[Deathman 906]

@Mawrak, сорри чел, я не проверял этого если честно и не знаю почему это может быть, но если ты найдешь причину я буду рад если ты расскажешь в чем дело

[Mawrak 1 009]

Deathman понял, тогда буду изучать

[Mawrak 1 009]

Короче я так и не понял в чем именно суть проблемы, но я сделал следующие изменения.

1) Правки в загрузке ресурсов погоды: 

https://github.com/Mawrak/S.T.A.L.K.E.R.-SHOC-VS2019/commit/6c98d340e52f4ee03b7eb1ecdc75cc5b57d98a98
https://github.com/Mawrak/S.T.A.L.K.E.R.-SHOC-VS2019/commit/0efd04d665e47d1ab72340ba2409a7ca333d7722

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

2) Удалил подгрузку текстур при загрузке игры:

https://github.com/Mawrak/S.T.A.L.K.E.R.-SHOC-VS2019/commit/5a917d8340d37dc215fcf6ace8d6f27ca619706e

Сами по себе обе правки значительно снизили нагрузку на RAM (1305 MB при запуске вместо 1860 MB на максималках). При этом игра совершенно спокойно работает и просто грузит текстуры по мере необходимости, как ни странно. А вот после этой второй правки почему-то игра начала еще и гораздо более активно выгружать ненужные ей ресурсы - потребление RAM сначала растет как и раньше, но минут через 40 игра начинает активно выгружать ресурсы скачками, вплоть до того что потребление RAM становится меньше гигабайта (в состоянии idle игрока, думаю при активной игре будет не так круто но все равно, а ни разу еще не видел, чтобы RAM превысил 2 гига, раньше это происходило постоянно даже с правками по погоде).

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

Изменено 31 августа, 2025 пользователем Mawrak

[Mawrak 1 009]

Deathman приветствую, у меня на этом движке зависают анимированные элементы главного меню (которые как видео) после долгой игры без открытия меню (долгой = несколько минут, чем больше тем хуже). Это же касатся любого меню с такими элементами (меню загрузки игры и т. д.)
Не знаешь, с чем может быть связано? Это судя по всему особенность именно этой сборки. Ни в каком другом движке я такого не видел. И я починить сам не могу, я вообще не понимаю из-за чего это. Это сейчас основная проблема для меня.

[Deathman 906]

В 10.02.2026 в 03:19, Mawrak сказал:

Deathman приветствую, у меня на этом движке зависают анимированные элементы главного меню (которые как видео) после долгой игры без открытия меню (долгой = несколько минут, чем больше тем хуже). Это же касатся любого меню с такими элементами (меню загрузки игры и т. д.)
Не знаешь, с чем может быть связано? Это судя по всему особенность именно этой сборки. Ни в каком другом движке я такого не видел. И я починить сам не могу, я вообще не понимаю из-за чего это. Это сейчас основная проблема для меня.

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

Первые возможные виновники проблемы которые мне приходят в голову это:

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

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

 

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

[Mawrak 1 009]

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

я лично никогда не сталкивался с ней

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

[Mawrak 1 009]

Deathman опытным путем было установлено, что анимированные текстуры "застревают" только если они загружаются во второй раз. Если они считываются в первый раз с диска, то все норм. Следовательно, я смог починить проблему следующим образов:

https://github.com/Mawrak/S.T.A.L.K.E.R.-SHOC-VS2019/commit/565b280685c489e4a34d4134e01d916072315873

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

1) Оно не связано с ФПС;

2) Оно не связано с кодом обработки видео;

3) Оно не связано с кодом загрузки UI элементов;

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

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

[Сергей Андронов 278]

Mawrak Как ты его собрал? У меня визуалка даже 2019 находит тонну ошибок и прерывает сборку, либо же создаёт кривые dll с которыми игра не идёт, плюс размер с оригинальными не совпадает вообще никак.

[Mawrak 1 009]

Сергей Андронов я собирал на 2019, там в некоторых dll могут быть не совсем правильно настроены папки, например если в intermediate Directory стоит x:\intermediate, можно поменять на более универсальныq вариант $(SolutionDir)..\intermediate, в Output место x:\binaries\ поставить $(SolutionDir)..\bin\, и т. д (по аналогии с собирающимеся модулями, везде одинаково сделать короче). Скорее всего изначально вся сборка лежала на диске X или подключалась на него функцию mount, но для этого вроде файлов не приложено, проще переписать под единый формат.

Можешь взять мой коммит отсюда: https://github.com/Mawrak/S.T.A.L.K.E.R.-SHOC-VS2019/commit/0738e614b8e835b91ada5d5bfce385f8ece92871#diff-8d8d4d28cd035ff2eccf844d6b415a61936e725dd6c3f6c064f51e262b1944d0

Только не бери оттуда мою правку в ‎xr_3da/xrRender/LightTrack.cpp, там васня жуткая которая сломает освещение, это фиксилось и дорабатывалось сильно позже! Все остальное там это проектные файлы как раз. А этот файл верни как был.

Все корневые модули у меня вроде спокойно собирает даже без изменений в путях папок. В utils у меня до сих пор не все собирается, но оно вроде и не очень нужно. А что нужно типа eax.dll я из обычного ТЧ кажется взял.

Если при запуске в игре нет звука, значит OpenAL надо отдельно поставить из oalinst.exe.

1 час назад, Сергей Андронов сказал:

плюс размер с оригинальными не совпадает вообще никак.

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

Изменено 13 февраля пользователем Mawrak