𝐑𝐨𝐨𝐭𝐓𝐨𝐨𝐥 𝐁𝐥𝐨𝐠
194 subscribers
561 photos
48 videos
5 files
59 links
ニャン
Download Telegram
Минутка интересного о С++

Пока работал, попалась в коде одна дилемма, поэтому вынес ее в отдельный файл
🔥2
Суть задачи: Есть время жизни (скажем, партикла) длинной 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 сказать ничего не могу. Он все честно выполняет. Очень честно. Очень плотненько. И очень жирно
💯2
❌ Сделать "правильно" через массив и указатели на указатель
✅ Расписать так, как не писал Ритчи в свои лучшие годы
❤‍🔥2🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
^ Где-то в офисах Epic Games

Почитал

Вздохнул

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

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

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

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

Ну или я просто не выкупаю в чем мем
😁2
Вот так, по сусекам на скворечник, собрал простой воксельный рендер на чистом Vulkan

Первое успешное использование Vulkan, ахах

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

И использовал я... Ни за что не догадаетесь: Compute Shaders))
🔥1
Хо-хо
Ну, вот так я и поизучал етот ваш Vulkan

Разобрался с дескрипторами, бррр. Такая душнота...

Зато своими ручками собрал красивую фабрику дескрипторов и пайплайнов, ибо почему бы и нет?

Теперь я понимаю за что еще люблю C++ - за непревзойденную выразительность, и одновременно, близость к металлу <3
💯1
This media is not supported in your browser
VIEW IN TELEGRAM
Бл

Надеюсь разработчики Анрила, точнее, те кто занимались UMG/Slate, когда чпокают свою жену, то чпокают не прямо, а через "высокоуровневую обертку"

Кто придумал эту связку Slate и UMG, покажите мне их!

Сука, я заплачу за свет и воду, и буду варить их в котле, индивидуально, КАЖДОГО

А для особо самоуверенных привяжу к стулу и буду палками тыкать Immediate-Mode UI фреймворками по типу ImGui
😈2❤1😁1
Прикол

Сидел значит в Rider, работал, скомпилировал код

Услышал в наушниках отчетливый звук из Анрила что код успешно скомпилировался

Смотрю на панель панель задач

А там нет открытого Анрила 💀



СлУхОвЫе ГаЛлЮцИнАцИи...
❤3😁1
2 варианта записи одного и того же в C++

Вроде бы и там и там условие...
Вроде бы 2 похожих блока...
Вроде бы 2 функции вызываются...

...или нет?
❤1🤯1💯1
𝐑𝐨𝐨𝐭𝐓𝐨𝐨𝐥 𝐁𝐥𝐨𝐠
2 варианта записи одного и того же в C++ Вроде бы и там и там условие... Вроде бы 2 похожих блока... Вроде бы 2 функции вызываются... ...или нет?
Как элегантный if ломает ноги персонажу

Казалось бы, переписал громоздкие переменные в красивое условие if(Left() || Right())

Меньше строк, код чище! Но персонаж начнет хромать. Почему?

Все из-за механизма short-circuit evaluation (короткое замыкание) в С++ (который плотно отражен в ассемблере)

Компилятор просто экономит такты процессора: если в условии A || B левое условие выполнилось A = true, то результат всего true || B уже и так ясен - и выполнять правый блок B просто не имеет смысла

Но мы забыли, что наши функции - пишут данные по ссылке внутри ([&] DistanceRight)

В итоге получаем красивый баг:
- Мы создали 2 float переменных, но не проинициализировали их (в них может быть мусор, космическое число, и тд.)
- Левое условие выполнилось, записало результат в переменную, и вернула true
- Компилятор радостно прыгает внутрь if, скипнув вызов для правого условия...
- И в DistanceRight остаётся лежать мусор из стека!
- Из-за чего математика в FMath::Max() начнет честно сравнивать левое значение с мусором... и персонаж будет улетать в стратосферу

Мораль сей басни такова
Красивый код - это круто, но side-эффекты внутри ленивых || и && - это классический выстрел в ногу. В буквальном смысле - правую ankle_r
❤1🔥1