Спрайт-анимация: человечок шагает из PROGMEM

Первый мой человечек на OLED не шагал — он скользил. Одна поза, нарисованная через drawBitmap, честно ехала по экрану слева направо, но ноги были приколоты к земле намертво: фигурка катилась, как на коньках. Проблема не в коде движения, а в кадрах: живая ходьба — это смена поз, минимум две, а лучше три-четыре, и каждая поза живёт в памяти отдельным битмапом. Сегодня собираю полноценный спрайт: позы шага из PROGMEM, переключение кадров по millis с настраиваемым темпом, движение по экрану и стирание старого места — все четыре детали, без которых фигурка либо мерцает, либо пачкает за собой след.

Базу мы уже закладывали: как битмап превращается в массив байтов и сколько он весит — разобрано в уроке про drawBitmap, а конвертер картинок в C-массив показан в уроке про image2cpp. Здесь то же самое работает в цикле: не одна картинка, а очередь кадров, которую листает таймер. Железо прежнее — SSD1306 128×64 на I2C; для симуляции темпа пригодится ручка на A0, для паузы — кнопка на D2.

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

Спрайт человечка у меня 16×16 пикселей: голова, руки, туловище и ноги, которые и делают всю работу. Две позы — ноги врозь и ноги вместе — дают узнаваемый шаг: чередование читается глазом именно на смене ширины постановки ног. Четыре позы дали бы плавнее походку, но на 16 пикселях высоты разница между третьей и четвёртой позой тонет: детали меньше двух пикселей на этом размере сливаются в шум. Я много раз пробовал дорисовывать промежуточные кадры и вернулся к двум — при 24×24 и выше расширенный цикл уже оправдан.

Теперь память. Один кадр 16×16 — это 16 строк по два байта, итого 32 байта; две позы — 64 байта, и в PROGMEM они почти не чувствуются. Но масштаб считается заранее: кадр размером со весь экран занимает 128×64/8 = 1024 байта, а SRAM у Uno всего 2048 байта — два полных кадра в обычном массиве съедят половину оперативки ещё до первой переменной. Поэтому каждый массив поз помечается словом PROGMEM: байты лежат во flash, а в оперативку читаются по одному через pgm_read_byte в момент отрисовки — библиотека Adafruit_GFX делает это внутри drawBitmap сама.

Темп шага задаёт период кадра. Мой диапазон — 100-150 миллисекунд на позу: при 120 мс получается два шага в секунду, живо, но без бешеной дрожи. Ниже 60 мс позы сливаются в кашу, выше 250 мс ходьба превращается в статичные остановки. Период держим в константе и сравниваем с millis — механику неблокирующих таймеров мы проходили в уроке про millis вместо delay, здесь она листает кадры.

Размер спрайта выбирайте по той же арифметике. 8×8 весит восемь байт на позу, но человечка в восьми пикселях высоты не собрать: только намёк на фигуру. 32×32 даёт уже мимику и складки одежды, но каждый кадр стоит 128 байт, а зона стирания расползается. 16×16 — мой компромисс: 32 байта на позу, четыре позы — 128 байт во flash, и глаз уже читает шаг. Начинайте с малого размера и увеличивайте только когда видите, что не хватает именно деталей, а не кадров.

Порядок внутри кадра критичен. Сначала fillRect заливает чёрным прежнюю зону спрайта, потом сдвигается x, потом рисуется новая поза, и только в конце display() выталкивает буфер на экран. Если поменять местами стирание и отрисовку, экран на мгновение покажет две фигуры в соседних клетках — заметно на шаге 2 пикселя, когда зоны поз перекрываются. drawBitmap ставит белые пиксели поверх буфера, но старые не трогает: оставленный без стирания предыдущий кадр даёт хвост из ног через весь экран — классика первого запуска.

Пауза и рестарт получаются бесплатными. Пока millis не дотянул до периода, loop крутится вхолостую, и остановить фигуру — значит просто не запускать листание: одного флага вокруг всего блока if хватает. Позиция и номер позы живут в глобальных переменных, поэтому после паузы шаг продолжается с того же места — отдельное состояние «пауза» хранить не нужно. В игре этого мало: там фигура ещё и прыгает, а физику прыжка и столкновений разбирает урок про Flappy Bird — тот же каркас кадров плюс одна переменная вертикальной скорости.

Второй нюанс — движение против поз. Шаг по x на 2 пикселя за кадр при периоде 120 мс согласован с шириной постановки ног: если двигать на 4 пикселя, фигура проскакивает межкадровое расстояние и походка рвётся, хотя сами позы меняются исправно. Темп и скорость — разные ручки: период листает кадры, шаг по x ведёт фигуру по земле. На этот разбор я потратил вечера два, пока не полез с примером в чужой скетч игры — там дисциплина кадров уже стояла, и урок про анимацию без мерцания разобрал её по косточкам.

Буфер и display() работают так, что промежуточных состояний на экране не видно вообще: всё, что нарисовано до display(), живёт только в RAM. Почему так устроено и где лежит буфер 1024 байта — отдельная тема, разобранная в уроке про буфер и clearDisplay. Для анимации это означает свободу: можно стереть, перерисовать и подвинуть хоть пять объектов за один кадр — экран увидит только итог.

Тот же каркас ест любой спрайт: сердце с двумя фазами пульсации, капля дождя, стрелка компаса — меняются массивы и ширина зоны стирания. Развилка одна: спрайт едет по экрану — стирайте старую зону и сдвигайте x; спрайт стоит на месте — достаточно перерисовывать только его клетку, и кадр почти ничего не стоит. У меня сердечко на будильнике живёт в углу шапки рядом с часами: 16×16, две фазы, период полсекунды, и таймеры не мешают друг другу, потому что у каждого свой момент на millis.

В симуляторе видно главное свойство цикла: позы сменяются строго по таймеру, а не по скорости loop — выкрутите ручку в верхнее положение, и дрожь кадра станет заметной, в нижнее — фигура делает паузу в каждой позе. В паузе по кнопке таймер стоит, но позиция сохраняется: продолжение идёт с того же места, потому что x и поза живут в глобальных переменных между кадрами. На плате этот же каркас рисует уже байты из PROGMEM: симулятор честно показывает логику листания, а пиксельную картинку даёт железо.

Если фигура ходит в обе стороны, зону стирания считают от старой позиции в сторону новой: fillRect от меньшего x шириной 16 плюс |dx| — иначе при смене направления за спиной остаётся столбик. Дешевле держать dx одной переменной и стирать объединение двух зон — это две строки кода против отдельной ветки на каждое направление.