Редактирование движка - Страница 136 / Мастерская: создание модов для S.T.A.L.K.E.R. / GAMEINATOR forums

На сайт

Правила форума

Фотохостинг

Помощь по разделу

Сайт S.T.A.L.K.E.R. Inside / [ЗП] Параметры командной строки / Распаковщик ресурсов

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

Опции

RayTwitty

22.01.2016, 17:18

Сообщение #2701

Игровой Бог

Репутация:

648

Группа: Участник
Сообщений: 5354
Регистрация: 24.09.2010

Цитировать выделенное в форуму быстрого ответа

Редактирование собранного движка

Проект X-Ray extensions и его вики
Lua-перехватчик от alpet
xrLuaFix от RvP
xrLuaFix в редакции от Artos
xrLuaFix в редакции от svarog2741
LuaXML библиотека парсинга xml-файлов из скриптов (подключается при помощи функции require, которая есть в xrLuaFix)
NoProtect 1.0006 исполнительные файлы из Steam-версии без защиты
Документация к X-Ray (11.10.2004)
Файл заголовков от отладочного 6 патча

Cut X-Ray

Цель проекта - создание отдельных изменений движка игры с их последующей комбинацией с другими правками.
Авторы: SkyLoader, _призрак_
Для платформ: ТЧ 1.0004 и 1.0006, ЧН 1.5.10, ЗП 1.6.02
Адрес проекта на Google Code: https://code.google.com/p/cut-x-ray-project/
Страница на Moddb: http://www.moddb.com/mods/cut-x-ray-project-soc-cs-cop

Пак 1

1. Исправление вылета "can't find rank" для оружий.

2. Смерть от первого лица.
Видео: https://www.youtube.com/watch?v=c-4dNyvizxY

3. Collide
Возвращена коллизия мертвых тел с неписями и актором, как она сделана в старой физике билдов.
Видео: https://www.youtube.com/watch?v=1xNn04f3djc

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

5. Исправление вида от 3-го лица.
Изменено положение камеры от 3-го лица (1). Стрельба идет по перекрестью, а не по направлению актора. Если включить вид от 3-го лица (1) и удерживать Shift, то ГГ будет автоматически целиться в ближайшего непися или монстра.
Проблемы: Стрельба по перекрестью идет также при виде от 3-го лица (2). Если при автоматическом нацеливании непись/монстр удалится или перейдет в оффлайн, будет движковый безлоговый вылет. Я думал вырезать это нацеливание, но решил оставить.

Пак 2

1. Luminosity progress (только ТЧ)
Возвращение шкалы освещения вместо шкалы "заметности" ГГ, как в билдах.

2. Запрет на доставание оружия в машине (только ТЧ и ЧН) и на лестнице (ТЧ, ЧН, ЗП).

3. Руки на руле в машине. (только ТЧ и ЧН)
Видео: https://www.youtube.com/watch?v=nYrnrfGkO7Y

4. Отсутствие распознавания неписей перекрестием:
При наведении на непися перекрестье имеет дефолтный цвет. Также не показывает информацию о неписе, если смотреть на него.

5. Bind_object:
Возможность использовать скрипты в мультиплеере.

6. Из оружия на классе бинокля можно стрелять (только ТЧ)

Пак 3

1. Включение некоторых команд без использования ярлыка. Можно патчить по отдельности. Команды: -smap_4096 (максимально улучшенные карты теней), -mblur (включение блюра).

2. Измененная анимация безоружного гг.

3. Увеличение дистанции диалога с неписями (для создания сценок на расстоянии)

4. Исправление вылета при использовании предметов из трупов неписей.
В отличии от версии Kolmogor'а, здесь отключено само меню использования.

5. Возможность поднимать болты как обычные инвентарные предметы (комбинировать с модом Charsi "Заканчивающиеся болты")

Скачать все паки

Правки от RayTwitty aka Shadows

Geometry LOD fix (CS 1.5.10) – расширение диапазона консольной команды r__geometry_lod
Camblu crosshair for build 1865 – замена перекрестия прицела на кружок в билде 1865
Vertex buffer fix for NC Project – исправление вылета по переполнению буфера в NC Project
NO 100 sovetov fix (COP 1.6.02) – убирает надписи "100 советов" с экрана загрузки
Demo Record fix (SOC 1.0006) – убирает красные надписи в режиме demo_record
Weapon Bobbing Beta (SOC 1.0006) – раскачка оружия при ходьбе (бета-версия)
Build Loadscreen (SOC 1.0006) – билдовский экран загрузки со статичным изображением
Detail Density fix (SOC 1.0006) – расширение диапазона консольной команды r__detail_density
Mipbias fix (SOC 1.0006) – расширение диапазона консольных команд r1_tf_mipbias и r2_tf_mipbias
No Quick Use fix (SOC 1.0006) – запрет на использование аптечек и бинтов по быстрым клавишам
Sun Near fix (SOC 1.0006) – расширение диапазона консольной команды r2_sun_near
Target Font (SOC 1.0006) – замена шрифта под перекрестием прицела на шрифт DI
Unload Magazine fix (SOC 1.0006) – фикс скриптовой функции unload_magazine - теперь патроны разряжаются в инвентарь
PNG Screenshots (SOC 1.0006) – игра теперь делает качественные скриншоты в формате png

Скачать все правки

Правки от K.D.

xrPatch v0.8 – патчер для увеличения радиуса прорисовки травы
detail radius+density fix [SOC 1.0006] – добавляет регулировку радиуса отрисовки травы через консольную команду и расширяет диапазон регулировки плотности травы до 0.02

Правки от macron

Исправленный экзешник для SoC 1.0006

Доработанный и исправленный экзешник для ТЧ 1.0006 (на основе Steam-версии без защиты)
Включает в себя исправления вылетов, а также очистку лога игры от засоряющих сообщений. Более подробное описание внутри архива.

Ссылка: https://yadi.sk/d/At9Tw0ueSaDyS

X-Ray extensions portable

Портативная версия расширений движка "X-Ray extensions"
Платформы: ТЧ 1.0006, ЧН 1.5.10, ЗП 1.6.02
Эта версия имеет все нужные библиотеки и патчеры, а также настроенные bat-файлы для успешной компиляции. Более подробное описание внутри архива.

Ссылка: https://yadi.sk/d/OLYPbDXWjyEkH

Правки от Kolmogor

Правленный xrGame для SoC 1.0004

Изменения:
1. Добавлена консольная команда fov [5.0, 180.0] - изменяет глобальный FOV камеры.
2. Добавлена консольная команда k_ammo_on_belt [on\off] - включает\выключает использование патронов с пояса.
3. Артефакты работают из рюкзака, а пояс служит контейнером.

Ссылка: http://rusfolder.com/42636653

Правки от Kontro-zzz

Изменение значения hud_fov

Правки фиксированных значений параметра hud_fov - 0.37 либо 0.53, для CS 1.5.10 и для билда 3120.
Должно работать на GOG версии и no DVD.

Редактирование исходников

Скачать все исходники отсюда или с оригинальных постов SoC 1.0007rc1 SoC и CS CoP X-Ray 2

Репозитории

[SoC]
() Alpet & KD / оригинальное репо [Архивная ценность]
() xrDev [Архивная ценность]
() CleanXR [Архивная ценность]
() KRoddin [Архивная ценность][/b]
() Lost Alpha old [Архивная ценность]
() Репозиторий OGSE | Самый актуальный форк (KRoddin) | Версия от Abramcumner с небольшими исправлениями
() 1exx [Архивная ценность]
() Shkiper2012 [Архивная ценность]
() Morrey (dx10) [Архивная ценность]
() OP Engine (Winsor)
() Kondr48 [Архивная ценность]

[CS]
() RedPython [Архивная ценность]
() xrDev [Архивная ценность]
() OpenXRay [Архивная ценность]
() Charsi82 [Архивная ценность]
() Abramcumner | drksnc (MP) [Архивная ценность]
() RainbowZerg [Архивная ценность]

[CoP]
() Forser
() OpenXRay
() CoC | Demosfen | Last Day
() Abramcumner
() Im-Dex [Архивная ценность]
() xrDev [Архивная ценность]
() Tron [Архивная ценность]
() mrmnwar [Архивная ценность]
() Avo [Архивная ценность]
() vincent-t [Архивная ценность] | Старый репозиторий
() Shoкer
() Morrey CS-COP [Архивная ценность]
() Morrey [Архивная ценность]

[2.0]
() Saas
() xrOxy

Компиляторы x64: SoC CS CoP
NDA GSC

Оригинальные версии движков

Могут понадобиться для восстановления оригинальных библиотек.
SoC SoC ENG CS CoP
GOG version [1.0006, 1.5.10, 1.6.02]
Multi-patch version [1.0006, 1.5.10, 1.6.02]
Официальный мультиплеерный (невышедший) патч для SoC 1.0007rc1.

Инструментарий

IDA Pro (русский сайт)
QtDiaExplorer и прямая ссылка на скачивание
TortoiseSVN

Уроки

Изменение плотности травы и создание патча через IDA Pro

Автор: _призрак_
edited by: RayTwitty aka Shadows

Для редактирования нам понадобится программа IDA Pro.

1. Запускаем IDA Pro.
2. Загружаем бинарник рендера xrRender_R1.dll или xrRender_R2.dll.
3. Теперь необходимо найти, где регистрируется консольная команда. Жмем Ctrl+T и вводим r__detail_density.
4. Находим функцию и тщательно ее разбираем (я ее полностью разбирать не буду, только укажу, где задаются параметры:

Код регистрации консольной команды

Код

fld ds:flt_10064400 -- нижнее ограничение равное 0.6
or dword_1007CACC, 8
sub esp, 8
fstp [esp+30h+var_2C]
mov ecx, offset unk_1007CA9C
fld ds:flt_10064380 -- верхнее ограничение равное 0.2
fstp [esp+30h+var_30]
push offset aSs; "ЪЩЩ>"
push offset aR__detail_dens; "r__detail_density"
call ds:??0CCC_Float@@QAE@PBDPAMMM@Z; CCC_Float::CCC_Float(char const *,float *,float,float)
push offset sub_1005E080; void (__cdecl *)()
call _atexit
add esp, 4

Если вы заметили, чтобы трава стала плотней нужно уменьшить параметр, а чтобы травы стало меньше, нужно параметр увеличить
5. Нам нужно увеличить плотность травы: следовательно нужно изменить верхнее ограничение. Как это сделать? Есть три варианта:

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

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

Третий: создать переменную. Отличный вариант. Единственный минус - я не знаю как это сделать

Я пошел по второму пути. Два раза щелкнув на ds:flt_10064380, IDA отправила меня в дебри под названием .rdata. Там я нашел переменную, которая называлась - flt_1006452C и которая имела значение 0.0720999.
Насколько я понял, flt_1006452C - не является названием переменной, это сборка из двух показателей - (тип числа)_(смещение). В нашем случае это число типа float, которое находится по адресу 1006452C. Ну что же, приступим к редактированию!
6. Отправляемся в самое начало файла. Как? Сверху есть что-то типа статус-бара - строка состоящая из синего, серого, черного цвета. Нажимаем там в любом месте мышкой и ведем влево до конца.
7. Опять ищем r__detail_density. Находим в этой функции строку fld ds:flt_10064338. Дальше самое интересное - жмем на вкладку Hex View и там у нас выделяются какие-то цифры. Это наша переменная 10064338, только написано наоборот. Сравните:

Код

38 43 06 10
10 06 43 38

Похоже, не правда ли?

8. Начинаем редактировать. Нам нужно поменять 4338 на 452C (т.е. заменить ссылку с одной переменной на другую). Жмем правой кнопкой мыши на этих цифрах и выбираем пункт Edit. Меняем 38 43 на 2С 45. Дальше жмем где-нибудь в коде (это нужно сделать обязательно!).
9. После этого жмем правой кнопкой мыши и выбираем commit changes. Таким образом, мы поменяли ссылку на переменную и теперь верхнее ограничение будет равно значению из другой переменной.
Но IDA не меняет исходный файл. В нашем случае мы можем только создать файл изменений. Делается это так: File -> Produce file -> Create DIF file. Назовем его test. Этот файл можно открыть при помощи блокнота и посмотреть, что получилось.
10. Теперь необходимо внести изменения из этого файла в движок. Это можно сделать при помощи патчера bpatch. Качаем, смотрим и запускаем bpatch.cmd. Я думаю, что батник вы сможете изменить самостоятельно (настроить пути файлов и т.п.) - там все элементарно.
11. Все! Изменения внесены в движок, можно тестировать

Огромное спасибо Kolmogor'у и malandrinus'у. Если бы не они, я бы ничего не сделал. Спасибо вам еще раз.
Спасибо и Rolan'у, с которым я очень много беседовал и тоже узнал много чего

Полезные ссылки

Схема наследования классов оружия ТЧ
Схема наследования классов аномалий ТЧ
X-Ray Engine Wiki
Как скачать файлы с репозитория
Сборка движка X-Ray
Floating Point to Hex Converter
Online Markdown Editor
Команды ассемблера (вариант 1)
Команды ассемблера (вариант 2)
Описание регистров
Конвертер компьютерных величин
Binary to Text (ASCII) Conversion
Типы данных
C++ shell

Связанные темы
Закрома Родины | Исходники правок

Сообщение отредактировал RayTwitty - 27.08.2021, 00:15

Ответов

1_A

31.08.2017, 22:42

Сообщение #2702

Продвинутый геймер

Репутация:

104

Группа: Участник
Сообщений: 336
Награды: 4
Регистрация: 13.12.2011

Forser, хз у меня на х64 по 200-400 фпс, предела совершенства - нет

--------------------

Cheeki Breeki i v damke

ForserX

31.08.2017, 22:46

Сообщение #2703

Почти Игроман

Репутация:

91

Группа: Модератор
Сообщений: 516
Награды: 4
Регистрация: 19.07.2015

virus_ua, у меня она 15 ФПС выдавала, когда ещё в декабре того года собирал.

P.S. Пожалейте мой ПК. Он на статике выше 80 не выжимает.

Сообщение отредактировал Forser - 31.08.2017, 22:50

--------------------

X-Ray Oxygen

В армии по 01.07.2020.

Shoкer

01.09.2017, 00:47

Сообщение #2704

Кандидат Игровых Наук

Репутация:

2153

Группа: Участник
Сообщений: 3488
Награды: 4
Регистрация: 27.07.2009

Цитата(Xottab_DUTY @ 31.08.2017, 03:09)

Ты, помнится, где-то спрашивал расширение, которое сворачивало бы все диффы на гитхабе, чтобы удобнее было. Нашёл что-нибудь?

Честно говоря смутно помню что я там тогда спрашивал. У меня вроде только это и это стоит.

Цитата

Я также заметил что такой код стал приводить к вылету:
local pos = vector2():set(123, 456);
tostring(pos);

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

Цитата

Причина вылета в этой строчке ui_sleep_dialog.script:74:
pos.x = self.sleep_static:GetWndPos().x+self.sleep_static:GetWidth(), что равносильно pos.x = 321 + 40 --// 361

Тыц

Посмотрел более детально, проблема конкретно в комбинации self.sleep_static:GetWndPos().x = 123.456
Глянул как функция GetWndPos() экспортируется из движка (код экспорта в OpenXRay и в оригинале одинаков):

Код

IC const Fvector2& GetWndPos() const { return m_wndPos; }
...
const Fvector2* get_wnd_pos(CUIWindow* w) { return &w->GetWndPos(); }
...
.def("GetWndPos", &get_wnd_pos)

Меня смущает что функция get_wnd_pos возвращает указатель прямо на оригинальный объект.
То-есть (в моём понимании) делая в Lua

Код

self.sleep_static:GetWndPos().x = ...

Мы фактически меняем оригинальное значение.

Собственно где то тут видимо и кроется ошибка. Возможно LuaBind должен сам склонировать объект и вернуть в скрипты его копию, а вместо этого он возвращает оригинал ...
К сожалению пока слабовато понимаю где под капотом LuaBind-а всё это дело обрабатывается ...

Конкретно этот вылет фиксит переделка функции get_wnd_pos в:

Код

const Fvector2 get_wnd_pos(CUIWindow* w) { return w->GetWndPos(); }

Но это не панацея - нужно универсальное решение подо все подобные случаи.

Сообщение отредактировал Shoкer - 01.09.2017, 00:48

--------------------

Мне просто нравятся синие буквы под сообщением.

SkyLoader

01.09.2017, 00:56

Сообщение #2705

Почти Игроман

Репутация:

153

Группа: Участник
Сообщений: 614
Награды: 4
Регистрация: 03.05.2012

Цитата(Shoкer @ 25.08.2017, 01:16)

Всё что непосредственно по "двойному рендеру" - https://github.com/ShokerStlk/xray-16-SWM/c...83b6891f53cb2d7

Честно говоря, так и не понял, зачем так извращаться. Почему бы просто не делать рендер сначала в текстуру прицела, а потом в итоговый комбайн? Да, надо писать полноценную отрисовку сцены для текстуры. Да, будет отрисовка сцены два раза за кадр, но сильно заметно это не должно быть. Однако, в итоге мы не получаем багов вроде тех, что есть с HDR, и не будет того чередования отрисовки то в текстуру прицела, то в комбайн. Плюс для некоторых прицелов можно вообще делать рендер в прицел параллельно, как это сделано, например, в Insurgency.

Сообщение отредактировал SkyLoader - 01.09.2017, 01:01

Shoкer

01.09.2017, 01:07

Сообщение #2706

Кандидат Игровых Наук

Репутация:

2153

Группа: Участник
Сообщений: 3488
Награды: 4
Регистрация: 27.07.2009

Цитата(SkyLoader @ 01.09.2017, 00:56)

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

Когда это писалось я не совсем хорошо понимал как рендер вообще работает, впрочем и сейчас не особо понимаю - так что могу нести бред.

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

И я всё равно не понимаю как бы это помогло избежать баг с HDR, если номер кадра (Device.dwFrame) на оба вызова был-бы один и тот-же, и в лучшем случае у нас было-бы общее значение HDR для обоих кадров.

Код

gpu_id = (Device.dwFrame - 1) % HW.Caps.iGPUNum;

Не говоря о куче других мест где Device.dwFrame тоже используется в вычислениях.

Сообщение отредактировал Shoкer - 01.09.2017, 01:08

--------------------

Мне просто нравятся синие буквы под сообщением.

SkyLoader

01.09.2017, 01:23

Сообщение #2707

Почти Игроман

Репутация:

153

Группа: Участник
Сообщений: 614
Награды: 4
Регистрация: 03.05.2012

Shoкer, да, или дублировать код или рефакторить. Много, зато правильно и без багов

Для текстуры прицела по хорошему должен быть свой phase_combine(), который не трогает HDR в принципе (а также желательно без постпроцессинга всякого вроде блума и прочего), ведь это не итоговая картинка, а мы будем её только накладывать на модель. А Device.dwFrame в данном случае один и тот же, просто HDR трогается только при комбайне основной картинки.

Сообщение отредактировал SkyLoader - 01.09.2017, 01:32

Zagolski

01.09.2017, 06:20

Сообщение #2708

Почти Игроман

Репутация:

59

Группа: Участник
Сообщений: 629
Награды: 1
Регистрация: 13.12.2016

У меня есть идея основные кадры выводить без пропуска, т.е. в нормальном режиме, но также как и сейчас рендерить каждый третий кадр без худа и с другим fov, но параллельно с одним из основных, ну и тут же выводить его в прицел. Как раз сейчас этим занимаюсь.
По идее производительности жрать будет столько же, но фпс может быть выше из-за нормального функционирования вертикалки. Ну и не будет пропусков кадров. Да и в кадре для прицела можно будет качество графики снизить, чтобы еще меньше ресурсов жрало. А 1:1 параллельно рендерить - слишком по ресурсам накладно, фпс как минимум вдвое упадет во время прицеливания.

Сообщение отредактировал Zagolski - 01.09.2017, 06:22

SkyLoader

01.09.2017, 10:54

Сообщение #2709

Почти Игроман

Репутация:

153

Группа: Участник
Сообщений: 614
Награды: 4
Регистрация: 03.05.2012

Zagolski, как я уже написал выше, параллельный рендеринг в текстуру прицела подойдет только для некоторых прицелов, но не для всех. Для прицелов большой кратности будет сильно заметно, как будет отставать картинка, особенно, когда попытаешься быстро прицелиться во врага. В том же Insurgency по прицелу небольшой кратности с таким рендерингом уже было понятно, что есть небольшое отставание, по крайней мере на моём ПеКа. А на больших кратностях, думаю, такое прицеливание будет вызывать дискомфорт. В той игре на больших кратностях как раз и нет параллельного рендеринга, или может я не заметил. На хороших ПК наверняка это отставание заметно и не будет, но на слабых скорее всего будет.
Ты еще предлагаешь каждый третий кадр рендерить, это тем более вызовет отставание картинки. Рендерить с пониженной графикой тоже считаю плохой идеей.
Насчет падения фпс вдвое не согласен. Если не делать поспроцессинг для текстуры прицела, а только отрисовать сцену, то это не должно сильно влиять на фпс. Постпроцессинг нынче в модах жрет не мало.

UPD: Насчет отставания картинки, такое будет, если не делать синхронизацию потоков. Если сделать синхронизацию, то может и нормально будет. Только рендерить надо 1:1.

Сообщение отредактировал SkyLoader - 01.09.2017, 11:01

K.D.

01.09.2017, 11:57

Сообщение #2710

Почти Мастер

Репутация:

311

Группа: Участник
Сообщений: 1092
Награды: 5
Регистрация: 01.03.2011

Цитата(Shoкer @ 01.09.2017, 01:47)

У вектора нет функции преобразования к строке.

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

AndreySol

01.09.2017, 19:27

Сообщение #2711

Опытный Геймер

Репутация:

3

Группа: Участник
Сообщений: 150
Награды: 3
Регистрация: 16.02.2014

Цитата(-StalkMen- @ 31.08.2017, 23:33)

AndreySol,
Хм, вроде не в новом классе дело, ругается же вообще на game_cl_ArtefactHunt.
Вообще странно, зачем вызвался его "конструктор серверного класса". Отладчик в руки и вперёд.

Нашел на amk-team такое описание вылета:

Цитата

Expression : fatal error
Function : CObjectItemSingle<class CUIGameAHunt,1>::server_object
File : e:\stalker\patch_1_0004\xr_3da\xrgame\object_item_single_inline.h
Line : 54
Description : <no expression>
Arguments : Cannot instantiate server object, because server class is not declared!
Причина:
Переводчик даёт вполне адекватное определение. Но на самом деле вылет происходит по причине неопределённого состояния объекта, когда ему установлены оба флага для разрешения перехода в онлайн и оффлайн одновременно.

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

P.S. Вспомнил, недавно чистил системную папку "Документы", прибрал и все, что там было от Сталкера(у меня проект настроен в fsgame на локальную папку). Может в этом причина ?

Сообщение отредактировал AndreySol - 01.09.2017, 19:53

aka_sektor

01.09.2017, 20:59

Сообщение #2712

Грандмастер

Репутация:

118

Группа: Участник
Сообщений: 1788
Награды: 4
Регистрация: 04.04.2013

Цитата(Forser @ 31.08.2017, 22:27)

x64 Edition. 55-75 FPS. Годно.

Редактор погоды? Интересно.

Помнится, RayTwitty хвалился, что у него тоже есть ingame редактор. Тоже так выглядит?

Сообщение отредактировал aka_sektor - 01.09.2017, 21:00

--------------------

Те кто играют уже не забудут © Алексей Сытянов

ForserX

01.09.2017, 21:03

Сообщение #2713

Почти Игроман

Репутация:

91

Группа: Модератор
Сообщений: 516
Награды: 4
Регистрация: 19.07.2015

Цитата(aka_sektor @ 01.09.2017, 20:59)

Редактор погоды? Интересно.

Ничего интересного, по сути. Стандартный редактор, только на x64 с исправленным исключением.

--------------------

X-Ray Oxygen

В армии по 01.07.2020.

Shoкer

01.09.2017, 21:18

Сообщение #2714

Кандидат Игровых Наук

Репутация:

2153

Группа: Участник
Сообщений: 3488
Награды: 4
Регистрация: 27.07.2009

Цитата(aka_sektor @ 01.09.2017, 20:59)

Редактор погоды? Интересно.

Так то это родной ЧН-овский движковый редактор погоды. Именно он обязан исчезновению погоды из СДК.

Цитата(SkyLoader @ 01.09.2017, 10:54)

Насчет падения фпс вдвое не согласен. Если не делать поспроцессинг для текстуры прицела, а только отрисовать сцену, то это не должно сильно влиять на фпс. Постпроцессинг нынче в модах жрет не мало.

Дык соль же в том что постпроцессинг (АО, сан-шафты, ...) как раз делать надо. Нам ведь в прицеле нужна картинка экранного качества, а не промежуточный продукт для шейдеров. Тут максимум сглаживание убрать и DOF, и то сомнительно.

Кстати может ты, или кто либо, знаешь - насколько реализуемо динамически менять разрешение экрана на каждый кадр? Допустим рендерить каждый второй кадр в два раза меньшем разрешении.
Я так понимаю это просто так не сделать, ведь даже в оригинале каждое изменение разрешения ведёт за собой вызов vid_restart в консоли.

Сообщение отредактировал Shoкer - 01.09.2017, 21:22

--------------------

Мне просто нравятся синие буквы под сообщением.

SkyLoader

01.09.2017, 23:43

Сообщение #2715

Почти Игроман

Репутация:

153

Группа: Участник
Сообщений: 614
Награды: 4
Регистрация: 03.05.2012

Цитата(Shoкer @ 01.09.2017, 21:18)

Дык соль же в том что постпроцессинг (АО, сан-шафты, ...) как раз делать надо.

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

Цитата(Shoкer @ 01.09.2017, 21:18)

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

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

Код

u32        w=Device.dwWidth, h=Device.dwHeight;
// оригинал, для итоговой картинки
rt_Position.create            (r2_RT_P,        w,h,D3DFMT_A16B16G16R16F);
rt_Normal.create            (r2_RT_N,        w,h,D3DFMT_A16B16G16R16F);
rt_Color.create            (r2_RT_albedo,    w,h,D3DFMT_A8R8G8B8        );
// для прицела (размер/2)
rt_Position_temp.create            (r2_RT_P_temp,        w/2,h/2,D3DFMT_A16B16G16R16F);
rt_Normal_temp.create            (r2_RT_N_temp,        w/2,h/2,D3DFMT_A16B16G16R16F);
rt_Color_temp.create            (r2_RT_albedo_temp,    w/2,h/2,D3DFMT_A8R8G8B8        );

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

А в phase_scene_begin() и других местах начать использовать соответствующие кадру RT:

Код

if (bIsScopeFrame)
u_setrt (rt_Position_temp, rt_Normal_temp, rt_Color_temp, HW.pBaseZB); // для прицела
else
u_setrt (rt_Position, rt_Normal, rt_Color, HW.pBaseZB); // для итоговой картинки

Получится, что дополнительные текстуры будут висеть в памяти, хоть и разрешение у них вдвое меньше. Скорее всего есть варианты проще и оптимизированнее, но это надо спрашивать K.D. и тех, кто лучше в этом разбирается

На самом деле пока есть открытый вопрос: если делать последовательный рендеринг сначала в текстуру прицела, а потом в итоговую картинку, то как быть с вещами вроде ХОМов, которые рендерятся параллельно? Рендерить два раза для прицела и готовой картинки? Или же рендерить один раз? Делать какую-то синхронизацию для этого? Как быть с рендером детейлов, которые тоже идут параллельно.

Цитата(aka_sektor @ 01.09.2017, 20:59)

Помнится, RayTwitty хвалился, что у него тоже есть ingame редактор.

Там скриптовый, насколько я знаю.

Сообщение отредактировал SkyLoader - 01.09.2017, 23:59

K.D.

02.09.2017, 01:45

Сообщение #2716

Почти Мастер

Репутация:

311

Группа: Участник
Сообщений: 1092
Награды: 5
Регистрация: 01.03.2011

Цитата(SkyLoader @ 02.09.2017, 00:43)

Цитата(Shoкer @ 01.09.2017, 21:18)
Кстати может ты, или кто либо, знаешь - насколько реализуемо динамически менять разрешение экрана на каждый кадр? Допустим рендерить каждый второй кадр в два раза меньшем разрешении.
Как я понял, ты хочешь делать полноценный рендер сцены и освещение в текстуры меньшего разрешения для прицела. Может есть какие-то другие варианты, но я пока вижу вариант с дублированием текстур для G-буфера с вдвое меньшим разрешением.

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

Другое дело, что (на мой взгляд!), вы все с этими прицелами не туда смотрите. Зум в сталкере (да и не только там) делается уменьшением field of view камеры. Что это означает с точки зрения рендера? Во-первых, меняется фрустум камеры, соответственно, изменяется граф сцены (читай, набор видимых из камеры объектов). Во-вторых, меняются все эффекты, активно работающие перспективным преобразованием (солнечное освещение как базовый пример). Т.е. технически все остальное точно такое же. Отсюда логичный вывод - не надо отдельно картинку для прицела рисовать. Нужно теоретически: а) иметь два графа сцены и б) два набора матриц для эффектов (для приближения в прицеле и для окружающей картинки). Все, дальше во время рендера можно в шейдер просто нужные матрицы для объекта передавать, а для screen space шейдеров какую-нибудь маску применять или там через стенсил рисовать в два прохода.
Конечно, два раза граф сцены строить накладно. Можно просто флажок "приближения" ввести для объектов графа и выставлять его, если объект виден в прицел. Проблемой останутся только объекты, которых и так, и так видать, но их немного будет и тут уж можно и на овердро пойти.

BoBaH_671

02.09.2017, 08:22

Сообщение #2717

Новичок

Репутация:

1

Группа: Участник
Сообщений: 10
Награды: 1
Регистрация: 20.07.2016

Цитата(Forser @ 31.08.2017, 22:27)

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

В этот не запускается тоже. Просто ничего не происходит. Я что-то не так делаю явно. Покажите.

Xottab_DUTY

02.09.2017, 08:27

Сообщение #2718

Продвинутый геймер

Репутация:

36

Группа: Участник
Сообщений: 267
Награды: 3
Регистрация: 09.03.2013

BoBaH_671, должны лежать в папке с остальными dll-ками и xrEngine.exe два файла: editor.dll и editor_controls.dll и запуск через ключ -editor
Если OpenXRay, то там dll-ки называются чуть-чуть по-другому: xrWeatherEditor.dll и xrSdkControls.dll, ключ тот же.

Может у тебя просто дефиса не хватало в ключе запуска?

Ну.. Что увидел в сообщении)
Если не из-за этого, то не знаю даже

Сообщение отредактировал Xottab_DUTY - 02.09.2017, 08:28

--------------------

BoBaH_671

02.09.2017, 08:28

Сообщение #2719

Новичок

Репутация:

1

Группа: Участник
Сообщений: 10
Награды: 1
Регистрация: 20.07.2016

Дефис был. Я просто название ключа написал сюда. Спс за инфу. Проверю.

Zagolski

02.09.2017, 09:11

Сообщение #2720

Почти Игроман

Репутация:

59

Группа: Участник
Сообщений: 629
Награды: 1
Регистрация: 13.12.2016

DockPanelSkin.dll
Flobbster.Windows.Forms.PropertyGrid.dll
WeifenLuo.WinFormsUI.Docking.dll

А эти разве не нужны для редактора погоды? Не?

serg101188

02.09.2017, 09:31

Сообщение #2721

Почти Игрок

Репутация:

1

Группа: Участник
Сообщений: 28
Награды: 1
Регистрация: 31.05.2014

Всем привет
Кто сможет потскозать мне такая ситуация решил перекинут оружия из за в тч движковое рендер сделал понимает сдк 07 ну то есть ogf загружает из за анимаций 16 бит
Перекинул весь weapons huditem... Ну короче оружейку загружаются игру все нормально едет сталкера держат оружия а вот когда сам достаешь оружия не видно но стреляет покороче нету худа рук тоесть модели кто потскажит чо ещё не доделал или чота не правильно сделал если надо исходники посмотреть могу скинуть

Извеняюсь правописания писал с телефона тот все перековыркал

Я понимаю, что у нас тут за грамматику особо не судят, но, серьёзно, надо писать так, чтоб смысл хотя бы бы понятен с 1-2-го прочтения. Отмазка, что ты пишешь с телефона - так себе. Я тут с телефона 70% времени отвечаю и корректирую посты. [ForserX]

Сообщение отредактировал Forser - 04.09.2017, 14:43

« Предыдущая тема · Мастерская: создание модов для S.T.A.L.K.E.R. · Следующая тема »

3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)

Пользователей: 0