The simplest game on Ardruino with a display 1602 - Part # 1

The simplest game on Ardruino with a display 1602 - Part # 1
 
That's what we should get, well, he still knows how to jump, walk and beat the evil cacti that attack him, but we'll come to it step by step :)
 
 

PART # 1 of the base


 
I ordered myself arduino, "so-so toy" I thought, the kit is small (for testing), which later regretted. I wanted to open up the potential, but because of the lack of additional modules this did not work out, I had to experiment, cut the ardruino to the security system and watched how the sensors do their work, then decided to make an audible alarm (using the primal harness from the kit), so to say, the dogs learned loudly or suddenly barking :) and then my hands reached the display of 1602. "Hmm this is a real display," I thought, but then I was disappointed to learn that he devoured almost half of all contacts on the ardruino itself. After digging I found a strange fee in the "i2C" bundle and very suspicious was THAT! That the number of holes coincided with the number of pimples on the display. "Hmm, it's not so simple " I thought, and decided to solder them. A little later I realized that I did the right thing and now my display eats only two channels. I started to study what kind of display it is and what it does. After studying enough material, I learned that the display is purely textual, but about a miracle! It can process 8 new characters, with dimensions of 5x8 pixels. Well, let's start writing the game! First, it is necessary to figure out what kind of game it will be, decided to make a likeness of the dinosaur gougle 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, did not have to think long. I took the IR remote from the kit.
 
 

 
 
"That's the joystick," I muttered suspiciously to myself, thinking about the delay from the remote, the clarity of the IR sensor and indeed the adequacy of this idea, but there was nothing to do, I could teach ardruino to work with the keyboard for the company, but it was really lazy do it. So I proceeded to write down the codes of the console, which would work with them in the future. The code for the microcontroller here is the simplest:
 
 
"------------------------------------------------- ------------------------- "
//Download the IRremote library
#include
IRrecv irrecv (A0) //enable the analog port for the
sensor. Void setup ()
{
Serial.begin (9600); //set the com port speed to
Irrecv.enableIRIn (); //start the sensor itself
}
Void loop ()
{
If (irrecv.decode (& result)) //if the sensor sees any IR signal, then the condition is fulfilled
{
Serial.printIn (result.value, HEX); //read the code from the console and output it to the port logs
}
}
"------------------------------------------------- ------------------------- "

 
After filling it in ardruino and connecting it as it should, we can start recording from the log port of the tsirki, after pressing the buttons of the IR device. But here I just want to clarify how to connect the IR sensor.
 
 
If we look at the sensor, we see three legs, the left (analog signal), the middle (mass), right (plus 5V).
 
 

 
 
Since I had no idea how this would work at all, I started experiments. At first I made sketch code step by step, through (delay (time)) at first I did not suspect that this is a bad idea :)
 
What is the main cant. This microcontroller can not do multitasking. He considers the code from the top down, passing through all branches and functions and after completion, it starts anew. And now, when we have a lot of these "delay" in the code, we begin to notice obvious delays. By the way, yes, why do we need a lot of "delay" at all. When we make a game, we begin to increase the number of checks and interactions. 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 at 0.8f seconds in the air, that's the whole game and hangs on these 0.8f seconds. "Cant" I thought, and began to think about the solution. The solution was found quickly. The microcontroller itself can read the code quickly enough from the beginning to the end, (if it does not interfere) and also he can count the time from the beginning of its inclusion. This is what we need. Now we just create variables that will store the time for this or that action and a variable that compares the difference from how much time is now and how much to activate the code. Ardruino for a second, takes 1000 milliseconds, quite conveniently. Here is a fragment when it would have become clearer:
 
 
    "------------------------------------------------- ------------------------- "
//this example code fragment, clears the screen, roughly speaking this is our frame refresh rate
//the variables are
long ClearTime = 150; //150 = ???f seconds or ~ 6 frames per second
long ClearTimeCheck = 0; //check, will change while the code is working
long currentMillis = 0; //the timer variable is
void loop ()
{
currentMillis = millis (); //timer variable = time in milliseconds
}
void clearscreen () //screen update function
{//
if (currentMillis - ClearTimeCheck> = ClearTime) //if (working time - check is greater than or equal to ???f then the condition is fulfilled
{
ClearTimeCheck = currentMillis; //align the check to zero our counter
lcd.clear (); //perform the action itself, namely clean the screen
}
}
"------------------------------- ------------------------------------------- "
.
.
 
Not hard, right?
 
 
After rewriting all the code in a new way, the game began to work faster and more clearly, simulating multitasking actions :) I went somewhere far. After all, we still need to make a character, a kind of interface and animation. Since we can create only eight new characters, we need somehow to bluff it all by clever. On the display, I do not plan a lot of objects, so I can do it so that I have just eight active objects on the screen for one code processing. What will it be? Well, of course the main character, the blow, the villain, the heart and the health indicator. To begin with, this is enough. Yes, and I have three more unique objects in stock.
 
 
The main character will look like this:
 
 
 
 
The process of writing a new character, I produce a binary code (I'm so comfortable)
 
it will look like this:
 
 
01110
 
01110
 
00100
 
01110
 
10101
 
00100
 
01110
 
01010
 
 
If you look closely, then from the units, we'll see our character, but whatever he does not stand idle, let's make him an animation.
 
 
 
 
Now, to our code, add one more set of binary digits, namely this:
 
 
00000
 
01110
 
01110
 
00100
 
11111
 
00100
 
01110
 
01010
 
 
How to make the animation on this display, I indicated the logic above, but now let's move on to practice, at the moment, place it on 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. It's easier than it seems:
 
 
    "------------------------------------------------- ------------------------- "
#include
#include
LiquidCrystal_I2C lcd (0x3F, 16.2); //Set the display to
long AnimatedTime = 300; //the animation speed of the main character is
long AnimatedTimeCheck = 0; //check the speed (as in the previous example)
int AnimPlayer = 1; //check the state of the animation
int GGpozX = 8; //position the horizontal line
int GGpozY = 1; //position vertical 1 is the 2nd row and 0 is the first line of
long currentMillis = 0; //the timer variable is
//Create variables of our objects, they can be as many as you like, they are variables :)
enum {SYMBOL_HEIGHT = 8};
byte Player_1[SYMBOL_HEIGHT]= {B0111? B0111? B0010? B0111? B1010? B0010? B0111? B0101?}; //sprite 1
byte Player_2[SYMBOL_HEIGHT]= {B0000? B0111? B0111? B0010? B1111? B0010? B0111? B0101?}; //sprite 2
void setup ()
{
lcd.init ();
lcd.backlight (); //Turn on the display backlight
loop ();
PlAn ();
}
void loop ()
{
if (AnimPlayer! = 50)
{//this is a test of the character's death, so do not score yourself yet :)
//--------------------------- Animated ->
//-------------------- Player ->
if (AnimPlayer == 1) {lcd.createChar (? Player_1);} //if the state is 1 then sprite 1
//(lcd.createChar (number of the memory cell from 0 to ? name of the variable sprite))
if (AnimPlayer == 2) {lcd.createChar (? Player_2);} //if state 2 then sprite 2
}
//--------------------------- <- Animated
currentMillis = millis (); //timer variable = time in milliseconds
PlAn ();
}
void PlAn ()
{
if (AnimPlayer == 1) //if state 1 then
{
lcd.setCursor (GGpozX, GGpozY); //put the "cursor" on the point of coordinates of our hero
lcd.write (0); //draw the sprite from the memory location to the place where the "cursor" is
}
if (AnimPlayer == 2) //similarly to # 1
{
lcd.setCursor (GGpozX, GGpozY);
lcd.write (0);
}
if (currentMillis - AnimatedTimeCheck> = AnimatedTime) //check the time as before
{
AnimatedTimeCheck = currentMillis; //Well, it's already clear
if (AnimPlayer == 2) {AnimPlayer = 1; return;} //if position ? we do 1 and stop this code fragment
if (AnimPlayer == 1) {AnimPlayer = 2;} //if 1 then 2 and it does not make sense to stop, so we do not overload the memory with extra code, we have very little
there.}
}
"------------------------------------------------- ------------------------- "

 
After launching, we see the Cuckoo, which is in the center of the screen, on the 2nd line and sways, so to speak.
 
 
Conclusion: today I told how to learn the data through the infrared port, how to bypass the delay of the microcontroller code work and how to make the initial animation.
 
 
The rest will soon :) write a lot more, so I'll see how it will generally be interesting to you and if so, then tomorrow I'll start writing the sequel.
 
 
Thank you all for your attention, chao-cocoa!
+ 0 -

Add comment