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

Небольшой детектив.

Ковыряю я в отпуске mac платформу. В основном это мелкие фиксы, но есть одна особенность под этой платформой - это масштабирование. Так как разрешение экрана довольно большое, 4к, то рендерить редактор в масштабе 1 к 1 получается так себе. Все слишком мелкое и с этим невозможно работать. Но при этом система предоставляет коэфициент масштаба равному двум.

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

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

В этот момент я обратил внимание на странную особенность - по Х позиция курсора высчитывается верно, а вот Y зависит от масштаба камеры внутри редактора сцены

WTF вообще подумал я сначала 🤨 иии тут меня повело в какую-то неправильную сторону... ведь я стал грешить на особенности mac платформы.

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

Дошло до того, что я поставил рядом windows ноутбук и писал одинаковый отладочный код на win/mac сравнивая результаты. И что произошло? Правильно, различий никаких не было 🥲

Однако работало очевидно неправильно. На windows все впорядке, крестики 1 к 1 без всяких сдвигов вне зависимости от всего. В какой-то момент показалось что зависит от размера окна редактора, но нет...

Я вернулся к мысли что по Х все таки координата рассчитывалась верно, а по Y - нет. Точнее визуально было так. И я стал думать (эх, ключевое) где бы могла похериться Y координата. И я вспомнил про специальных хак для рендер-таргетов на mac: в определенном месте матрица трансформации переворачивалась по Y, это было сделано специально, тк рендер-таргет был перевернут.

В итоге я понял, что в математике проблем нет и процессор Apple считается все верно, а вот проблема как раз была в рендеринге картинки, частью которой был зеленый крестик все никак не совпадавший с красным

Переворот по Y для рендер-таргета пришлось переделать, сделать переворот еще ДО применения видовой матрицы, где задается трансформация камеры. И вауля, крестики совпали и проблема ушла

Такая вот поучительная история, которая в очередной раз показала: если тебе кажется что проблема в компиляторе/процессоре/частицах из космоса выбивающих бит из RAM, то проблема очевидно в тебе

На видео красный крест отображает координаты экранного курсора, а зеленый - интерактивной области внутри редактора сцены

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

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

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

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

Итак, что он умеет? Рассмотрим сверху вниз

График распределения времени кадра.

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

Все это добро рисуется с историей на 100-120 кадров, то есть за прошедшие пару секунд. Здесь сразу видно общую картину, если явно выделяется какая-то зона, если она стала занимать слишком много времени от кадра. Так же видны "спайки", то есть единомоментные просадки зон в определенных кадрах.

Можно навести курсор на этот график и он перестанет обновляться, отобразив картину по кадру, на который указывает курсор

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

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

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

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

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

В процессе аггрегации может получиться много зон, значительно больше того, что влазит в экран. А виджет довольно компактный, тк занимает часть экрана игры. Поэтому выводится только N зон, с самым большим временем работы. Остальные суммируются и выводятся как other.

Это работает динамически, что гарантирует что что-то крупное точно будет отображено

График основных метрик: FPS, Draw Calls, Drawn primitives, Used memory

Тут все просто, точно так же показываются последние 100-120 кадров, текущее значение, минимальное и максимальное значение на промежутке. А так же цветовая дифференциация метрик: красное - плохо, желтое - так себе, зеленое - перфект

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

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

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

Количество сущностей на сцене. В playrix у нас движок называется VSO, поэтому соответствующая подпись - VSO entities

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

В целом, большинство проблем в unity-like движках, это раздутая и не оптимизировання сцена, где каждая горошина проработана и рендерится. Нууу потому что вот так вот, потому что пофиг..

Это сразу видно в виджете и здесь так же используется цветовая дифференциация. Если метрика стала красной, то может быть это то самое проблемное место. Как в примере с долгим апдейтом UI, может оказаться что у нас много Images и Nodes.

Важно отметить, что если одна или несколько метрик стали красными - это не значит что 100% перфомансу похерело. Это стоит воспринимать как эвристику, помогающую базово понять, есть ли проблема. Если на сцене 20 тысяч нод, но FPS стабильно на 60, значит все нормально. Ведь финальная метрика - это FPS

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

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

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

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

Приложу архивчик с исходниками. Они здесь as is, то есть никакой универсальности нет, но их можно использовать как основу, чтобы сделать что-то подобное у себя

тащусь с этой прикормки 🤩

В интересное время живем! Когда я смотрел фильмы, фантастику, и там герои смотрели видео и потом такие "а теперь посмотрим с другого угла", я думал - ну и чушь полнейшая... Но вот он сайт - 4dv.ai, и в нем можно сделать именно так. Интересно, станут ли наши видео трехмерными? Или нафиг не нужно?

Поговорим про паттерны

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

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

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

Что ж, чтобы понять как правильно их юзать, нужно понять их суть, как они работают. Я бы выделил тут два аспекта:

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

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

Все это артефакты устройства нашего мозга, а точнее его ограниченности. У нас ограниченный контекст и возможность воспринимать новую информацию. Все ведь помнят как в школе/институте под конец дня новые знания превращались в кашу, хотя с утра все шло довольно легко? А еще, небольшой тест: представьте себе 10 отдельных людей, со всеми деталями и движениями. Не получится, мы просто не можем держать такой большой контекст одновременно. Обычно предел где-то около 5-6. Но вот само понятие "10 людей", без детализации, уже довольно простое

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