Далее я старался уже "обточить болванку" до нужного состояния. Что-то, что попроще и побыстрее сделать самому - делал сам.

Например, удалял ненужное. Но один раз мне нужно было удалить пачку ненужных методов "чутка подумав": нужно было удалить работу со стейтами виджета при клике и наведении курсора. При этом работу со стейтом раскрытия нужно было оставить. Ох, еще подумал уточнить это в запросе, но не стал. Не нужно ведь делать то, о чем тебя не просили, правда же?

Конечно же под нож попала и работа с opened стейтом...

Ах ну и да, с этим получилось плохо (( Удалил, спасибо конечно брат, но нахера мне эти комментарии я не знаю

Еще одну вещь подметил, относящуюся скорее лично ко мне. Я сам по себе довольно быстро работаю (порой в ущерб качеству, буду честен), и для меня набрать 400-500 строк кода довольно просто. Поэтому для меня некоторые вещи банально быстрее и проще сделать самому, чем запросить это в GPT. Но я точно знаю что не все такие, и кому-то этот эффект внешнего помощника будет давать бОльший эффект

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

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

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

Попробуем подвести итоги.

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

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

Дополнительно отмечу что я сидел в двух IDE Одновременно - MSVS и Cursor. Это мягко говоря не удобно, а переучиваться на VS Code (коим по факту является Cursor) сходу сложновато. Нужно настраивать окружение, учить новые хоткеи, да и честно сказать по функционалу он похуже чем MSVS + Visual Assist X. В идеале бы иметь такой инструментарий прямо в MSVS. Оно есть вроде бы как, но у меня все разваливалось при любых попытках что-то поменять через чат

Теперь циферки!

Изначально GPT сгенерил мне 860 строк кода, поверх них пришлось сделать 490 строк изменений. По количеству измененных строк получается что я переработал 55% кода, то есть тот самый code acceptance получился 45%. Забавно, что ранее я "на чуйке" предположил что мне cursor дает буст где-то в 40%, получилось довольно близко. Стоит понимать что почти все 45% - это то что было сгенерено в первом запросе, при генерации болванки. И это самый тупой и рутинный код, который остался. Везде, где была реальная логика виджета - все переписано. Местами вручную, местами через запросы в чат

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

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

Редактор стейт мешины уже похож на что-то нормальное. Забавно, на него я уже убил х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 кадров, текущее значение, минимальное и максимальное значение на промежутке. А так же цветовая дифференциация метрик: красное - плохо, желтое - так себе, зеленое - перфект

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

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

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