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


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


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

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

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

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

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

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

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

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

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

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

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

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

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



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

А что если переделать обработчик скриптов и перевести скрипты сразу в двоичный вид + сохранение совместимости с текстовыми скриптами? Теоретический это должно повысить скорость работы движка.

Так это же скриптовый косяк. Такой код, как правило, даже в скриптах не нужен.


Замерял кстати?
Выглядит некрасиво, по сути ничего ужасного - 65к итераций даже для скрипта ерунда. Большая часть итераций получает из движка nil и ничего не делает.

В опенхрей и огср добавили методы итерации по существующим объектам.
Если такой цикл используется для поиска одного объекта, такой цикл можно было удалить сто лет назад.
Может тебе скооперироваться с PP, ОГСР или любым другим модом, в котором подчистили скрипты?

Я из какого-то репо такое подрезал:

Хотя, мне кажется, если замерить скорости, то особого выигрыша не будет. Просто "синтаксический сахар", меньше коду.

Можно просто выкинуть Луа и вкручивай что-нибудь пошустрее.

Поддерживаю, значительного не будет... учитывая что alife():object(i) заканчивается в движке map_NETID[ID] - прирост очень маленький за счет уменьшения итераций и невозврата nil через luabind. Самая трудоемкая итерация - это поиск объекта по его имени, но это больше вопрос к дизайну кода. А по поводу остального переноса - любой функционал, перенесенный в движок - сразу становиться статическим и "трудномодифицируемым". Для примера - амк-алайв - захотел ты добавить какую то хитрую реакцию на объект или событие - будь добр пересобери движок. Но мои тесты показали что даже полное отключение алайфа не добавляет особой производительности (по сравнению, например, со схемами АИ, отключение которых дает этак процентов 15-20). Вот оптимизацией скриптов заниматься, профайлингом - вот это благое дело... Да и я не согласен с ForserX что ЛУА такой уж медленный - смотря как его "готовить"...

или вылетает с attempt to index a nil value

А, не, беру свои слова назад... Меня торкнуло и я померял.
с++ в движке

экспорт
class_<CALifeSimulator>("alife_simulator")
.def("iterate_alife_objects",&iterate_alife_objects)

Луа в скриптах


т.е. мы делаем по 100 итераций обращения туда и туда... почему 100? ну например приперло на апдейте какого нибудь биндера кому то это делать...
Результат - время в микросекундах:
[11.09.19 12:12:52.069] test 1 count[3729223] time[17154788]
[11.09.19 12:12:52.069] test 2 count[3729223] time[3562466]
При единичной итерации
[11.09.19 12:19:10.499] test 1 count[36923] time[156888]
[11.09.19 12:19:10.499] test 2 count[36923] time[33034]

т.е. примерно в 5-ть раз быстрее... как по мне - стоит заморочиться
p.s. желающие померять level.object_by_id - оставляю Вам для факультатива...

На деле совсем не в 5 раз. Так никто не измеряет. Недавно здесь тоже оптимизировали циклы.
Найди в скриптах реальный такой цикл и замерь.

Это безотносительно того, что такие циклы не нужны и их надо убирать.

Давно хочу для ХЕ сделать метод level.search_by_id(id), чтобы объекты nil само пропускало, сканирования аидишника может в разы ускорить.

так на реальном же цикле понятно что я предложил идеальный вариант, выбросив внутренности цикла обработки оставив только аккумулятор. Если не я себя порадую то кто? (с)
Я отдаю себе отчет что прирост будет намного меньше.
Если мне не изменяет зрение - OBJECT_REGISTRY это map,и вроде как он не sparse, во всяком случае в моем движке я не смог найти подобных значений в нем на разных сейвах. далее object(id) выполняет const_iterator find(id) на каждый вызов, т.е. 65к раз, и чем больше этот мап тем больше МС на это уходит.
iterate_alife_objects делает for только по существующим объектам, например только 23к. т.е. уже здесь должен быть выигрыш. пусть не в 5-ть, но в 1.5 раза, но больше чем 1% да и читаемость кода повышается. По поводу реальных циклов - я писал профайлер для апдейтов биндеров всяких скриптовых , так что я понимаю, что такое выигрыш на нем в 10 миллисекунд...
===
а на level.object_by_id прирост еще больше, там объектов еще меньше, чем 65к итераций. так что в любом случае будет прирост. Предложите свой код, может у Вас лучше получиться, я ж не говорю что он идеален.

А в чем смысл, искать объект по ID, если по ID его можно получить сразу alife():object(int id)?

Значит так.

Количество итераций на порядок меньше, на сколько помню полный скан ID'шника занимает 15 мс, а так будет 2-3 мс или меньше.

Всем привет!

Занимаюсь разработкой мультиплеерного мода на ЗП. Для игроков сделал скрипт bind_player_mp.script, который работает на клиенте.
В целом всё ок и оно работает. Но изредка скрипт отваливается. Например не выполняется код в апдейте.

И собственно вопрос, как можно отловить это? Можно ли в движке что-то подкрутить, чтобы в целом игра падала или ещё как?


PS: Такое уже было, когда из скриптов вызывал "кривые" движковые методы, которые при вызове из движка роняли игру, а из скрипта - просто падает скрипт без каких либо ошибок.

JustChiller,
Стоит попробовать debug версию движка.

Вообще даже больше. Я когда это дело у себя оптимизировал, то такие циклы насколько я помню до ~200 мс задержку давали. В игре это ощущается как кратковременный фриз. А переносом в движок удалось снизить до 5 мс. Там был перебор всех серверных объектов, которых около 25к. Это клиентских объектов обычно мало, 1-2к, тут конечно гораздо быстрее.

Товарищи, столкнулся с такой проблемой с физикой. сборка x64 на основе 1.0007rc1, вот видео

Все происходит на свалке возле перехода на Бар. спавниться небольшой предмет. при спавне ему снимается флаг UsedAI_Location через нетпакет. если стоять сверху блоков - при спавне предмет проваливается на верх нижней плиты. если в момент спавна подпрыгнуть - предмет спавниться и падает на верхнюю плиту. на х32 сборке такой проблемы нет - предмет сразу появляется на верхней плите. Подскажите, пожалуйста, хоть в какую сторону копать? Спасибо!

Winsor, попробуй эту правку:
https://github.com/xrOxygen/xray-oxygen/com...ac41e07a0a93d6e
code/engine.vc2008/xrPhysics/Physics.cpp

Спасибо, но не работает. У меня вместо surface.mu = FLT_MAX; стояло surface.mu = std::numeric_limits<dReal>::max();
но как бы идея то одна и та же... Можете посоветовать что еще?

Winsor, вот пример спавна авто по координатам. Переделай на свой класс примерно так же.
Тут нужно смотреть какая координата - верх и чуток её завысить ( или занизить?).

Блин , это вектор направления, к точке спавна - не подойдёт.
Примерно так же надо править спавн-координату.

Спасибо, идею я понял, этот вариант я оставлял "на потом". Все таки хочется понять что не так с х64 в отличие от х32.

Winsor,
Покопай в сторону SURFACE
Oxy

-StalkMen-, тут ни мой, ни твой вариант не поможет.
При спавне предметов таким макаром, задействована камера. И от её взора зависит "высота" ( сила прилипания) спавна.
Такую я ерунду замечал, что если опустить камеру в низ, то спавн уходил под землю, но если смотреть в небо то спавн появлялся на поверхности.

Это мысль вслух.


Может просто уменьшить скриптово дистанцию спавна от актора? До 0.1 например.
Чем выше дистанция, тем меньше сила прилипания к грунту ( даже не сила, а больше градаций существует для преодоления силы) .

Опять мысль вслух.

Winsor, чем отличается 32 и 64 физика? Там разные версии ode.

Есть подобная фигня с воллмарками в СДК (да и в игре, но в ней скорее всего z-fight эффект).

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

А точно вовремя снимается? Координаты не успевают пересчитаться?


На 0:30 не проваливаются и без прыжка. На 0:36 проваливается уже лежавшая.

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

Попробуй увеличить модель раз в 5, будут проваливаться или нет. Или аптечки под ноги поспавнить.

Еще можно попробовать эти шпильки из урана сделать

я переделал конструктор серверного объекта, флаг снимается уже не из скриптов, а прямо в момент CSE_ALifeObject::CSE_ALifeObject() - т.е. до корректировки позиции этот флаг уже снят.

ну там судя по всему спавн пришелся "сверху" модельки трубки, уже заспавнившейся.

можно немножко подробнее что это за щаг? objects_per_update?

сам топи урановые шпильки...

По поводу спавна - проваливается, даже если спавнить по фиксированным координатам, не только по координатам актора. причем это происходит на большинстве поверхностей (материалов). сейчас попробую "поднять" спавн на толщину/высоту модели над поверхностью.
а с SURFACE - у меня мозга не хватает понять что именно там происходит и почему. т.е. есть подозрение что указатели x32 и х64 разные по размеру и неправильно смещение по блоку памяти идет. Если тупо вставить код из Окси - то крашится игра дальше, когда пытается с полученным объектом surface что-то сделать. Велик тот человек который смог понять что к чему и как оно работает - я пока пас...

в консоли ph_frequency, который преобразуется в fixed_step и CPHWorld::SetStep
Шпилька тоненькая, возможно за шаг просчета физики успевает упасть сквозь плиту настолько, что уже не пересекается с мешем, и благополучно падает дальше.


Ну в смысле массу увеличить.


Если аналогичной правки нет, надо добавлять. Смысл в том, что под х64 в структуре dContact компилятор укладывает члены не строго подряд, а выравнивает на 8 байт, в результате в памяти между членами появляются пропуски. ГСЦ для получения указателя на член использовало размер предыдущего члена. Под х32 без пропусков это работало, под х64 с пропусками - нет.

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

Напрямую эта правка из окси тебе не подойдет. В окси изменили структуру dContact, переставили в ней члены, поэтому и формулы другие.
3rd-party\ode\include\ode\contact.h

Попробуй такой дефайн:
#define SURFACE(Ptr, Stride) ((dSurfaceParameters*) (((byte*)Ptr) + (Stride-offsetof(dContact, geom) + offsetof(dContact, surface))))

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

ph_frequency 50
ph_frequency 200
результат один и тот же.

Даже не знаю. Ну пойду делать спавн выше, других идей нет.

Winsor, а что это у тебя за деталь на видео?

Мне кажется большой предмет вроде РПГ или пулемета, заспавнившись внутри актора нанесет ему нормальный такой урон

трубка маленькая. изогнутая.

к сожалению - проваливается даже если по координатам фиксированным спавнить.

Winsor, увеличь шейп модели. Это должно помочь.
Движок не оперирует шейпами в сечении меньше 1 сантиметра (точно), а от 1-10 см наблюдается околизия.

Есть болты проваливающиеся под землю. Этот баг в ЧН был точно ( у меня в движке есть).

Вообще, предмет не должен никуда проваливаться без физ. пинка. В оригинале ТЧ, даже если предмет спавнится наполовину в стене, то там и остается, пока его кто-нибудь не тронет.

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

Это не баг а фича, убирать сразу не нужно

cjayho, я так же считаю. Типа болт утонул в жидком асфальте. Хавок.

Кто знает формулу? Дано два вектора, текущий и нужный, надо вычислить угловую скорость чтобы объект развернулся на нужный вектор. Надо для ракет с стабилизацией, чтобы боком не летали.

Не знаю, видели ли вы или нет. Слежу за этим интересным проектом и ребята молодцы - прикрутили к ТЧ dx11 самописный как я понял, только не много трогая структуру из ЗП.
https://ap-pro.ru/news/v_prosectors_project...2019-09-27-1168.

В теме проекта на предпоследней странице более подробно расписали.

Общем сам разобрался.

Можно код добавить в движок, точней нужно. Нужно всем! Настоятельно рекомендую!

увеличил модель, результат на видео... О_О

в начале запись из-под студии как то глюкнула, смотреть с 15-й секунды. нипонимай.