Мир совсем уже двинулся

Ах, Portal: Solver

Попытался в редакторе сделать коридор длиной 18.446.744.073.709.551.615 метров



Проиграл.
(Потребовалось >58016< МБ оперативки)

========
#news
========

Бета версия !
Вышла Бета версия ! Редактор карт, переработка Солвер Хэнда, Отражающие Панели и т.д. !
Переработанные уровни спиной к спине с новыми механиками, но меньше слов, скачайте и попробуйте сами !

Небольшая памятка по поводу новых биндов :
G - Заморозить объект в воздухе
R - Переключить ориентацию в пространстве (Solver Hand)

Следите за новостями о анонсах наших будущих проектах и спасибо вам, за вашу поддержку !
В ближайшее время мы выпустим Portal: Solver SDK (делать карты через код, альтернатива стандартному редактору для программистов)

Portal: Solver Gamejolt

Сцена на изображении сделана BnTr58

Finally

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

Контекст: Чтобы передать данные между C++ кодом и шейдером, нужно вручную создать и заполнить структуру. И при сотни тысяч шейдеров это утомляет. Даже Эпиков

хаха анрюшу обделили

Почему в час ночи вместо работы в UE я должен разбираться почему он падает нафиг

И сюрприз сюрприз - падает из-за Race Condition в сборщике мусора (на скрине FGCReferenceTokenStream и UGCObjectReferencer)

Когда объект еще не успел удалиться и сборщик мусора натыкается на его "полуживую" версию

Дурашка блин

Я понял
Час ночи для Анрила - переход в страну невиданных чудес

То сборщик мусора наебнется
То внутренняя ошибка компилятора.... что бл-

Суть задачи: Есть время жизни (скажем, партикла) длинной 3 секунды. И его текущее время жизни (со спавна). Нужно преобразовать его в прозрачность, да так, чтобы от от 0 до "middle" оно начиналось от 0 до 1, а вот дальше от "middle" до конца жизни - плавный спад от 1 до 0

Есть функция MapClamped, которая преобразовывает значения от А<->Б до 0<->1 (или 1<->0), и плюсом, ограничивает выходной диапазон (чтобы не получить -0.2 или 1.3)

И в чем суть: Есть 2 варианта реализации функции CalcOpacity. Сравнить входное значение с "middle" и посчитать нужный диапазон. Или! Просто взять и посчитать 2 диапазона и затем умножить их друг на друга (ибо тут математика сработает прекрасно)

И резонный вопрос: Что выбрать? Моя GLSL-натура говорит что ветвления - зло. Предсказатель ломает выполнение, штрафы, и тд..., но вторая натура говорит, что операции деления (divss) занимают очень много тактов. От 10 до 40 штук, и что оно не стоит того

Поэтому взял миллион значений, сгенерировал их, и погонял на своем Core i5 12400f в сборках Debug и Release на компиляторе MSVC (без спец флагов и тд.)

Результаты на лицо - в релизе на безвитвленном варианте аж на 2 такта быстрее!

Но почему в релизе всего 4-6 тактов на элемент, если функция такая огромная?

А тут вмы можем заметить механизм Out-of-Order Execution - внеочередное выполнение инструкций, когда процессор может продолжать выполнять следующие инструкции (спекулятивное выполнение), не дожидаясь ОЗУ (В моем Core i5 окно выполнение инструкций составляет внушительные 512 операций)

Вот такие дела.... А про Debug сказать ничего не могу. Он все честно выполняет. Очень честно. Очень плотненько. И очень жирно

^ Где-то в офисах Epic Games

Почитал

Вздохнул

Сделал пометку

ООП умирает. Если и писать движок, то ориентированный исключительно на ECS

Также многопоточка. Она тоже нужна. А лучше всего - когда математически описана графами (наука рулит, сэр!...)

Так, в пример графам, Render Graph (RDG) - незаменимая штука для Vulkan и DX12

V3 ❌
Latest ✅

Ну или я просто не выкупаю в чем мем