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

В целом ChatGPT справился, код выглядел почти нормально и очень похожим на исходный

ну да ладно, как еще можно заюзать ChatGPT чтобы упростить жизнь разработчика?

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

То же самое можно применить и к текстам. Текста ведь тоже читать муторно порой, правда? Какую-нибудь статью, рабочие документы, любую муторную херню можно упростить пропустив через ChatGPT, и затем использовать выжимку

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

Тут тоже можно использовать ChatGPT, стравив ему свой "поток мыслей" и попросив написать стройный и читаемый текст

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

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

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

но их уровень достаточен чтобы разительно снять рутину

Мысли в сторону. Честно говоря мне казалось что такое невозможно еще ближайшие годы.

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

Однако, это уже работает. ChatGPT под капотом связывает сущности, и может этим оперировать.

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

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

По сути это будущее уже здесь и сейчас, разработчики уже ищут пути как правильно это применить. Пойду попробую поисковик bing, в который microsoft уже встроил chatGPT. А еще они проинвестировали в OpenAI. Молодцы, вовремя подсуетились

Google тоже радует: https://youtu.be/6DaJVZBXETE

god bless chat gpt

немножно необычного. Квест для внимательных 😉

Поговорим о слоях и сортировке. Казалось бы, 2D графике все просто, но все же в любой игре, над которой я работал, была проблема организации сортировки:
- нужно рисовать персов, чтобы они не пересекались своими частями друг через друга
- нужно сверху рисовать UI, со своей массой слоев. А иногда и нужно рисовать персов в UI
- ребята с Unity еще скажут - "и партиклы надо запихать куда-то!!!11"

В общем, дело тонкое. Как же решать эту проблему? Как правильно, а самое главное удобно и понятно, раскладывать графику по слоям и приоритетам?

Начнем с самого простого способа - рисовать в том же порядке, в каком находятся объекты в дереве сцены. Объекты рисуются друг за другом, в порядке обхода. Для большинства случаев этого, на самом деле, достаточно. Но иногда нужно что-то нарисовать выше или ниже. Классический пример из UI - это попапы. Их удобно располагать в иерархии прямо на объекте, куда они указывают. Но рисоваться он должен как бы поверх всего, чтобы на него не налазили соседние элементы и он излишне не отсекался. Всегда возникают ситуации, когда нужно что-то сделать "повыше" или "пониже". Поэтому просто сортировать в порядке обхода иерархии не получится

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

Да и два одинаковых объекта с одинаковым набором приоритетов будут "проходить друг через друга". Представьте тех же персов, собранных из приоритетов, проходящих друг через друга. Ноги, руки, тело - все будет пересекаться между двумя персами, хотя они должны выглядеть как одно целое. В общем, для большинства кейсов такое не подходит

Можно добавить именованные слои. Каждый объект лежит на своем слое, а внутри слоя сортируется в порядке иерархии. В целом, это равносильно первоначальному обходу иерархии, просто проблемы локализуются на уровне слоев. Уже проще, но все же не идеально

На мой взгляд самая правильная система - это комбинирование всех. В ней есть слои, и первоначально задан их порядок. Один слой ни при каких обстоятельствах не может "залезть" на другой слой. Затем по-дефолту все сортируется в порядке иерархии, тк в большинстве случаев это и нужно. И для отдельных кейсов задается числовой приоритет, который как бы "вытаскивает" объект из иерархии, и сортирует в рамках слоя в зависимости от его приоритета. У дефолтных объектов приоритет 0, таким образом можно что-то сделать ниже, а что-то выше

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

У меня уже давно была идея сделать два режима отображения иерархии в сцене: реальная иерархия и очередь отрисовки. Собственно, почему бы не вывести дерево очередности отрисовки камер, слоев и объектов там? К тому же, через drag'n'drop это очередность можно будет редактировать. Захотел поменять слой - перетащил объект в нужный слой. Захотел чтобы он был в подиерархии другого объекта - просто перетащил. И мгновенно увидел результат, дерево с порядком отрисовки сразу поменялось и ты видишь актуальный результат

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

Окошко еще не финальное, но уже вполне получается проверить концепцию.

Цветом выделены разные батчи, цифра справа - числовой приоритет, если задан. В руте показаны камеры (на скрине не видно), под каждой камерой - список слоев, которые она рендерит. В слое объекты и их дети. Выглядит все просто и понятно. А главное drag'n'drop интуитивен: ты хочешь чтобы объект рисовался в определенном месте - просто перетаскиваешь его туда

Расскажу о демке и о том, над чем сейчас работаю уже в течение последних 3х месяцев

Сейчас я интегрирую о2 в чужой движок.

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

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

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

Собственно сейчас я работаю над интеграцией о2 в чужой движок. На самом деле он уже интегрирован и сейчас идет работа над оптимизацией. Оптимизация довольно интересная, как и тот продукт, над которым я работаю. Это - гемблинг, игровые автоматы проще говоря, на стареньком железе с 10-ти летним 32битным ARM, линуксом под капотом и ультра-дерьмовой видеокартой.

Сейчас все на этапе эксперимента, попробовать интегрировать о2 в их движок и добиться приемлемого перфоманса на их железе. Это позволит им делать игры быстрее, верстать графику в редакторе. А скрипты на JS помогут в портировании игр под WEB. В общем, почти мгновенная прокачка тулсета студии за счет внедрения о2

Этап интеграции прошел относительно быстро. Пришлось научить все компилироваться вместе, разрулить зависимости в CMAKE, да и собственно перевести о2 на CMAKE. Поддержать платформенные API под линукс и OpenGLES. Поправить ошибки gcc (скажите мне про кросс-компиляемость С++ ага). Основная работа связана со специфичным железом, компиляцией под него и значительной переделкой рендера.

Видюха там и правда слабая и привередливая. Например, очистка стенсил-буффера, который ты даже не юзаешь, может дать +20 FPS. До сих пор идет поиск всех крупиц, неочевидно съедающих перфоманс. Правильная запись в буффер вершин, сжатие DXT, все что угодно может влиять. Отличный способ прокачать свои знания в графике

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