TECHNO BROTHER

АЦП управляется при помощи нескольких регистров:

Регистр Communications

Communications Register 8 бит, содержит биты настройки выбора входа CH1 CH0, активация режима STANDBY STBY.

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

Например необходимо записать данные в регистр SETUP, то в коммуникационном регистре записываем адрес регистра SETUP, номер канала, бит записи или чтения:

Communications Register (пример записи в регистр SETUP)

RS0 RS1 RS2 = [001] — адрес регистра SETUP

RW = [0] — запись

CH1 CH0 = [01] — выбран канал №2

Регистр Setup

Регистр SETUP содержит биты настройки коэффициента усиления G2 G1 G0 (от 1 до 128), режимы калибровки MD1 MD0, тип входного сигнала B/U (униполярный\биполярный).

Биты G2 G1 G0

Режимы калибровки:

MD1 MD0 = [00] — рабочий режим, калибровка не проводится

MD1 MD0 = [01] — калибровка нуля и опорного напряжения

MD1 MD0 = [10] — калибровка нуля

MD1 MD0 = [11] — калибровка опорного напряжения

После процедуры калибровки биты MD1 MD0 возвращаются в рабочий режим [00].

Регистр Clock

Регистр Clock содержит делитель тактовых импульсов на 2 (бит CLKDIS), бит выбора частоты кварцевого резонатора (бит CLKDIV) и биты CLK FS1 FS0 определяющие скорость опроса АЦП (частота дискретизации).

*Бит CLK доступен при использовании кварцевого резонатора 4.9152 MHz

Регистр данных (Data Register)

16 — и бытный регистр, содержит результат измерения.

Ниже показаны эпюры сигналов в режиме чтения и записи регистров.

Запись

Чтение

При записи данных в регистр сигнал CS служит сигналом начала и конца записи данных, запись бита производится на возрастающем фронте сигнала синхронизации SCLK.

При чтении главным условием для начала чтения данных служит сигнал готовности АЦП к передаче данных DRDY, в данном примере сигнал готовности DRDY снимается в выхода АЦП, но можно и не использовать выход DRDY, а брать состояние готовности с бита DRDY коммуникационного регистра. Далее после сигнала CS, на каждом возрастающем фронте сигнала синхронизации SCLK происходит считывание 1 бита данных с выхода DOUT. Запись как и чтение начинается со старшего разряда.

Как ранее отмечалось AD7706 имеет 3 псевдо дифференциальных входа, поэтому общим входом для всех каналов служит вход COMMON. В зависимости от подключения входа COMMON АЦП может измерять биполярное или униполярное напряжение.

Схема включения при измерении униполярного напряжения

Тестовый скетч

// AD7706

#define SCLK 2

#define CS 3

#define DIN 4

#define DOUT 5

#define DRDY 6 

#define REF 2.500  

#define AIN1 0b00

#define AIN2 0b01

#define AIN3 0b11  

#define GAIN_1 0b000000

#define GAIN_2 0b001000

#define GAIN_4 0b010000

#define GAIN_8 0b011000

#define GAIN_16 0b100000

#define GAIN_32 0b101000

#define GAIN_64 0b110000

#define GAIN_128 0b111000 

#define F20 0b000 // 5.24 Hz

#define F25 0b001 // 6.55 Hz

#define F100 0b010 // 26.2 Hz

#define F200 0b011 // 52.4 Hz 

unsigned long times; 

void setup() {

Serial.begin(9600);

pinMode(SCLK,OUTPUT);

pinMode(CS,OUTPUT);

pinMode(DIN,OUTPUT);

pinMode(DOUT,INPUT);

pinMode(DRDY,INPUT);

digitalWrite(SCLK,HIGH);

digitalWrite(CS,HIGH);

digitalWrite(DIN,HIGH);

reset(); 

write_byte(0x20|AIN2);

write_byte(0x00|F20); // Clock | 2.4576 MHz

delay(100);

} 

void loop() {

times=millis();

write_byte(0x10|AIN2);

write_byte(0b01000100|GAIN_1); // Setup | Self-Calibration  // Измеренное напряжение от 0 до +2,5 В

write_byte(0x38|AIN2);

unsigned int u_data = read_byte();

Serial.println(REF/65535 * (u_data),5 );  // Цифровое значение от 0(0,0В) до 65535(+2,5В)

Serial.println(u_data);  /// Частота опроса

Serial.print("F = ");

Serial.print(1/ ((float(millis()-times))/1000));

Serial.println(" Hz");

Serial.println();

delay(1000);

} 

void write_byte(byte data){

digitalWrite(CS,LOW);

for(int i = 7; i >= 0; i--){

digitalWrite(SCLK,LOW);

digitalWrite(DIN, (data >> i) & 1);

digitalWrite(SCLK,HIGH); }

digitalWrite(CS,HIGH);

} 

unsigned int read_byte(){

unsigned int data_out=0;

unsigned int dat;

while(digitalRead(DRDY)!=LOW);

digitalWrite(CS,LOW);

for(int i = 15; i >= 0; i--){

digitalWrite(SCLK,LOW);

digitalWrite(SCLK,HIGH);

dat = digitalRead(DOUT);

data_out |= (dat<<i); }

digitalWrite(CS,HIGH);

return data_out;

} 

void reset(){

digitalWrite(CS,LOW);

for(int i = 31; i >= 0; i--){

digitalWrite(SCLK,LOW);

digitalWrite(DIN, HIGH);

digitalWrite(SCLK,HIGH); }

digitalWrite(CS,HIGH); }

На вход №2 подано напряжение в 1,8 В. В мониторе порта отображается частота опроса, измеренное напряжение и его цифровое значение которое может находится в пределах от 0 до 65535 (16 бит).

Схема включения при измерении биполярного напряжения

При измерении биполярного напряжения на вход COMMON подается опорное напряжение для создания средней точки, при этом источник входного сигнала не должен иметь соединения с GND АЦП.

Тестовый скетч

// AD7706

#define SCLK 2

#define CS 3

#define DIN 4

#define DOUT 5

#define DRDY 6 

#define REF 2.500  

#define AIN1 0b00

#define AIN2 0b01

#define AIN3 0b11  

#define GAIN_1 0b000000

#define GAIN_2 0b001000

#define GAIN_4 0b010000

#define GAIN_8 0b011000

#define GAIN_16 0b100000

#define GAIN_32 0b101000

#define GAIN_64 0b110000

#define GAIN_128 0b111000 

#define F20 0b000 // 5.24 Hz

#define F25 0b001 // 6.55 Hz

#define F100 0b010 // 26.2 Hz

#define F200 0b011 // 52.4 Hz 

unsigned long times; 

void setup() {

Serial.begin(9600);

pinMode(SCLK,OUTPUT);

pinMode(CS,OUTPUT);

pinMode(DIN,OUTPUT);

pinMode(DOUT,INPUT);

pinMode(DRDY,INPUT);

digitalWrite(SCLK,HIGH);

digitalWrite(CS,HIGH);

digitalWrite(DIN,HIGH);

reset(); 

write_byte(0x20|AIN2);

write_byte(0x00|F100); // Clock | 2.4576 MHz

delay(100);

} 

void loop() {

times=millis();

write_byte(0x10|AIN2);

write_byte(0b01000000|GAIN_1); // Setup | Self-Calibration  // Измеренное напряжение от 0 до +/-2,5 В

write_byte(0x38|AIN2);

unsigned int u_data = read_byte();

Serial.println(REF/32768 * (u_data-32768),5 );  // Цифровое значение от 0(-2,5В) до 65535(+2,5В), середина шкалы 32768(0,0В)

Serial.println(u_data);  /// Частота опроса

Serial.print("F = ");

Serial.print(1/ ((float(millis()-times))/1000));

Serial.println(" Hz");

Serial.println();

delay(1000);

} 

void write_byte(byte data){

digitalWrite(CS,LOW);

for(int i = 7; i >= 0; i--){

digitalWrite(SCLK,LOW);

digitalWrite(DIN, (data >> i) & 1);

digitalWrite(SCLK,HIGH);

}

digitalWrite(CS,HIGH);

} 

unsigned int read_byte(){

unsigned int data_out=0;

unsigned int dat;

while(digitalRead(DRDY)!=LOW);

digitalWrite(CS,LOW);

for(int i = 15; i >= 0; i--){

digitalWrite(SCLK,LOW);

digitalWrite(SCLK,HIGH);

dat = digitalRead(DOUT);

data_out |= (dat<<i); }

digitalWrite(CS,HIGH); r

eturn data_out;

} 

void reset(){

digitalWrite(CS,LOW);

for(int i = 31; i >= 0; i--){

digitalWrite(SCLK,LOW);

digitalWrite(DIN, HIGH);

digitalWrite(SCLK,HIGH);

}

digitalWrite(CS,HIGH);

}

На вход №2 подано напряжение в +1,48 В. В мониторе порта отображается частота опроса, измеренное напряжение и его цифровое значение которое может находится в пределах от 32768 (0 В) до 65535 (+2,5 В) (15 бит).

На вход №2 подано напряжение в -1,48 В. В мониторе порта отображается частота опроса, измеренное напряжение и его цифровое значение которое может находится в пределах от 0 (-2,5 В) до 32768 (0 В) (15 бит).

Даташит — ad7706.pdf

http://rcl-radio.ru/?p=129749

• FLASH (ПЗУ): 32 Кбайт

• SRAM (ОЗУ): 2 Кбайт

• E2PROM (EEPROM): 0K / 1K / 2K / 4K / 8K (эмуляция)

• PWM (ШИМ): 8

• Частота: 32 МГц

• АЦП: 9 пинов, 12 бит

• ЦАП: 1 пин, 8 бит

• Силовые пины: 4 (до 80 мА)

• Таймеры 2x 8bit, 2x 16bit

• UART: 1

• SPI: 1

• I2C: 1

• PLL: 1

• Опорное напряжение: 1.024В / 2.048В / 4.09В ± 0,5%

• Логический уровень: 5В

Для прошивки LGT8F328P-LQFP32 MiniEVB необходимо поэтапно выполнить несколько простых действий:

1. Добавим поддержку платы LGT8F328P-LQFP32 MiniEVB в Arduino IDE, для этого добавим ссылку в менеджер плат

https://raw.githubusercontent.com/dbuezas/lgt8fx/master/pack...

Далее в менеджере плат находим плату lgt8fx выбрав версию платы 2.0.0 (и выше) и устанавливаем ее:

Далее во вкладке инструменты находим нужную нам плату:

Установите настройки показанные на скриншоте:

После установки настроек платы можно для примера загрузить скетч BLINK. На плате  LGT8F328P-LQFP32 MiniEVB установлен светодиод подключенные к выходу D13, после загрузки скетча светодиод должен начать мигать.

Для загрузки скетча

void setup() {  

pinMode(LED_BUILTIN, 13); }

void loop() {  

digitalWrite(13, HIGH); 

delay(1000); 

digitalWrite(13, LOW); 

delay(1000);  

}

Распиновка платы

http://rcl-radio.ru/?p=129966

Владельцы собак-роботов смогут вернуть своих питомцев в Sony. Компания проведет ремонт и передаст их больницам, домам престарелых и другим социальным учреждениям.

В Sony уверены, что собаки-роботы подходят для эмоциональной поддержки: реагируют на голос и прикосновения и «узнают» хозяина.

Источник : Будущее сейчас

Многие программисты так или иначе имеют тягу и интерес к разработке игр. Немалое количество спецов было замечено за написанием маленьких и миленьких игрушек, которые были разработаны за короткое время «just for fun». Большинству разработчиков за счастье взять готовый игровой движок по типу Unity/UE и попытаться создать что-то своё с их помощью, особенно упорные изучают и пытаются что-то сделать в экзотических движках типа Godot/Urho, а совсем прожжённые ребята любят писать игрушки… с нуля. Таковым любителем писать все сам оказался и я. И в один день мне просто захотелось написать что-нибудь прикольное, мобильное и обязательно — двадэшное! В этой статье вы узнаете про: написание производительного 2D-рендерера с нуля на базе OpenGL ES, обработку «сырого» ввода в мобильных играх, организацию архитектуры и игровой логики и адаптация игры под любые устройства. Интересно? Тогда жду вас в статье!

❯ Как это работает?

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

Один из прошлых проектов — 3D шутэмап под… коммуникаторы с Windows Mobile без видеоускорителей! Игра отлично работала и на HTC Gene, и на QTek S110!

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

Подобные инструменты включают в себя как довольно функциональныеконструкторы игр, которые обычно не требуют серьёзных навыков программирования и позволяют собирать игру из логических блоков, так и полноценных игровых движков на манер Unity или Unreal Engine, которые позволяют разработчикам писать игры и продумывать их архитектуру самим. Можно сказать что именно «благодаря» доступности подобных инструментов мы можем видеть текущую ситуацию на рынке мобильных игр, где балом правят очень простые и маленькие донатные игрушки, называемыегиперкежуалом.

Но у подобных инструментов есть несколько минусов, которые банально не позволяют их использовать в реализации некоторых проектов:

• Большой вес приложения: При сборке, Unity и UE создают достаточно объёмные пакеты из-за большого количества зависимостей. Таким образом, даже пустой проект может спокойно весить 50-100 мегабайт.

• Неоптимальная производительность: И у Unity, и у UE очень комплексные и сложные рендереры «под капотом». Если сейчас купить дешевый смартфон за 3-4 тысячи рублей и попытаться на него накатить какой-нибудь 3 в ряд, то нас ждут либо вылеты, либо дикие тормоза.

Лично я для себя приметил ещё один минус — невозможность деплоить игры на устройства с старыми версиями Android, но это, опять же, моя личная хотелка.

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

❯ Определяемся с задачами

Перед тем, как садится и пилить игрушку, нужно сразу же определится с целями и поставить перед собой задачи — какой стек технологий мы будет использовать, как будем организовать игровую логику, на каких устройствах игра должна работать и.т.п. Я прикинул и решил реализовать что-то совсем несложное, но при этом достаточно динамичное и забавное… 2D-шутер с видом сверху!

Игра будет написана полностью на Java — родном языке для Android-приложений. Пустые пакеты без зависимостей весят всего около 20 килобайт — что только нам на руку! Ни AppCompat, ни какие либо ещё библиотеки мы использовать не будем — нам нужен минимальный размер из возможных!

Итак, что должно быть в нашей игре:

• Основная суть: Вид сверху, человечком по центру экрана можно управлять и стрелять во вражин. Цель заключается в том, чтобы набрать как можно больше очков перед тем, как игрока загрызут. За каждого поверженного врага начисляются баксы, за которые можно купить новые пушки!

• Оружие: Несколько видов вооружения, в том числе пистолеты, дробовики, автоматы и даже пулеметы! Всё оружие можно купить в внутриигровом магазине за валюту, которую игрок заработал во время игры

• Враги: Два типа врагов — обычный зомби и «шустрик». Враги спавнятся в заранее предусмотренных точках и начинают идти (или бежать) в сторону игрока с целью побить его.

• Уровни: Можно сказать, простые декорации — на момент написания статьи без какого либо интерактива.

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

• Графика: Аппаратно-ускоренный рендерер полупрозрачных 2D-спрайтов с возможность аффинных трансформаций (поворот/масштаб/искривление и.т.п). На мобильных устройствах нужно поддерживать число DIP'ов (вызовов отрисовки) как можно ниже — для этого используется техника батчинга. Сам рендерер работает на базе OpenGLES 1.1 — т.е чистый FFP.

• Ввод: Обработка тачскрина и геймпадов. Оба способа ввода очень легко реализовать на Android — для тачскрина нам достаточно повесить onTouchListener на окно нашей игры, а для обработки кнопок — ловить события onKeyListener и сопоставлять коды кнопок с кнопками нашего виртуального геймпада.

• Звук: Воспроизведение как «маленьких» звуков, которые можно загрузить целиком в память (выстрелы, звуки шагов и… т.п), так и музыки/эмбиента, которые нужно стримить из физического носителя. Тут практически всю работу делает за нас сам Android, для звуков есть класс — SoundPool (который, тем не менее, не умеет сообщать о статусе проигрывания звука), для музыки — MediaPlayer. Есть возможность проигрывать PCM-сэмплы напрямую, чем я и воспользовался изначально, но с ним есть проблемы.

• «Физика»: Я не зря взял этот пункт в кавычки :) По сути, вся физика у нас — это один метод для определения AABB (пересечения прямоугольник с прямоугольником). Всё, ни о какой настоящей физике и речи не идет :)

Поэтому, с учетом требований описанных выше, наша игра будет работать практически на любых смартфонах/планшетах/тв-приставках кроме китайских смартфонов на базе чипсета MT6516 без GPU из 2010-2011 годов. На всех остальных устройствах, включая самый первый Android-смартфон, игра должна работать без проблем. А вот и парк устройств, на которых мы будем тестировать нашу игру:

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

❯ Рендерер

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

По сути, в современном мире, 2D — это частный случай 3D, когда рисуются всё те же примитивы в виде треугольников, но вместо перспективной матрицы, используется ортографическая матрица определенных размеров. Во времена актуальности DirectDraw (середина-конец 90х) и Java-телефонов, графику обычно не делали адаптивной, из-за чего при смене разрешения, игровое поле могло растягиваться на всю площадь дисплея. Сейчас же, когда разброс разрешений стал колоссальным, чаще всего можно встретить два подхода к организацию проекции:

• Установка ортографической матрицы в фиксированные размеры: Если координатная система уже была завязана на пиксели, или по какой-то причине хочется использовать именно её, то можно просто завязать игру на определенном разрешении (например, 480x320, или 480x800). Растеризатор формально не оперирует с пикселями — у него есть нормализованные координаты -1..1 (где -1 — начало экрана, 0 — середина, 1 — конец, это называется clip-space), а матрица проекции как раз и переводит координаты геометрии в camera-space координатах в clip-space — т.е в нашем случае, автоматически подгоняет размеры спрайтов из желаемого нами размера в физический. Обратите внимание, физические движки обычно рассчитаны на работу в метрических координатных системах. Попытки задавать ускорения в пикселях вызывают рывки и баги.

• Перевод координатной системы с пиксельной на метрическую/абстрактную:
  Сейчас этот способ используется чаще всего, поскольку именно его используют самые популярные движки и фреймворки. Если говорить совсем просто — то мы задаем координаты объектов и их размеры не относительно пикселей, а относительно размеров этих объектов в метрах, или ещё какой-либо абстрактной системы координат. Этот подход близок к обычной 3D-графике и имеет свои плюшки: например, можно выпустить HD-пак для вашей игры и заменить все спрайты на варианты с более высоким разрешением, не переделывая половину игры.

Для совсем простых игр я выбираю обычно первый подход. Самое время реализовать главный метод всего рендерера — рисование спрайтов. В моём случае, спрайты не были упакованы в атласы (одна текстура, содержащая в себе целую анимацию или ещё что-то в этом духе), поэтому и возможность выборки тайла из текстуры я реализовывать не стал. В остальном, всё стандартно:

Всё более чем понятно — преобразуем координаты спрайта из world-space в camera-space, отсекаем спрайт, если он находится за пределами экрана, задаем стейты для GAPI (на данный момент, их всего два), заполняем вершинный буфер геометрией и рисуем на экран. Никакого смысла использовать VBO здесь нет, а на nio-буфферы можно получить прямой указатель без лишних копирований, так что никаких проблем с производительностью не будет. Обратите внимание — вершинный буфер выделяется заранее — аллокации каждый дравколл нам не нужны и вредны.

Обратите внимание на вызовы ByteBuffer.order — это важно, по умолчанию, Java создаёт все буферы в BIG_ENDIAN, в то время как большинство Android-устройств — LITTLE_ENDIAN, из-за этого можно запросто накосячить и долго думать «а почему у меня буферы заполнены правильно, но геометрии на экране нет!?».

В процессе разработки игры, при отрисовке относительно небольшой карты с большим количеством тайлов, количество вызовов отрисовки возросло аж до 600, из-за чего FPS в игре очень сильно просел. Связано это с тем, что на старых мобильных GPU каждый вызов отрисовки означал пересылку состояния сцены видеочипу, из-за чего мы получали лаги. Фиксится это довольно просто: реализацией батчинга — специальной техники, которая «сшивает» большое количество спрайтов с одной текстурой в один и позволяет отрисовать хоть 1000, хоть 100000 спрайтов в один проход! Есть два вида батчинга, статический — когда объекты «сшиваются» при загрузке карты/в процессе компиляции игры (привет Unity) и динамический — когда объекты сшиваются прямо на лету (тоже привет Unity). На более современных мобильных GPU с поддержкой GLES 3.0 есть также инстансинг — схожая технология, но реализуемая прямо на GPU. Суть её в том, что мы передаём в шейдер параметры объектов, которые мы хотим отрисовать (матрицу, настройки материала и.т.п) и просим видеочип отрисовать одну и ту же геометрию, допустим, 15 раз. Каждая итерация отрисовки геометрии будет увеличивать счетчик gl_InstanceID на один, благодаря чему мы сможем расставить все модельки на свои места! Но тут уж справедливости ради стоит сказать, что в D3D10+ можно вообще стейты передавать на видеокарту «пачками», что здорово снижает оверхед одного вызова отрисовки.

Для загрузки спрайтов используется встроенный в Android декодер изображений. Он умеет работать в нескольких режимах (ARGB/RGB565 и.т.п), декодировать кучу форматов — в том числе и jpeg, что положительно скажется на финальном размере игры.

На этом реализация рендерера закончена. Да, все вот так просто :)
Переходим к двум остальным модулям — звук и ввод.

❯ Звук и ввод

Как я уже говорил, звук я решитл реализовать на базе уже существующей звуковой подсистемы Android. Ничего сложного в её реализацир нет, можно сказать, нам остаётся лишь написать обёртку, необходимую для работы. Изначально я написал собственный загрузчик wav-файлов и хотел использовать AudioTrack — класс для воспрозизведения PCM-звука напрямую, но мне не понравилось, что в нём нет разделения на источники звука и буферы, из-за чего каждый источник вынужден заниматься копированием PCM-потока в новый и новый буфер…

Полная реализация звукового потока выглядит так. И да, с SoundPool нет возможности получить позицию проигрывания звука или узнать, когда проигрывание закончилось. Увы.

Да будет звук! Ну и про ввод не забываем (листинг получился слишком длинный, а на Пикабу нет тега для кода - так что как-то так):

public static final int TOUCH_IDLE = 0; public static final int TOUCH_PRESS - Pastebin.com

Сама реализация джойстика крайне простая — запоминаем координаты, куда пользователь поставил палец и затем считаем дистанцию положения пальца относительно центральной точки, параллельно нормализововая их относительно максимальной дистанции:

public class Joystick { private Sprite joySprite; public float Veloc - Pastebin.com

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

Основа для игры есть, теперь переходим к её реализации!

❯ Пишем игру

Писать игру я начал с создания первого уровня и реализации загрузчика уровней. В качестве редактора, я выбрал популярный и широко-известный TileEd — удобный редактор с возможностью экспорта карт в несколько разных форматов. Я лично выбрал Json, поскольку в Android уже есть удобный пакет для работы с этим форматом данных.

Карта делится на 3 базовые понятия: тайлы — фон, с изображением травы/асфальта/земли и.т.п, пропы — статичные объекты по типу деревьев и кустов и сущности — объекты, участвующие в игровом процессе, т.е игрок, зомби и летящие пули. Система сущностей реализована в виде абстрактного базового класса, который реализовывает логику апдейтов, просчитывает Forward-вектор и выполняет другие необходимые задачи:

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

@Override public void update() { super.update(); joyInp - Pastebin.com

Ну и не забываем про реализацию зомби. Она тоже очень простая: есть базовый класс Zombie, от которого наследуются все монстры и который реализует несколько необходимых методов — повернуться в сторону игрока, идти вперед и конечно же атака!

❯ Что у нас есть на данный момент?

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

Как мы видим, игра (а пока что — proof of concept) работает довольно неплохо на всех устройствах, которые были выбраны для тестирования. Однако это ещё не всё — предстоит добавить конечную цель игры (набор очков), магазин стволов и разные типы мобов. Благо, это всё реализовать уже совсем несложно :)

❯ Заключение

Написать небольшую игрушку с нуля в одиночку вполне реально. Разработка достаточно больших проектов конечно же требует довольно больших человекочасов, однако реализовать что-то своё, маленькое может и самому!

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

Статья подготовлена при поддержке компании TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи каждую неделю!
Но тут я даже чутка навру - на этой неделе вас ждёт сразу две статьи :) Следующая - в четверг, прошлую неделю я отдыхал и работал.

Для примера использования таймера выберем 16 битный таймер Timer_1.

Для настройки таймера в данном примере используется 3 регистра:

• TCCR1B — Регистр управления B

• OCR1A — Регистр сравнения А выходных данных

• TIMSK1 — Регистр маски прерываний счетчика/таймера

Пример скетча:

void setup() {  

pinMode(12, OUTPUT);  

noInterrupts();  

TCNT1 = 0;  

TCCR1A = 0;  

TCCR1C = 0;  

byte n = 5;  

// clksys / 1 = 1  

// clksys / 8 = 2  

// clksys / 64 = 3  

// clksys / 256 = 4  

// clksys / 1024 = 5  

// [CS12:CS10]  

TCCR1B = (1 << WGM12) | n;  

OCR1A = 9999;// 0-65535  

TIMSK1 |= (1 << OCIE1A); //

_ctc = f_sys / (2 * n * (1 + OCR1A)) // 32 000 000 / (2 * 1024 * (1 + 9999)) = 1.5625 Hz interrupts();

}

void loop() {}

ISR(TIMER1_COMPA_vect){digitalWrite(12, !digitalRead(12));}

Подключите светодиод (через резистор 200 Ом) к выходу D12. После загрузки скетча светодиод начнет мигать с частотой 1,5625 Гц.

TCCR1B

В регистре управления используем бит WGW12 и биты CS10:CS12.

WGW12 активирует режим СТС

CS10:CS12 предделитель который делит тактовую частоту микроконтроллера

OCR1A

16-и битный регистр сравнения, содержит два 8-и битных регистра: OCR1AL и OCR1AH объединены для
формирования 16-разрядного OCR1A.

TIMSK1

Бит регистра TIMSK1 OCIE1A  разрешают прерывания при совпадении с A (OCR1A).

ISR(TIMER1_COMPA_vect) — функция обработчика прерывания, в нее помещается код который необходимо исполнять в режиме прерывания.

Если имеется необходимость использовать таймер для генерации импульсов (меандр), в микроконтроллере имеются выходы таймера. Для Timer_1 это выходы D9 и D10.

При совпадении регистра сравнения OCIE1A и счетного регистра состояние выхода таймера меняется на противоположное, а счетный регистр TCNT1 сбрасывается.

Ниже показан пример скетча генерации меандра, таймер работает в режиме CTC

void setup() {  

pinMode(9, OUTPUT);  

noInterrupts();  

TCNT1 = 0;  

TCCR1A = 0;  

TCCR1C = 0;  

byte n = 5;  

// clksys / 1 = 1  

// clksys / 8 = 2  

// clksys / 64 = 3  

// clksys / 256 = 4  

// clksys / 1024 = 5  

// [CS12:CS10]  

TCCR1B = (1 << WGM12) | n;  

OCR1A = 9999;// 0-65535  

TCCR1A |= (1 << COM1A0);

// f_ctc = f_sys / (2 * n * (1 + OCR1A)) // 32 000 000 / (2 * 1024 * (1 + 9999)) = 1.5625 Hz interrupts();

}

void loop() {}

Бит COM1A0 регистра TCCR1A определяет режим работы таймера. Если установлен бит COM1A0 то состояние на выходе OC1A меняется на противоположное при совпадении.

В этом примере если подключить светодиод (через резистор 200 Ом) к выходу D9, то после загрузки скетча он начнет мигать с частотой 1,5625 Гц.

Нормальный режим работы таймера

В нормальном режиме работы таймера можно использовать регистр сравнения OCR1A, при равенстве счетного регистра TCNT1 и регистра сравнения OCR1A происходит прерывание, но в отличии от режима СТС счетный регистр TCNT1 не сбрасывается, а увеличивает свое значение до максимального 65535 и только после этого происходит его сброс и новое прерывание.

Для нормальной работы этого режима в регистре масок прерывания TIMSK1 используются биты OCIE1A и TOIE1.

Бит OCIE1A разрешает прерывание по совпадению, а бит TOIE1 разрешает прерывание по переполнению.

При этом прерывания происходят два раза за один цикл заполнения счетного регистра TCNT1.

Пример скетча

void setup() {  

pinMode(12, OUTPUT);  

noInterrupts();  

TCNT1 = 0;  

TCCR1A = 0;  

TCCR1C = 0;  

byte n = 5;  

// clksys / 1 = 1  

// clksys / 8 = 2  

// clksys / 64 = 3  

// clksys / 256 = 4  

// clksys / 1024 = 5  

// [CS12:CS10]  

TCCR1B = n;  

OCR1A = 9999;// 0-65535  

TIMSK1 |= (1 << OCIE1A) | (1 << TOIE1);

interrupts();

}

void loop() {}

ISR(TIMER1_COMPA_vect){  digitalWrite(12, !digitalRead(12));  }

При обнулении счетного регистра светодиод подключенный к D12 (через резистор 200 Ом) загорается, как только значение счетного регистра станет равным значению регистра сравнения, светодиод погаснет и не будет светится пока значение счетного регистра не достигнет максимального значения.

Период работы прерывания при переполнении счетного регистра равен:

Tпереполнения = 1/(f sys / (2 * N * 65536))

Период работы прерывания при совпадении равен:

Tсовпадения = 1/(f_sys / (2 * n * (1 + OCR1A)))

В скетче установлен предделитель на 1024, значит:

Tпереполнения = 1/(32 000 000 / (2 * 1024 * 65536)) = 4,19424 с

Период работы прерывания при совпадении при OCR1A = 9999:

Tсовпадения = 1/(32 000 000 / (2 * 1024 * (1 + 9999))) = 0,64 с

Если например не использовать режим работы таймера прерывание и сбор при переполнении, то подключенный светодиод к D12 (через резистор 200 Ом), будет загораться при совпадении значений счетного регистра и регистра сравнения, а после переполнения счетного регистра и новом совпадении значений счетного регистра и регистра сравнения гаснуть.

void setup() {  

pinMode(12, OUTPUT);  

noInterrupts();  

TCNT1 = 0;  

TCCR1A = 0;  

TCCR1C = 0;  

byte n = 5;  

// clksys / 1 = 1  

// clksys / 8 = 2  

// clksys / 64 = 3  

// clksys / 256 = 4  

// clksys / 1024 = 5  

// [CS12:CS10]  

TCCR1B = n;  

OCR1A = 20000;// 0-65535  

TIMSK1 |= (1 << OCIE1A);

interrupts();

}

void loop() {}

ISR(TIMER1_COMPA_vect){  digitalWrite(12, !digitalRead(12));  }

Если например не использовать режим работы таймера при совпадении значений счетного регистра и регистра сравнения, то подключенный светодиод к D12 (через резистор 200 Ом), будет загораться при переполнении счетного регистра, а после гаснуть при новом переполнении счетного регистра.

void setup() {  

pinMode(12, OUTPUT);  

noInterrupts();  

TCNT1 = 0;  

TCCR1A = 0;  

TCCR1C = 0;

byte n = 5;  

// clksys / 1 = 1  

// clksys / 8 = 2  

// clksys / 64 = 3  

// clksys / 256 = 4  

// clksys / 1024 = 5  

// [CS12:CS10]  

TCCR1B = n;  

TIMSK1 |= (1 << TOIE1);

interrupts();

}

void loop() {}

ISR(TIMER1_OVF_vect){  digitalWrite(12, !digitalRead(12));  }

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

Если установлен бит COM1A0 то состояние на выходе OC1A (D9) меняется на противоположное при совпадении.

void setup() {  

pinMode(D9, OUTPUT);  

noInterrupts();  

TCNT1 = 0;  

TCCR1A = 0;  

TCCR1C = 0;  

byte n = 5;  

// clksys / 1 = 1  

// clksys / 8 = 2  

// clksys / 64 = 3  

// clksys / 256 = 4  

// clksys / 1024 = 5  

// [CS12:CS10]  

TCCR1A = (1 << COM1A0);  

TCCR1B = n;  

OCR1A = 9999;

interrupts();

}

void loop() {}

Режим PWM (ШИМ)

Широтно-импульсная модуляция  (PWM) — процесс управления мощностью методом пульсирующего включения и выключения потребителя энергии.

Основной причиной применения ШИМ является стремление к повышению КПД при построении вторичных источников питания электронной аппаратуры и в других узлах, например, ШИМ используется для регулировки яркости подсветки LED-мониторов и дисплеев в телефонах, КПК и т. п.

По сути выходной PWM сигнал в LGT8F328P это импульсный сигнал с изменяемой длительностью импульсов. Если взять период следования импульсов за 100 %, то длительность импульсов может меняться от 0 до 100%, а так как Timer_1 16 бит, то заполнение длительности импульса периода следования импульса может меняться от 0 до 65535 значений, то есть от 0 до 100%.

Режим FPWM

Режим работы FPWM определяется несколькими регистрами, а в частности регистром захвата ICR1 и регистром сравнения OCR1A.

В регистр ICR1 записывается значение которое сравнивается с счетным регистром TCNT1 и при равенстве происходит изменение состояния  на выводе OC1A (D9), в данном случае появляется лог. 1, в регистре ICR1 указываем максимальное значение (зависит от разрядности).

В регистр OCR1A записывается значение которое сравнивается с счетным регистром TCNT1 и при равенстве происходит изменение состояния  на выводе OC1A (D9), в данном случае появляется лог. 0.

void setup() {  

pinMode(D9, OUTPUT);  

noInterrupts();  

TCNT1 = 0;  

TCCR1A = 0;  

TCCR1C = 0;  

byte n = 1;  

// clksys / 1 = 1  

// clksys / 8 = 2  

// clksys / 64 = 3  

// clksys / 256 = 4  

// clksys / 1024 = 5  

// [CS12:CS10]  

TCCR1A = (1 << COM1A1) | (1 << WGM11);  

TCCR1B = (1 << WGM13) | (1 << WGM12) | n;  

ICR1 = 65535;  

OCR1A = 5000;

interrupts();

}

void loop() {}

Бит COM1A1 делает активным выход OC1A (D9), а биты WGM11 WGM12 WGM13 активируют режим FPWM.

Частота PWM в этом режиме определяется:

Fpwm = f sys / (N * (1 + ICR1))

Если предделитель установлен на 1, а регистр ICR1 имеет значение 65535, то:

Fpwm = 32 000 000 / (1 * (1 + 65535)) = 488,28125 Hz

Аналогично можно использовать выход Timer_1 OC1B (D10), использование которого определяет бит COM1B1, при этом используется регистр сравнения OCR1B.

void setup() {  

pinMode(D10, OUTPUT);  

noInterrupts();  

TCNT1 = 0;  

TCCR1A = 0;  

TCCR1C = 0;  

byte n = 1;  

// clksys / 1 = 1  

// clksys / 8 = 2  

// clksys / 64 = 3  

// clksys / 256 = 4  

// clksys / 1024 = 5  

// [CS12:CS10]  

TCCR1A = (1 << COM1B1) | (1 << WGM11);  

TCCR1B = (1 << WGM13) | (1 << WGM12) | n;  

ICR1 = 65535;  

OCR1B = 1000;

interrupts();

}

void loop() {}

Так же в этом режиме PWM имеется возможность инверсии выходного сигнала. Биты COM1A1 COM1A0 определяют режим работы выходного сигнала.

Читать дальше...