Я не очень люблю разработку под Андроид и причины тому две: опенсорс и OpenGL.

Начнем со второго, потому что это более древнее зло. Как известно, OpenGL - это стандарт. Все, что вне его описания уходит либо в расширения, либо реализуется, как это считает нужным вендор. Расширения как бы тоже стандаритизированы, но вот их использование не является обязательным, а всего лишь рекомендация. Даже если вендор - это Google, а Google - это один из ключевых участников Khronos, совершенно не факт, что расширение будет на каком-нибудь Pixel-е. Поэтому лучше их вообще не использовать. Ну или обмазаться кучей проверок (на одной работе была отдельная ветка кода под `if (IE6)` - видимо тут так же надо - да, именно так и надо, к сожалению).

С Vulkan-ом +/- все то же самое, только еще и кода в 100500 раз больше приходится писать просто, чтобы его инициализировать - напоминает старый DirectX.


Теперь к опенсорсу. Казалось бы, что плохого, что не нашлось в документации - найдется в коде. Как бы да, если вы пишите исключительно под Pixel. Но у нас же есть еще Xiaomi, Samsung, Huawei и прочие. И у каждого свой форк Андроида. И к их коду, как правило, доступа нет (если есть - поправьте и покажите, где оно лежит). В итоге по документации и гугловому коду оно должно работать, а по факту - держи рандомный код ошибки и сообщение, и сиди кури мануалы по железу, чтобы понять, что же там не так - иначе я хз как это понять.

И это я, слава богу, сижу достаточно далеко от гуи - по большей частью за JNI даже. Что там на гуе - боюсь представить. Хотя нет, не боюсь - на прошлой работе был проект под Андроид гуйный, и мы там намучились с доступностью, потому что она, опять таки, у всех вендоров (не) работает по-разному.

Что-то случилось: сошлись звезды или планеты выстроились в ряд - но у меня наконец поженились GarageBand и Orca.

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

А если у вас есть MainStage (или еще что-то, позволяющее вешать разные миди каналы на разные инструменты), то можно делать вещи еще интереснее и писать сразу для ансамбля.

Нашел, куда с пользой на практике применить процедурную генерацию - буду пилить мод для Террарии, потому как задолбала меня там рутина типа копания туннелей.

Ну и всякие биомы можно нагенерить через SDF необычные.

Пока сделал рисование этих самых тоннелей))

https://youtu.be/hHqi1CUbclM?si=v5QUkOczd2DOm2TF

Записали с товарищем очередной бухтеж.

Если кому есть что интересного обсудить/рассказать/поговорить на тему вокруг разработки, программирования, математики. графики и процедурной генерации - пишите, обсудим

https://machinelearning.apple.com/research/illusion-of-thinking

Кто бы мог подумать 🍿

Вроде яблоки анонсировали интересного про Metal, AVP и ML. Проснусь - посмотрю, что там.

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

Liquid Glass

Пока три вопроса
1. Сколько оно жрет батареи на все эти эффекты стекла?
2. На эффекты жидкости оно SDF использует или ручками через безье фигуры строит?
3. Сколько теперь страдать дизайнерам и фигме?

Foundation model

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

Сделаю однажды на этом полностью процедурно генерированную RPG, если оно будет работать.

Metal4

1. Меньше оверхеда и жонглирования энкодерами
- Блит и компьют теперь просто компьют
- У рендер энкодера можно переключать аттачменты (фреймбуферы) на лету в энкодере
- новый MachineLearningEncoder

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

3. Улучшенная синхронизация (?)

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

5. Интеграция ML наконец
- добавили тензоры (раньше были только буферы и текстуры)
- новый MachineLearningEncoder
- CoreMLPackage -> MetalPackage->энкодер
- расширения для Metal Shading Language для поддержки всего этого

6. В MetalFX добавили плюшек
- апскейл (было и раньше)
- интерполяция кадров
- денойз для рейтрейсинга

7. Можно мешать старый и новый с помощью MTLEvent

Возможно, что-то пропустил. Детали будем смотреть в доках и следующих сессиях.

В дебагере Метала обещают вот такую тулу для отладки нейронок - прям красивое

К вопросу liquid ass. Недавно на одном проекте делал такую линзу для просмотра значений пикселей. В данном случае - индексированная гифка

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

В итоге сделал мод [WdF] Tools - он опубликован и в нем аж целый один инструмент, который крафтится из куска земли и умеет рыть тоннели между двумя точками.

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

https://youtu.be/_UxxJg10GDE

Сделал вводное видео про мод. В целом, там все просто, но мало ли.

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

Автоматизировал постройку коридоров.

Для этого я держу поле с ячейкой 5х5 тайлов, где помечаю, построен там коридор или нет. Это нужно по нескольким причинам:
1. Коридоры всегда выровнены по сетке
2. Не нужно перепердоливать созданнаю ячейку (по крайней мере в данной сессии), то есть если вы там что-то руками поменяете, оно останется
3. Оно мне нужно для постройки границ коридора (блоков вокруг)

Как строятся границы:
- для всех измененных ячеек я беру нулевых соседей
- для каждого соседа строю маску, как расположены соседи вокруг
- в зависимости от маски ставлю блоки

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

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

Недавно столкнулся с проблемой кодирования 4к видео на Андроиде (на iOS жалобы не поступали) - у него пячится цвет:

Проблема возникает из-за разных цветовых стандартов исходного и экспортируемого видео. На входе у нас BT.470, на выходе BT.709 (зеленоватое) или BT.2020 (красноватое).

Даже если мы выставим руками BT.601 (тот же BT.470 математически), то аппартаный энкодер поставит обратно в BT.709 (или BT.2020 в зависимости от вендора) для 4к видео, потому что BT.601 не поддерживается для таких размеров. Также мы могли бы руками править цвет, но для этого нам нужно знать входной формат, а средствами андроида это получить невозможно - он нули возвращает.

Поэтому будем тащить ffmpeg и ручками пячить цвета.

Немного контекста: эти стандарты по сути определяют матрицу для перехода YUV<->RGB и пришли из телевидения. (вот про 601 например)

Почему у Андроида такая всратая тула для дебага видюхи? Из официального я нашел только Android GPU Inspector (AGI), и это шайтан-арба мало того, что работает не только лишь на всех девайсах (про симулятор молчу), так еще и на них - через раз, падает, не может захватить кадры и прочее.

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

Если вы знаете, что есть для Андроида кроме AGI - скажите, ибо задолбало меня это чудище.

Подсказали армовскую тулу https://developer.arm.com/Tools%20and%20Software/Graphics%20Analyzer

По сравнению с AGI сильно удобнее и, самое главное, работает на всем моем небольшом зоопарке.