That's what we should have, well, he still knows how to jump, walk and beat the evil cacti that attack him, but we will come to this step by step :)

PART # 1 Basics

I ordered myself an arduino, “so-so toy” I thought, a small kit (for testing) which I later regretted. I wanted to unlock the potential, but because of the lack of additional modules, this did not work out, I had to experiment, tweaked the arduino to the security system and watched the sensors do their work, then decided to make an audible alarm (using the supplied tweeter), loudly or not Suddenly bark :) and then my hands reached the display 1602. "Hmm ... it's a real display," I thought, but then I was disappointed to learn that he was eating almost half of all contacts on the arduino itself. Having rummaged, I found a strange motherboard in the “i2C” package and it was very suspicious THAT! That the number of holes coincided with the number of pimples on the display. "Hmm, not so simple ..." I thought, and decided to solder them. A little later, I realized that I had done the right thing and now my display eats up only two channels. I began to study what kind of display it is and what it can do. After examining a sufficient amount of material, I learned that the display is purely textual, but what a miracle! It can handle 8 new characters, dimensions of 5x8 pixels. Well, let's start writing a game! First, it is necessary to think of what the game will be, I decided to make a semblance of a diner, Google Chrome, but with a couple of chips, so to speak, for a start, I think it will come down :) but you still have to manage something, and multi-button, you don’t have to think long. I took the IR remote from the kit.


')
“That's the joystick” I muttered suspiciously under my breath, thinking about the delay from the console, the clarity of the IR sensor, and indeed the adequacy of this idea, but there was nothing to do, I could teach arduino to work with the keyboard for the computer, but it was really lazy do it. So I proceeded to write the remote control codes to work with them in the future. The code for the microcontroller is the simplest:

"--------------------------------------------------------------------------" //   IRremote #include <IRremote.h> decode_results results; IRrecv irrecv (A0); //      void setup () { Serial.begin(9600); //   com  irrecv.enableIRIn(); //    } void loop () { if (irrecv.decode( &results )) //      ,    { Serial.println( results.value, HEX ); //          irrecv.resume(); //            } } "--------------------------------------------------------------------------" 

The code of the remote control signal looks like this: “FF18E7” you will of course have other codes, but you should understand the essence, and when you make an appeal to this code, we finish “0x” in the beginning and we will succeed (0xFF18E7).

After filling this into the arduino and connecting it as it should, we can start recording from the tsiforki port log, after pressing the buttons of the IR device. But just here I want to clarify about how to connect the IR sensor.

If we look at the sensor, we see three legs, left (analog signal), average (weight), right (plus 5V).



Since I still had little idea how this would work at all, I began experiments. At first I made the sketch code step by step, through (delay (time)) at first I didn’t suspect that it was a bad idea :)
What is the main joint. This microcontroller does not know how to multitask. It counts the code from top to bottom, passing through all branches and functions and after completion, it starts again. And so, when we have a lot of these “delays” in the code, we begin to notice obvious delays. By the way, yes, why do we need a lot of “delay”? When we make a game, the number of checks and interactions begins to grow. For example, the enemy is moving towards us and I want to jump over it, I press the “jump” and according to the plan, I have to hang in the air, for example, for 0.8f seconds in the air, that's the whole game and hangs for these 0.8f seconds. “Cant” I thought and began to think about the decision. The solution was found quickly. The microcontroller itself reads the code quickly enough from beginning to end, (if it doesn’t interfere with it) and also knows how to count the time from the beginning of its inclusion. This is what we need. Now we just create variables that will save time for one or another action and a variable that checks the difference from what time it is and how much time to activate the code. Arduino for a second, takes 1000 milliseconds, quite convenient. Here is a snippet when it becomes clearer:

 "--------------------------------------------------------------------------" //    ,  ,        //  long ClearTime = 150; // 150 = 0.15f   ~6    long ClearTimeCheck = 0; // ,       long currentMillis = 0; //   void loop () { currentMillis = millis(); //   =    } void clearscreen () //   { // if (currentMillis - ClearTimeCheck >= ClearTime) //  (  -     0.15f    { ClearTimeCheck = currentMillis; //       lcd.clear(); //   ,     } } "--------------------------------------------------------------------------" 

Not hard, right?

After rewriting the whole code in a new way, the game began to work quickly and clearly, simulate multitasking actions :) I’ve come far. After all, we still have to make a character, a kind of interface and animation. Since we can create only eight new characters, we need to somehow flush it all over smart. I don’t plan on doing a lot of objects on the display, therefore, I can make it so that I would have eight active objects on the screen in one code processing. What will it be? Well, of course the main character, punch, villain, heart and health indicator. Enough to start with. Yes, and I have three more unique objects in stock.

The main character will look like this:



The process of entering a new character, I produce a binary code (I feel so comfortable)
it will look like this:

01110
01110
00100
01110
10101
00100
01110
01010

If you look, then from one, we will see our character, but that he would not stand idle, let's make him an animation.



Now to our code, add another set of binary digits, namely this:

00000
01110
01110
00100
11111
00100
01110
01010

How to make an animation on this display, I indicated the logic above, and now let's move on to practice, at the moment, place it at the center of the screen, and make it just stand still, and remember, our task is to use only one memory cell for two animation sprites. This is easier than it seems:

 "--------------------------------------------------------------------------" #include <Wire.h> #include <LiquidCrystal_I2C.h> LiquidCrystal_I2C lcd(0x3F,16,2); //   long AnimatedTime = 300; //     long AnimatedTimeCheck = 0; //   (    ) int AnimPlayer = 1; //    int GGpozX = 8; //   int GGpozY = 1; //   1  2   0    long currentMillis = 0; //   //   ,     ,    :) enum { SYMBOL_HEIGHT = 8 }; byte Player_1[SYMBOL_HEIGHT] = {B01110,B01110,B00100,B01110,B10101,B00100,B01110,B01010,}; //  1 byte Player_2[SYMBOL_HEIGHT] = {B00000,B01110,B01110,B00100,B11111,B00100,B01110,B01010,}; //  2 void setup() { lcd.init(); lcd.backlight();//    loop(); PlAn(); } void loop() { if (AnimPlayer != 50) { //    ,       :) // --------------------------- Animated -> // -------------------- Player -> if (AnimPlayer == 1){lcd.createChar(0, Player_1);} //  1   1 //(lcd.createChar(    0  7,   )) if (AnimPlayer == 2){lcd.createChar(0, Player_2);} //  2   2 } // --------------------------- <- Animated currentMillis = millis(); //   =    PlAn(); } void PlAn () { if (AnimPlayer == 1) //   1  { lcd.setCursor(GGpozX, GGpozY); //  ""      lcd.write(0); //          "" } if (AnimPlayer == 2) //  №1 { lcd.setCursor(GGpozX, GGpozY); lcd.write(0); } if (currentMillis - AnimatedTimeCheck >= AnimatedTime) //       { AnimatedTimeCheck = currentMillis; //     if (AnimPlayer == 2){AnimPlayer = 1; return;} //  2   1      if (AnimPlayer == 1){AnimPlayer = 2;} // 1  2           ,         } } "--------------------------------------------------------------------------" 

After the launch, we see a little person who is in the center of the screen, on the 2nd line and sways, so to speak.

Conclusion: today I told how to find out the data through the IR port, how to bypass the delay of the microcontroller code and how to make the initial animation.

The rest is coming soon :) there is still a lot of writing, so I’ll see how it will be interesting to you at all and if so, I’ll start writing the continuation tomorrow.

Thank you all for your attention, Chao-Cocoa!

The second part of the article -> habr.com/post/425367