Лилик, дорогой!
Я же тебя еще на старом форуме, когда ты мучил 1306 дисплей, спрашивал о цели. Тогда - пусть его - ты изучал новую игрушку. Но теперь уже набрал кое-какой опыт. Я повторю вопрос: для чего ты планируешь выводить картинки на неподходящем устройстве? Есть ли практическая цель, кроме обучения?
Микроконтроллеры, даже такие продвинутые и двухядерные, как RP2040 или ЕСП32 не созданы для фотореалистичной графики. Экран, если и используют, но на уровне GUI и без особых украшательств. Вообще не созданы. Если бы ты вспомнил времена Виндоус 3.11 то в ней не было возможности выводить графику - 16 цветов всего, для большей части компов. Картинки, адаптированные под восьми-битный цвет мы выводили на режиме VGA19 - 320х200.
Это было совсем недавно.
Тут, на форуме, было обсуждение про то, почему современные программы тратят столько памяти. В первую очередь именно по этому - КРАСИВАЯ ГРАФИКА.
Вообще очень интересное искажение психики - интересоваться максимумом возможностей. Что человека, что технологии. Когда-то это было оправдано - не было другого. Но сейчас зачем интересоваться скоростью велосипеда. если есть мотоцикл? Зачем интересоваться глубиной погружения без акваланга, если он есть? Мне кажется, что если бы была возможность БОЛЕЕ ОДНОГО РАЗА прыгнуть без парашюта, то были бы любители узнать и эту возможность!
Так вопрос: зачем слайд-шоу на ЕСП32? Оформление красивого GUI нужно делать сообразно с возможностями контроллера. Он не может воспроизводить видео, но может отрисовать интересную анимацию.
Практическая желалка делать анимационную заставку к игре,
в каждом этапе. Интересоваться максимумом как то само выходит. Вот сделал птицепрыгалку на кнопке, через день привык к механике нажатия добавил ещё два уровня с другой механикой кнопки. Теперь к череде трёх алгоритмов управления привыкаю. А тут картинка-заставка надоела, вот про анимацию и подумал.
Ну, а презентация - форма ознакомления через экран (при одной кнопке в интерфейсе) будет полезна.
Рисуй анимацию. Или обрабатывай видео для компактного и быстрого вывода на ЕСП. Но “в лоб” такое нельзя сделать.
Вообще мне казалось что у тебя есть художественная подготовка? Художка в детстве или что-то типа? Так вот пойди путем классической анимации. Фон и объект. Объект можно всячески искажать аффинными преобразованиями. Объектов может быть несколько - туловище, конечности, голова. Как пленка прозрачная с персонажем в старых мультиках. На такое должно хватить и скорости и памяти.
ЗЫ: еще допишу. Про пламя свечи. Колебания свечи это искажения стандартной ровной и симметричной “луковки” пламени. То есть картинка нужна ровно ОДНА. а искажения либо придумать, либо вычислить из имеющегося ряда. Это уже, конечно, не аффинные искажения.
Вот это уже интересная алгоритмическая задача. А не “впихнуть невпихуемое”
Не, рисовальщик я никакой со школы ещё. Просто графическое представление не очень даёт волю фантазии в отличии от текста поэтому графика читаема, а текст не очень иллюстративен для меня.
Купите себе уже одноплатник, поставьте Linux, к нему легко цепляется практически любой дисплей, там уже гигагирцовый минимум проц 64 разрядный, можно на фантазировать почти все.
Логическая ошибка: чтобы что-то было уже сделано, мало, чтобы было разрешение, нужно, чтобы это хоть кому-то было полезным.
А бесполезных вещей, которые сделать можно, но которые не сделаны и никогда не будут сделаны, - море. Просто потому, что они абсолютно никому не нужны.
Ну вот первые 3 кадра вашей гифки. Если даже сильно не всматриваться, то видно, что в каждом следующем кадре хранится только то, что изменилось от предыдущего.
Хорошо видно на примере столба - на втором кадре его старое местоположение затирается небом, и рисуется новый столб на новом месте. Всё остальное изображение не трогается и остается от предыдущего кадра. С третьим и последующими кадрами - аналогично.
Должно быть понятно, что и второй, и третий кадры будут занимать меньше места, чем первый - просто потому, что данных меньше и сожмутся они лучше.
Если вам не понятен сам принцип сжатия, то представьте, что жена послала вас в магазин. Она же не скажет вам “купи огурец, огурец, огурец, огурец, грушу, грушу, грушу”, а скажет “купи 4 огурца и 3 груши”. Это и есть простейший алгоритм сжатия - RLE называется. Вспомнился анекдот: “…а это изюм, но он не продается!”
Посмотрите, например, на второй кадр, сколько там прозрачных (зелёных) пикселей подряд! Зачем хранить одинаковые идущие подряд пиксели, если можно сразу указать - официант, прозрачный пиксель 100500 раз пжалуста.
Но это самый простой алгоритм, в реальности применяются алгоритмы значительно оптимальнее.
Посмотрел похожий вариант с птичкой. Принцип ясен. Он ограничен малыми изменениями в анимации по отношению к базовому кадру. Попробую на примере ST7735 сделать, правда со своеобразным способом сжатия.
Не пойму, вы готовую анимацию пытаетесь сжать для показа на экране или графику в игре выводите?
Для игры так не делается, как для видео или гифки. Для игры нужны тайлы/спрайты, т.е. кусочки изображения, из которых составляется общая картинка. Для птички это будут:
дома́, причем не от края до края одним тайлом, а хранится только одна группа домов и на экран выводится 4 раза;
кусты, также выводятся с повтором;
облака, у них периодичность слабо улавливается, скорее всего нарисовано с перекрытием;
земля (то, что внизу в косую полоску), тут вообще хранится одна маленькая косая полоска, при выводе на экран повторяющаяся раз 20, а то и вообще такой примитив программно можно формировать;
столб - достаточно хранить узкую горизонтальную полоску в один пиксель толщиной по вертикали (для формирования столба) + его “шапка” (тоже можно только одну полоску хранить);
птичка - туловище + 3 положения крыла.
P.S. Вообще, странная какая-то гифка, столбы и низ зашумлены. Зачем? Цвета к стандартной палитре подгонялись что ли?
поэтому графика читаема, а текст не очень иллюстративен для меня.
