А, вот ещё вопрос. При сборке xrLC под ЗП не у кого не было проблем с тем, что компилятор не собирал материалы? У меня тут баг с тем, что их название не записывается и игра вылетает из-за того, что не может найти noname материал.

Уважаемые знатоки кто-нибудь делал сверх-быстрые компиляторы для normal качества сборки мапы? Я плане того что Припять из оригинала компилилась за 7 часов на нормале, это нихрена не нормально. Хотя бы 2-3 часа.

Экий ты нетерпеливый. Учись.

x64, забыл сказать.

Это понятно, просто с материалами вроде ничего не было.
В xrLC:
У b_texture на х64 другой размер из-за указателя.
У CDB::TRI надо выравнивание поменять - GSC зачем-то влепили выравнивание 8 байт, в результате на х64 все поехало.
Это все еще KD проделал. Можно в xp-dev посмотреть.

Ну и уже в движке надо будет в просчете коллизий смещение зафиксить.

С текстурами разобрался. Хм... Может локация кривая. Нужно найти кого-то для теста.

Блин меня одного убивает скорость компиляции уровней в юнити и во всех современных движках, по сравнению с икс реем. Как они так сделали? Там расчет геометрии нереально быстро идет, а в юнити еще и солнечное построение в реальном времени.

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

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

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

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

Например я начинал (в 2012 ), на скриптах, есстественно -- не закончил...


Иконковое окно-"список" надо экспортировать в xRayExt. Тогда во всех интерфейсах точно прорыв будет.

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

Ты релиз что ли запускаешь? Что стектрейсы такие куцые?

Mixed

Запускал бы Debug под отладчиком.

С этим у меня тяжёлая ситуация, есть тут одно подозрение, если не выйдет - придётся юзать дебаггер.

---

А, ну вот и вылезло.

---
Нашёл...

Что ещё поправить в xrCDB?

Кажись понял в чём дело, вопрос пока снят...

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

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

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

Две стороны вопроса: дизайнерская и технологическая.

Дизайнерская: дизайнерам нужен список как в инвентаре - "список" из иконок. Это и даст (возможно) "прорыв" в дизайне интерфейсов.Драг-дроп -- не так-уж и важен...

Технологическия: ... А здесь мне и сказать особо нечего - не компетентен. Возможно надо делать как делали разработчики движка -- продолжая их тактику (что логично) - несколько дополнительных классов, функций и конфигов, в том-же стиле, "GUI-либа" в общем... Скорость работы интерфейса конечно важна.


Есть такой "калькулятор", ACalc назвали. Хоть в его создании я принимал участие - у меня его сейчас нет, но где-то наверняка есть ссылки. Он пересчитывает параметры из xml-файлов из того, что есть в (любые) нужные разрешения. То-есть - формула есть.

Ссылку нашёл (спасибо РедПитону).

в инвентаре драгдроп, в этом классе есть и список из иконок (другим классом делается). в чем прорыв я так и не понял, поясни на примере.

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

да я и не про добавления говорю, а про переделывание того что есть, расчет этих координат это опять же дело формулы, как ты верно заметил, а эти все калькуляторы опять время жрут, зачем сидеть за калькулятором, когда это сразу кодом можно высчитать, текстуры тут для облегчения можно нарисовать под более распространенные форматы (4/3, 16/9), а потом их уже дотягивать до 5/4 или 16/10 или еще что-нибудь. у меня какие-то там приблуды и работают, одна настройка подходит под три разрешения (на которых я долго тестировал), движок сам понимает шф или нет и там делит/умножает, существенно сокращается время настройки этих данных, но проблема с текстурами никуда не девается, нужно либо несколько текстур, либо одна большая, которую можно ресайзить без потери качества.

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

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

Да, возился. отличий особых между ТЧ и ЗП я не заметил. да, оптимизированы некоторые куски кода, некоторые классы называются немного по другому. переделан механизм работы с мультистрочным текстом - но чтобы это ускорило как то особо UI - я бы не сказал, более важное, наверное - появился UIRender.
Но после своих извращений над UI ТЧ я бы не сказал что оно медленное. Для ускорения работы самый лучший вариант - это как предлагали - делать темплейты в движке, в скрипты уже экспортировать готовые блочные решения. я не говорю что UI хорошее - нет. надо что-то делать с фокусом дочерних элементов, надо что-то делать с Z-уровнями (коих просто нет), что-то с окнами наподобие хинтов. но все это надо переделывать именно с нуля , с базовых классов. но зная эти проблемы - можно пойти на некоторые ухищрения (на которые шли сами ПЫСы, если посмотреть код скриптов - это очень заметно ), которые позволяют обходить эти баги и при этом прекрасно пользоваться UI без коренной переделки. например, частичное портирование механизма подсветки итемов в инвентаре из ЗП не привело к падению производительности. был даже сделан вывод состояния предмета на иконку с поддержкой конфига xml (в ЗП он статичный, меняется только в исходниках) - после некоторых издевательств над кешированием параметров - скорость отрисовки выросла очень и очень.

я пошел другим путем - я научил движок распознавать 21 мониторы и читать конфиги UI *_21.xml и отдал дизайнерам (людям с чувством прекрасного). а они уже изменили конфиг так, чтобы он красиво смотрелся на каждом мониторе. в движке никакой статической привязки, все отдано в конфиги, надо просто гарантировать загрузку правильного

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

uirender никакого отношения к производительности не имеет, этот вариант я давно проверил (некоторые моменты пысовского рефакторинга (не связанные с uirender) у меня работают, но что-то там я прироста не наблюдаю). а все эти темплейты, скриптовые "ухищрения" это борьба со следствием, локальная оптимизация о которой я и говорил.

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

с чего думал начинать коренную переделку? какие мысли по архитектуре окон при стандартном дизайне? зпшную архитектуру тестил?

Подскажи, каким "другим классом"?
Из скриптов доступно?

7.9, из скриптов не доступно, я же говорил что драгдроп вообще не особо предназначен для экспорта, там вспомогательные классы рисуют типа драг айтем сел айтем и т.д., там я когда экспортом занимался где-то 4 класса вроде дополнительно выгонял, или 3, не помню уже, и от них там еще потом что-то по моему идет, на этом я и понял что проще в движке все делать.

еще такой вопрос, на зп или тч кто-то писал реализацию fillvetricies для 3 и 4 скиннингов? в тч там просто неиспользуется, а в зп вообще грохнуто. единственный ощутимый затык при замене скелетов в тч на зп вариант чтобы все тянуть на уровне копипасты, либо опять резать контент, да и если тч модели поднимать на уровень засовывая туда все эти нанотехнологии, то опять же нужны эти функции будут.

блин, если кто-то рискнёт заниматься ui то это будет просто классно - было бы неплохо обновить функционал и стабильность. Например частый ресайз элементов приводит в вылетам:

Вот как-то раз захотелось сделать ресайз под размер итема - минуты 2-3 работы такого инва и получаем вылет)

по фокусу - попробуй создать несколько комбобоксов подряд вертикально, причем по координатам последний - самый верхний. выпадающее окно списка будет открываться позади всех следующих элементов. второе - те же комбобоксы, созданые "правильно", под ним какой нибудь список - открыть комбобокс и "поездить" мышкой - видно как фокус (событие mousemove) "проваливается" через бокс, при этом в движке чего бы я не делал... и с SetCapture игрался и с (On)MouseEvent - победить так и не удалось, косяк где то глубоко спрятан, либо не там искал. ну и еще есть пару косяков некрасивых с "проваливающимися" событиями.
з-уровни как раз и нужны для нормальной обработки событий, для правильной отрисовки динамических элементов...
в хинт "засовывать" элементы я планирую в ближайшее время, уже есть пару задач
зпшную архитектуру тестил? - нет, работаю на ТЧ. а в чем принципиальное отличие?
с чего думал начинать коренную переделку? - планировал разделить все таки рендеры "основного окна" и UI. пока только мысли.

Каспер, ты где ведешь перенос проекта ле? Может у тебя есть репа.

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


давай на примере, что за нормальная обработка событий? чем сейчас не нормальная? что за динамические элементы? чем сейчас динамические не нравятся?


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


зачем? впрочем я так и не понял что у тебя "основное окно", а что ui, и чем одно от другого отличается.

Обычно это делают рады простоты/удобства кода. Расчет положения UI элементов не такая уже и затратная операция, поэтому экономить на спичечных головках нету смысла.

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

Вопрос по openxray - он ещё жив и стоит ли вообще качать и собирать последнюю версию? Будут ли с этим сложности ( нехватка либ, несовместимость с оригинальными ресурсами игры)? В последний раз когда пробовал - оно не собиралось, да и сборка через батник не есть гуд(

В начале апреля влили PR: https://github.com/OpenXRay/xray-16/pull/160
Якобы должно все собираться без батников.


Это же опенсорс. Он жив, пока ты туда коммитишь.

abramcumner, ну а совместимо ли с ориг. ресурсами? А то я бегло почитал обсуждения на гите, там поднимали тему что новый lua ведёт себя по-другому.

В репозитории есть папка res. По идее там все нужные правки оригинальных ресурсов.



Спроси у Карлан`а (он обновил луаджит в ТЧ до 2.0.4), что ему пришлось поменять в скриптах из-за этого.

Конкретный пример - как Вы побороли то что выпадающее окно комбобокса открывается позади элементов , которые созданы после комбобокса. по логике - эго выпадающий список должен всегда выводится поверх любых элементов - механизма это сделать - нет. BringToTop/BringAllToTop- очень странная реализация.
Ну и обновление - в смысле в ручную? CUI::Render вручную? может мы о разных вещах говорим?


ммм... "проваливающиеся" события - я понимаю душой, что проблема в SendMessage - но толком побороть мне не удалось.
Динамические элементы - это выпадающие окна комбобокс (больная тема), это treeview со сворачивающимися нодами, это всякие адорнеры, которые атачатся к элементам и рисуют себя в их области - с последними обработка событий вообще жесть.



Есть основной рендер игры (основное окно - то что ты видишь при убранном худе), а есть рендер для элементов UI (тот же худ)- ну не знаю как еще объяснить.

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


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

Подскажите, плиз, где в движке смотреть автоматическое назначение предмета в слот при появлении этого предмета в инвентаре ? Т.е. к примеру имеем пустой слот под детектор, взяли детектор - он автоматом прыгнул в слот. Где это происходит ? Нашел цепочку: CActor::OnItemTake -> CInventoryOwner::OnItemTake, но собственно назначения предмета в слот не вижу...

OnItemTake - это "обработчики" события Take, которые вызываются (для ТЧ 1.0007) из CInventory::Take. там Вы можете увидеть вызов CInventory::Slot, в котором и происходит "магия".

====
Уважаемые знающие, столкнулся с багом (который говорят присутствовал еще с оригинала ТЧ) - при одевании на ствол глушителя и прицела - иногда текстура либо глушителя либо прицела может не вырисовываться на худе. при этом флаги аддонов выставляются правильно. лечится повторно снятием/одеванием, например, прицела. Сталкивался ли кто либо с таким багом и как боролись?

Благодарю!

Winsor, текстура = иконка или именно текстура на модели? Если текстура то могу лишь предположить что это связано с памятью)

только текстура на модели на худе. когда снимаешь/одеваешь глушитель после такого бага - оба аддона появляются. так что память тут думаю ни при чем. в ЗП такого повторить не удалось, но там и attachable_object переписана...

Winsor, в зп тоже такое есть

Что делать если при запуске скомпилиронных проектов на Mixed появляется сплэш и исчезает и из ошибок ничего не выскакивает? Как выявить ошибку в таком случае?

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

Попробую юзануть, за ответ спасибо.

а как боролись с этим?

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

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

Патчер для XR_3DA.exe из ОГСЕ (а может и для других пойдет) для возвращения стандартного значения размера экрана загрузки.
Автор: macron

Поместить XR_3DA.exe и запустить patch_ogse_intro.cmd

Скачать

Зачем патчеры для exe от которого есть сорцы

kasper, для тех кто считает что программирование это не для всех, для тех кто "ни хочу, ни буду, я лучше запилю ищо 100 диалогов чем освою азы кодерства" ))

Есть новости по "утечке" исходников LA DC? репозитарий не сделали общедоступным?