Делаем Тетрис на Arduino

Сегодня мы займемся изучением внутренностей игры Тетрис, написанной под платформу arduino и светодиодную матрицу.
Автором данной самоделки является AlexGyver, автор одноименного YouTube канала. Добро пожаловать в удивительный мир квадратных пикселей.

Начнем, пожалуй, с истории. Тетрис - это игра, в которой сверху вниз падают фигуры, состоящие из 4-х квадратиков. В разных сочетаниях эти фигуры можно поворачивать и перемещать вправо-влево. Цель игры собирать горизонтальные уровни, которые очищаются и вам начисляются очки. Проигрышем считается момент, когда новой фигуре уже некуда упасть. Придумал тетрис советский программист Алексей Леонидович Пажитнов.

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

По количеству проданных коммерческих версий, тетрис превосходит любую другую игру в истории человечества. Лишь для одной Game Boy было продано 35 миллионов копий, не говоря о портативной Brick Game, которая в свое время была практически у всех.
Реализацию тетриса на arduino и цветной матрицы начнем с разбора «костылей». Матрица состоит из трехцветных адресных светодиодов. Проблема у данного типа матриц и в том, что она слишком крутая. Цвет каждого пикселя кодируется 24 битами, то есть по 8 бит на каждую составляющую: красный, зеленый и синий. Такого типа данных на arduino нет, есть следующий - 32 бита.

Цвета всех светодиодов должны храниться в оперативной памяти, так как мы будем их менять. И того, для матрицы 16 на 16 имеем ровно 1 Кб занятой динамической памяти, а у arduino nano их всего 2.

Добавим еще несколько библиотек и начнем писать код, память и во все закончится. Автор принципиально не использует, например, arduino mega, где памяти больше. Цель сделать игру именно на arduino nano, используя простые, стандартные и всем известные инструменты, но в то же время нестандартные подходы и «костыли» и с их помощью добиться максимально оптимального кода.
Первым «костылем» будет отказ от отдельного хранение в памяти позиций фигур и вообще всего, что творится на экране. Нам нужно хранить координаты точек подающей фигуры и координаты точек уже упавших фигур, то есть как максимум нам нужен еще 1 массив, двумерный 16 на 16, а это еще целых 256 байт. У нас с вами уже есть массив цветов всех пикселей, давайте использовать его. Ведь помимо того, что мы можем поставить на матрицу цветную точку, мы можем измерить свет уже имеющейся точки так, что работать будем именно с цветами. Тетрис начинается с падающего блока, который управляется кнопками и имеет 2 координаты в системе координат матрицы. Это очень просто, возводим таймер, по которому будет падать блок. Это библиотека автора, можете почитать на сайте. Для обработки кнопок, автор также использует свою библиотеку. Схема подключения кнопок до смешного проста: 4 кнопки, 8 проводов.

Каждый шаг таймера мы рисуем точку на пиксель ниже старой, а старую точку рисуем черным цветом, то есть выключаем светодиод. По нажатию на кнопку делаем то же самое, но с горизонтальной координатой. Ну и для приличия, ограничим по размерам матрицы, чтобы точка не вышла за пределы поля. Видите, ничего сложного. Но это ненадолго потому, что настало время рисовать фигуры. Работать будем следующим образом: сохраним привязку к подающей точке, которая у нас уже написана, назовем ее главная точка или главный блок. Главный блок двигается в системе координат матрицы, это мы уже сделали. Все фигуры тетриса состоят из 4-ех блоков, именно поэтому, кстати, он и называется Тетрис.

Эти координации запишем в массив вот в таком виде: {0.1, 0.2, 1.2} и массив закинем во флэш-память чтобы не тратить память динамическую. Что касается поворота фигур. Именно поворачивать фигуры у нас не получится. Банально очень трудно объяснить микроконтроллеру как это сделать. Для этого нужно задавать центр вращения, как-то раскладывать фигуру на части и у каждой части искать новые координаты с учетом сильной пикселизации, что явно приведет к ошибкам и получится ерунда. Проблема решается очень просто, будем хранить в памяти все 4 положения для всех фигур и всё.