233

THE ONE CUBE. Дневник разработки. Ноябрь '25

Серия THE ONE CUBE

Коротко — как я уперся в потолок железа на 20 FPS, снова обломался с зарубежными знаменитостями, внезапно получил репост от AlexGyver и оформил основу своего рендер движка.

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

Пристегнитесь, это был тот еще месяц.


Глава 1. Погружение в оптимизацию и битва за каждый FPS: фризы, гонка данных и потолок железа.

1-11 ноября.

Начало месяца прошло под знаком войны за производительность. Каждый шаг в разработке кубика упирается в нужду в глубокой оптимизации. Вроде бы в ESP32 есть целых 8MB "быстрой" памяти (PSRAM), но ее реальная скорость — всего около 20MB/s при стандартных настройках. Когда нужно на 6 экранов протолкнуть данные (а это по 112 КБ на каждый кадр, итого почти 700 КБ каждую долю секунды), мощный процессор вместо полезных вычислений начинает заниматься тупым переливанием байтов.

Поначалу я пытался решить это с помощью нейросетей, объясняя им свои идеи про параллелизм. Но как спросишь, так и получишь — ИИ выдавал полурабочий код, и стало ясно: придется самому, по старинке, разбираться с семафорами и мьютексами.

И это дало первые результаты. Сделал класс для перелива данных в фоне и запустил имитацию тяжелых расчетов : последовательное выполнение (перелив + математика + рисовка) дало 15 FPS. А вот параллельное (заливка в фоне + математика + ожидание) — уже 18 FPS на ВСЕХ шести экранах. Уже что-то. Процессор чилил и ждал, пока зальются буферы, а значит, в это время он мог делать что-то полезное.

Следующим шагом стало копание в настройках железа. Оказалось, что можно поднять скорость копирования памяти почти вдвое, с 18 до 40 MB/s! Это был прорыв. Судя по замерам, показ на всех 6 экранах теперь выдавал 25 FPS. Забавно, что этот микроконтроллер для DIY-поделок превращается в карманную игровую машину.

Прикрутил чтение PNG-файлов для фонов и спрайтов с хромакеем и запустил тест с бегающими картинками.

Но радоваться было рано. Появились небольшие фризы и вообще началась “гонка данных” — некоторые экраны, похоже, получали не те данные, показывая артефакты. Вдобавок, один из экранов начал подтормаживать, видимо из-за длинного сигнального провода. Пришлось снижать настройку размера пакетов данных на экраны.

Да, я знаю, что “стабильные 20 FPS” в 2025 году звучит как начало плохого анекдота. Но для микроконтроллера ESP32, который в реальном времени перезаписывает картинку на шесть экранов, это та самая маленькая инженерная победа. А для экспертов по Crysis на калькуляторах — отличная тема для комментариев =)


Глава 2. От хаоса к системе… и обратно. Архитектура, сложность математики и рождение основы рендер движка.

7-26 ноября.

Пока шла борьба за FPS, я параллельно пытался превратить хаос в коде в осознанную систему. Начал разделять код по файлам, выносить константы, все по фэн-шую. Добавил обработку TTF-шрифтов, которые библиотека сама переводила в 4-битный растр.

И в какой-то момент я понял, что то, что начиналось как драйвер для железа, превратилось в нечто большее. После долгих мучений с архитектурой, конечными автоматами (привет, универ!) и руганью с нейросетями, я наконец-то собрал рендер-движок v0.1. Это уже полноценная система на десяток классов.

Вот первая анимация на полном движке. Не особо зрелищно, но оно работает.

Но путь к движку был тернист. На нем меня поджидала «Змейка»… и ее проклятая математика. Прикрутить текстурки к змейке было легко, а вот заставить их правильно поворачиваться на изгибах — оказалось не простой задачей. Я, понадеявшись на ИИ, раз 20 получал от него разные формулы поворота, и каждый раз получал какую-то дичь. Придется снова, как в старые добрые времена, обклеивать куб бумажками и выводить все формулы вручную.

А потом, проверяя, сколько RAM жрет “Змейка”, увидел, что на некоторых этапах съедается почти вся память! Ее всего-то 270 КБ в сумме. Оказалось, PSRAM нельзя напрямую отправлять на экраны, данные все равно сначала копируются в основную RAM память. Пришлось снова переписывать ядро драйвера экранов.

Еще поколдовал с паралелелизмом. PSRAM конечно прям достанется =)
Все функции в коде её хотят и дерутся за неё. В общем, всё та же цифра в 18-20 фпс это потолок.


Глава 3. Маркетинг: погоня за звездами и неожиданный успех

5-20 ноября

Иногда от программирования ядра тошнит. Хочется не на буковки и циферки смотреть на экране компьютера, а делать шоу. В ноябре продолжил свой принципиальный квест: достучаться до Viva La Dirt League. Reddit забанен, мейл они не читают. Пришлось делать не по изначальному плану: создал комиксы про них и начал бомбить сторисами с отметками всех актеров. Результат: один из топов глянул и… промолчал.

Пост об VLDL: THE ONE CUBE. Как игральная кость.. Почти =)

Провал с VLDL меня не остановил. Я переключился на Critical Role, у которых как раз намечалась премьера нового сериала. План тот же: комиксы, видео с кубиком, отметки. И снова — полная, оглушительная тишина. Никто из топов даже не посмотрел.

Пост о Critical Roll: The One Cube // Трибьют Mighty Nein — Critical Role теперь в кубике

НО, внезапно, алгоритмы соцсети бустанули мой пост с комиксом))

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

План был простой:

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

  2. Доставить это в комментарии к главному в ру-сегменте DIY-блогеру, AlexGyver.

Расчет оправдался на 100%. Ему зашло, и он репостнул видео к себе в канал.

Вот это видео и сам репост, на память.

На этой волне я завел блог на DTF и начал перезаливать старые посты. Результаты скромнее (пост про змейку набрал 2.8к просмотров против 35к на Пикабу), но радует, что в комментариях писали: «У Гайвера видел такой кубик». Узнаваемость работает =)


Глава 4. Маркетинг: партизанские идеи, провалы и халявные канапешки

21-24 ноября

Кроме онлайн, надо выбираться на живые встречи с людьми. Впереди Игрокон Lite 2026.

Я написал организаторам с предложением о сотрудничестве — описал свой уникальный проект, и предложил сделать что-то крутое с их брендинком. В ответ пришла отписка, суть которой сводилась к простому: “С вас 15 000 рублей за стол и стул на ярмарке”. Что ж, это было ожидаемо. Видимо, инди-разработчик с уникальным железом менее интересен, чем продавец акриловых дайсов.

Чтож, будет партизанский маркетинг =) Я приду как обычный участник с тремя кубами, в гавайской рубашке Томми Версетти и с кучей 3D-печатных сувениров (и не только). При тряске куба можно будет получить подарок. Посмотрим, кто соберет больше внимания — стол за 15к или энтузиаст с горящими глазами =)

А вот другая выставка, на которую случайно попал в ноябре, стала отличной тренировкой перед Игроконом. Тренировкой провала. Я со своими технологиями абсолютно не вписался в тусовку художников и фотографов (выставка была о народном творчестве в нашем городе). За весь вечер подошло всего пара человек. Но есть и плюсы: я понял, насколько важно правильно выбирать целевые мероприятия, и объелся халявными канапешками. Опыт, пусть и такой.


Глава 5. Рождение игровых механик: от “гачи” к “Алхимслоту”

15-29 ноября

Весь месяц не только боролся с железом, но и пилил то, ради чего все затевалось — игровые механики. Началось все с переделки “гача-игры” (показ случайных картинок при тряске). И тут же я столкнулся с багом: датчик движения срабатывал через раз. Ни одна нейросеть не смогла найти ошибку в логике. Пришлось снова вспоминать универ и переписывать класс акселерометра на конечном автомате. Теперь все заработало как часы.

Вот так теперь выглядит “гача”: при тряске — “рубашки”, после — анимация смены картинок. Для красивых роликов даже собрал целый натюрморт с игральными костями, бусами и перьями.

Перенос “гачи” на новый движок открыл простор для экспериментов. Так родилась слот-машина: пока трясешь — барабаны крутятся. Можно даже останавливать их резким наклоном. Куб учит обращаться с ним аккуратно: от легкой тряски все медленно движется, а можно раскрутить и пытаться остановить в нужный момент. Это уже не просто “потряс-посмотрел”, а тактильный игровой процесс.

Не "лимонные" картинки ниже, это идея тематики под Utopia Show. Чуть позже планирую доработать стиль иконок, и также отправить как и для AlexGyver.

А потом я пошел дальше и сделал “Алхимслот”: барабаны не просто крутятся, а картинки на центральной линии могут смешиваться, образуя новые. Из этой механики можно придумать кучу игр, начиная с классической «Little Alchemy 2». Вот где кубическая форма начинает раскрываться по-настоящему =)


И вот тут я прямо слышу, как эксперты из комментариев уже набирают сакраментальное: “Автор, все это можно сделать на телефоне! Зачем этот куб?”. И знаете что? Они абсолютно правы. Конечно, можно. На телефоне можно сделать и змейку, и слот-машину, и алхимию.

Более того, они добавят: “В телефоне тоже есть гироскоп, его тоже можно наклонять и трясти!”. И снова будут правы! А теперь, ради эксперимента, попробуйте взять свою 6-дюймовую “лопату” и начать ее резко дергать в руках, как я это делаю с кубом на видео. Попробовали? Чувствуете, как этот стеклянный бутерброд за 50+ тысяч рублей так и норовит вылететь из руки и разлететься на атомы?

В этом и есть разница. Телефон — это прямоугольный, плоский и хрупкий инструмент для связи, который можно заставить делать что-то еще. А куб изначально спроектирован, чтобы его крутили, трясли и даже роняли (он уже летал со стола, все работает). Это как сравнивать езду на городской малолитражке по бездорожью и на специально подготовленном багги. Обе машины поедут, но опыт, комфорт и результат будут совершенно разными.

Этот проект — не про “сделать то, чего нет на телефоне”. Это про “сделать то же самое, но получить совершенно другой, физический и тактильный опыт”. Про то, чтобы держать игру в руках, а не бояться уронить свой основной инструмент для жизни, пытаясь им играть).


Итоги месяца

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

Что получилось:

  • Выжать максимум из железа: Стабильные 19-20 FPS на 6 экранах — это мой личный потолок для этой версии железа. Больше — только с новой архитектурой или другим контроллером.

  • Создать фундамент: Рендер-движок v0.1 — это огромный шаг вперед. Теперь вместо набора разрозненного кода у меня есть основа системы, на которой можно строить игры.

  • Получить “знак качества”: Репост от AlexGyver — это не просто хайп. Это подтверждение от авторитета в индустрии, что идея интересна целевой аудитории.

  • Нащупать новые механики: Слот-машина и “Алхимслот” — это не просто тесты, а уже почти готовые концепции игр, которые родились из экспериментов.

Открытия месяца (или то, что я снова понял):

  1. ИИ — не волшебная палочка. Он хорош для рутины, но когда дело доходит до сложной логики (как с поворотом текстур у змейки) или архитектуры, он тупит и выдает дичь. Думание своей головой и бумажка в клетку все еще надежнее.

  2. Прямой штурм крепости не работает. Погоня за VLDL и Critical Role была похожа на кавалерийский наскок на стены замка. Я получил ценные данные: этот канал коммуникации с ними не работает, по крайней мере, пока. Это не значит, что дверь закрыта навсегда. Это значит, что для следующего штурма понадобится осадная башня, а не просто громкие крики под стенами. Либо удача // обходной лаз в замок.

  3. Персональный подход бессилен, если цель недосягаема. Усилия по созданию кастомного контента для зарубежных миллионников ушли в пустоту, потому что достучаться до них почти невозможно. Тот же подход сработал с Гайвером, потому что он — часть живого комьюнити, а не закрытая корпорация. Вывод: выбирать нужно не только метод, но и реалистичную цель.

  4. Тщательно выбирать правильные мероприятия. Провал на выставке художников — отличный урок.

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


Предыдущие посты:

THE ONE CUBE. Дневник разработки. Октябрь '25

THE ONE CUBE. Дневник разработки. Сентябрь '25

LED CUBE. Дневник разработки. Август '25


P.S. Спасибо, что дочитали! Каждый ваш комментарий, даже самый гневный, помогает проекту двигаться вперед. Следить за разработкой в режиме реального времени можно в моем TG-канале, там я появляюсь каждый день.

https://t.me/andreibesarabchannel

Инженериум DIY

571 пост5.4K подписчика

Правила сообщества

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

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

5
Автор поста оценил этот комментарий

Вот вообще ничего не понятно. Зачем этот кубик? С 6ю мать его экранами? Чего с ним делать то? Кнопок нет. Трясти его? За чем. Ну потряс, ну поменялось что то там на милипизерных экранах. И что. Нафига это. Короче как в старой поговорке, ничего не понятно если бы мы знали для чего это но мы не знаем. Но вот вообще не понятнятная хрень.

раскрыть ветку (1)
4
Автор поста оценил этот комментарий
Иллюстрация к комментарию
13
Автор поста оценил этот комментарий

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

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

С точки зрения маркетинга, ИМХО, почти провальный продукт.
С момента прошлого нашего разговора, закинул вопрос об этом кубике всем своим знакомым днд-шникам. Реакция была достаточно предсказуемая - "Вау, прикольная штука. Купить? *мыслительный процесс* Мне оно нафиг не нужно". Вариант покупки даже не стали рассматривать, как подарок приняли бы и оставили на полочке пылиться.
Народа фанатично залипающего в игры, на разных платформах, у меня не так много, всего пару человек, но реакция тоже была +/- одинаковая - "Красивое, но нафига оно? Что там есть уникального?". Хотя концепт змейки по всем граням заинтересовал, но не до уровня приобретения отдельного девайса. В подарок бы приняли и попробовали бы поиграть. Даже больше, спросили не я ли делаю и хотели пощупать змейку.
Гача концепция заинтересовала днд-шников, в качестве генератора предметов, но сразу возникло много вопросов "А можно ли сохранить предмет? А можно ли настроить свой список предметов и частоту выпадения?", но это от игроков. Мастеров не особо заинтересовало, мне рассказали о куче каких-то приложений и сайтов, которые заточены на ведение днд и сохранении локаций и прогресса.
Получил пригоршню советов по расширению функционала, но он явно не в масштабах возможностей ESP.

Больше я такие опросы проводить не буду, ну его нафиг, печень не выдержит ))

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

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


Поэтому будет мировая система координат для объектов, которые уже будут транслироваться на физические экраны. И как раз получается будет две системы - замкнутая по кубу (через кватернионы) и плоская развертка по кресту большой карты.


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

Поэтому была выбрана простая система полного обновления экрана, как быстрый и максимально рабочий способ.


Благодарен вам, что вы рассказали про кубик знакомым. И их реакция ожидаема. Всё равно что рассказывать какой вкусный стейк по его картине на выставке.

По гаче концепции было бы интересно узнать полный список вопросов.

Пока что на эти я отвечу, что всё можно настроить. Главное мне бы понимать, что именно хочется игрокам.


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


И интересно, какое расширение функционала хотели. 3D проц явно не потянет, но те задачи что обычно в днд, мне кажется справится.


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

показать ответы
0
Автор поста оценил этот комментарий

На какую пал выбор и в результате правильный ответ?

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

https://platform.parallel.ai/


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

2
Автор поста оценил этот комментарий

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

"хорошая тема, но это надо еще потратить пару недель" - гугли алгоритмы отрисовки старых игр и нейронки в помощь, не думаю что это займёт столько времени ))
Полное обновление экрана, очень кратно жрёт ресурсы. Этот вопрос решили и оптимизировали еще в эпоху 286-486 IBM'ов и первых консолей.

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

Народ видит, в этом варианте использования кубика, использование его как дополнения, а не как основной девайс. Их хотелки можно реализовать и без отображения данных на кубике, достаточно просто запихнуть гироскоп с блютус и аккумом в небольшой кубик, ну или ограничится одним дисплеем и тряской кубика. Но тогда, опять же, мы приходим к вопросу "Зачем кубик? Проще запихнуть в смартфон", который может перекрыться только желанием игроков похвастаться вещью и приобретением кубика мастером, дабы реализовать это желание игроков. Дальше всё зависит от мастера, готов ли он вложить в это деньги или игрокам не лень будет показать всем экран своего смартфона на котором будет картинка предмета.
Не забываем о том, что потом будет по ночам икаться о кривом рандоме, таже если он будет идеальным, ведь все неудачи будут адресованы именно в сторону ПО, а не на бросающего обычный кубик d20 ))
Т.е. их заинтересовала визуализация получения вещей, а не основной функционал кубика ((

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

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

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

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Спасибо за такой развернутый ответ и за “полевые испытания”! Фидбэк просто золото.


Реакция людей абсолютно логична. Они видят гаджет и пытаются встроить его в свои привычные сценарии. А весь сок как раз в тех механиках, которые сейчас невозможны — например, совместные QTE-действия для всей пати. Но это надо показывать, а не рассказывать.


Идеи про кастомизацию лута и приложение для мастера — это 100% то, куда всё и движется. Так что спасибо, что подтвердил мои догадки =)


За идею с тамагочи отдельный респект, это прям самостоятельный классный проект.

показать ответы
2
Автор поста оценил этот комментарий

Ты крут! Мне видится одна загвоздка во всем этом: когда доведешь свой проект до коммерческого уровня (а ты доведешь, не сомневаюсь), кто игры клепать на него будет? Прелесть ведроида в том, что каждый второй может сесть, написать какую-то хрень и вывесить в гуглмаркете. И это скачают и установят без пляски с бубном. У тебя же крайне специфическая платформа выходит, которой владеешь только ты, а в одиночку много не напишешь, к сожалению. PS даёшь D20 )))

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

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


В котором надо только выбирать блоки, заполнять свойства и привязывать картинку. Далее конструктор это экспортирует в json + картинки, и кубик это хавает как игру =)


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

И конечно сделать сайт, куда можно будет выкладывать игры и их скачивать.


В предыдущем посте я упоминал, что куб подключается к компьютеру как карточка памяти. Скачал игру с сайта, закинул на куб в папку "games", а лаунчер её подцепил.


P.S. Проект начинался как идея кубика D20, который подсвечивает выпавшую грань светодиодом. Но D20 сделать физически невозможно, а вот D6 вполне. При этом этот кубик может выдать на экране случайное число хоть D100 =)

показать ответы
4
Автор поста оценил этот комментарий

Стабильные 19-20 FPS на 6 экранах

а надо ли одновременную работу всех 6 экранов, ещё и с одинаковым фпс, если игрок физически больше чем на 3 сразу смотреть не сможет?

раскрыть ветку (1)
2
Автор поста оценил этот комментарий

Вы правы, 6 одновременно почти никогда не нужны (если конечно игра не предусматривает быстрой прокрутки устройства). Но 4 — очень часто. Это центральный, верхний и два боковых. Это основное игровое поле, которое должно быть активным. Если это настолка на несколько человек за столом, то и задний экран становится важен для другого игрока. Поэтому потребность в 4-5 активных экранах есть.


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


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


Так что да, стабильные 20 FPS на 6 экранах — это скорее стресс-тест и демонстрация возможностей. В реальных играх ресурсы будут распределяться гораздо умнее.

0
Автор поста оценил этот комментарий

Какую конкретно нейросеть использовал?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

обычно gemini / claude для кодинга и повседневных задач, parallel ai для поиска в интернете

0
Автор поста оценил этот комментарий

интересная задумка!) подписался на вас) а в продаже еще не появилось?)

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Спасибо =)


В продаже оно будет тогда, когда на одном кубике будет как минимум штук 5-7 хороших разнообразных игр. И система удобной загрузки нового контента. А до этого ой как далеко.


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

показать ответы
0
Автор поста оценил этот комментарий

на одном канале spi дисплеи сидят или каждый на своем?

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

2 канала по 3 дисплея. На большее там не хватает пинов и интерфейсов))

3
Автор поста оценил этот комментарий

нейросеть спроси) поколение готовых решений)

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

сейчас спросил самую мощную. оно выдало мне готовое решение =)

показать ответы
2
Автор поста оценил этот комментарий

а ты хотел готовое решение?

попробуй математику для сферы, разделённой на сектора. единственное, у тебя полюсов нет.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

да, хотел готовое решение =)

показать ответы
0
Автор поста оценил этот комментарий

таки чего там? 20 фпс - всё ещё потолок?)

мне правда интересно

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

на 6 экранов железо физически больше не может.

0
Автор поста оценил этот комментарий

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

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Благодарю за совет. И кстати, эта идея по оптимизации экранов уже была предложена ранее и обсуждена с другими комментаторами под текущим постом.

показать ответы
0
Автор поста оценил этот комментарий

херня какая-то.

статья от нейросетки, код от нейросетки, картинки от неё же, поди (или честно спиздил?)

20 ФПС - это реально твой потолок.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Какое точное наблюдение! Так же, как путешественник летит на самолёте, а не пытается переплыть океан на плоту, чтобы сделать это “по-настоящему”.


А что до 20 FPS — вы правы, это потолок. Для этого железа. И я этим горжусь, потому что знаю, чего стоил каждый из этих кадров.

показать ответы
0
Автор поста оценил этот комментарий

А что за дисплеи-то хоть?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Так а смысл там кадры обновлять если картинка статичная?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Возвращаемся к изначальной теме. Динамика на кубике - максимум 20 фпс. И никаких статичных картинок.

показать ответы
0
Автор поста оценил этот комментарий

Ну вот, т.е. сам один дисплей уже 20 фпс потолок имеет на 80 МГц шине? Верно я понял? Или всё же это не потолок для него?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Если просто выводить картинку на дисплеи без всего остального (логика, математика, перезаливка фона и тд), то оно может около 25 фпс. Но тогда это будет просто фоторамка =)

показать ответы
0
Автор поста оценил этот комментарий

Да не нужно так расписывать :) вы как нейронка :)

Я понимаю суть, 80МГц на SCK это максимум для ESP32, для дисплея тоже?

Сколько FPS может выдать один дисплей?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

В текущих реалиях 19-20 на каждом экране, если включать все 6.

да, 80мгц максимум.

показать ответы
0
Автор поста оценил этот комментарий

Ну или нет

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Спасибо за постоянное внимание к проекту! Рад видеть вас снова.

0
Автор поста оценил этот комментарий

Ну значит если есть мощь МК, может создать по типу своего SPI, или портов не хватает? Там вы сказали два аппаратных. Какая тактовая частота у sck?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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


1) Протокол жестко задан: Внутри каждого экрана стоит свой контроллер (драйвер), который аппаратно “запрограммирован” понимать только один язык — протокол SPI. Мы не можем “придумать свой протокол”, точно так же, как не можем заставить FM-радиоприемник ловить Wi-Fi. Это физическое ограничение самого экрана.


2) Скорость имеет предел: И ESP32, и контроллеры дисплеев имеют максимальную частоту SPI, выше которой они физически не могут работать (в моем случае это 80 МГц на канал). Просто “захотеть” передавать быстрее, увы, невозможно — это предел самого кремния.


3) Используется самый быстрый метод: Чтобы достичь этой максимальной скорости и не тратить процессорное время, я уже использую самый быстрый из существующих методов — передачу данных через аппаратный модуль DMA напрямую в аппаратный SPI. Процессор в это время свободен. Любая программная реализация была бы в сотни раз медленнее.


4) Все каналы уже заняты: У ESP32 всего два аппаратных SPI-канала, которые можно эффективно использовать для такой задачи. Оба у меня уже задействованы.


То есть, система уже работает на абсолютном максимуме своих аппаратных возможностей. Ускорить ее можно, только полностью сменив платформу и архитектуру.

показать ответы
0
Автор поста оценил этот комментарий

У меня только два глаза, как я могу насладиться всеми шестью экранами?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Смысл не в том, чтобы видеть их все сразу, а в том, чтобы взаимодействовать с кубом как с цельным 3D-объектом. Мир на нем бесшовный.

0
Автор поста оценил этот комментарий

Так ESP32 этож 32 битный камушек, нет?

Я могу ошибаться сильно, но он за так вычисления оперирует 32 битами.

А картинка у вас на одном дисплее RGB 8bit, которую думаю даже можно ужать до 7bit и никто не заметит.

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

Я думаю тактовой частоты микроконтроллера должно хватить, чтобы вычитать переменную, разложить на RGB и впихнуть в матрицы.

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

Опять же, может посмотреть в сторону оптимизации видеоядра?

Вв пытаетесь упихнуть все дисплеи на одно ядро. Но что если для каждого дисплея сделать свой камушек, который будет отвечать только за один дисплей. Между камушками организавать связь. Чтобы синхронизировать кадры. И вот вы уже добились большей производительности чем в 20 фпс. Тем более esp32 вроде не такие дорогие камни.

Какой там протокол у дисплеев? SPI какой-нибудь? Или что-то своё?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Вы правы, ESP32 — 32-битный, и это дает много возможностей.

И вы затронули несколько очень интересных моментов.


Про цвет: Вы почти угадали. Думаю, вы имели в виду 24-битный формат RGB888 (по 8 бит на канал, >16 млн цветов). Я же использую 16-битный RGB565 — это “золотой стандарт” для embedded.

В нем 5 бит уходит на красный, 6 на зеленый и 5 на синий. На практике это дает 32 градации красного, 64 градации зеленого (к которому глаз наиболее чувствителен) и 32 градации синего — итого более 65 тысяч цветов.

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


И ваша идея про упаковку абсолютно верна — эти 16 бит как раз и лежат в одной переменной. Так система и работает «под капотом».

Про архитектуру: Идея с отдельным контроллером на каждый дисплей очень интересная с теоретической точки зрения. Но на практике это, к сожалению, создаст больше проблем, чем решит: энергопотребление и цена вырастут в разы (если вообще удастся запихать 6 камней в одно устройство размером с половину ладони), а синхронизация 6 контроллеров внутри одного куба — это задачка посложнее, чем просто отрисовка (привет wowcube с 8 процессорами и 24 экранами).


Про FPS: Текущий FPS в 20 кадров достигается как раз на одном ESP32, который по 2 шинам SPI работает сразу со всеми шестью экранами. И узкое место тут — сама скорость шины (~8MB/s на канал), а не вычислительная мощность ядра.


Но в любом случае, спасибо за новый взгляд

показать ответы
0
Автор поста оценил этот комментарий

Супер, дальнейших успехов в развитие проекта

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

спасибо =)

0
Автор поста оценил этот комментарий

а герцовку spi не повысить? пока передается надо следующий кадр уже готовить

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Там всё работает на пределе железа

показать ответы
0
Автор поста оценил этот комментарий

Зачем рисовать на 6 экранах, если 6й всегда внизу и его не видно? Можно оптимизировать, гироскоп же знает, где верх

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Оптимизация это следущий шаг =)

0
Автор поста оценил этот комментарий

Одновременно 6 экранов куба видеть нельзя. Может стоит максимальный ФПС держать только на видимом, поменьше на боковых и совсем низкий на заднем экране? Возможная оптимизация.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Да, логично. Но сначала выжимается максимум из системы, а потом делается оптимизация.

0
Автор поста оценил этот комментарий

А че там DMA никакого нет на экран кидать?

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

DMA есть и используется по максимуму для копирования и отправки данных на экран. Но всё упирается в скорость передачи по интерфейсу SPI (и остальных накладных расходах).

показать ответы
0
Автор поста оценил этот комментарий

Кстати, только что подумалось. А ты не рассматривал концепцию куба как аксессуара к телефону? Цепляешь его по БТ, например, в начинке только чтение БТ канала и ввод/вывод. Все вычислительные мощности упереть на сторону телефона. Опять же из плюсов: обратная связь куба и телефона, можешь вводить/сохранять все что угодно. Доступность ведроида, широченные возможности к разработке приложений. Сплошные плюсы.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Такое в принципе реализуемо. Внутри кубика блютус+вайфай модуль. Другой вопрос, какие именно игры на нем запускать в таком случае.

показать ответы
1
Автор поста оценил этот комментарий

как уже неоднократно говорилось в комментариях под постами ТСа, все это, конечно, здорово, вот только зачем?

ТС, взываю, определись, ЧТО именно ты делаешь? зачем этот кубик?

раскрыть ветку (1)
Автор поста оценил этот комментарий

Вы уже спрашивали это в октябрьском посте. Ответ не изменился.


Это игровая консоль с новым типом управления. Смартфон не дает такого тактильного опыта и пространственного геймплея. Посмотрите пост про 6D-змейку — это самый простой ответ на ваш вопрос. Если и после этого непонятно “зачем”, значит, эта платформа просто не для вас.

10
Автор поста оценил этот комментарий

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

вместо того, чтобы 1 раз пошариться на математическом сайте)

раскрыть ветку (1)
Автор поста оценил этот комментарий

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


Если вдруг сможете найти — буду очень благодарен.

показать ответы

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества