How to read if the key is pressed? keypressed()? Reason:Sprites.

How to read if the key is pressed? keypressed()? Reason:Sprites.

newn01

Member #12,120

July 2010

Hi everyone. I was reading Allegro reference, i have found a function called keypressed(). However, you put in a concrete key inside.

I have also tried using while operators, but the texture just went invisible, when you press a key (movement key). So... I have no good ideas anymore.

That is basically for drawing a steady sprite, when the character is not moving (when key is not being hold down).

Hope i explained it well.

amber

Member #6,783

January 2006

newn01 said:

Hope i explained it well.

No, not really.

I don't understand the specific issue but in general it seems like part of the problem is that you don't have much separation between your input-getting code, your logic processing code, and your drawing code... which is usually not a good thing.

All you'd really have to do is store the sprite's coordinates in variables and draw it at those locations every frame, and only change them when you're pressing a key. Does that help? Sorry, I'm not sure what you're asking.

newn01

Member #12,120

July 2010

Okay, sorry. Let me try to explain:

Yea, i need something like you said: draw sprites only when key is being pressed. Being hold down. When you release the key, i want the character to stay. Not to drawn the sprites. And all i found is keypressed command, in which you cannot tell which key is being pressed. Also, if you do this:

    if(keypressed() == TRUE)
    {
    up();
    down();
    left();
    right();
    }

It just reacts before you press any key. After that it counts as true, even if you are not pressing any keys. And you cannot declared it as FALSE, because keypressed() = FALSE doesn't work. :/

Thomas Fjellstrom

Member #476

June 2000

You can use either readkey() or key[...] to check for key presses.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Kitty Cat

Member #2,815

October 2002

Use readkey() to read it, otherwise it will continue to return true. And don't mix the key[] array with the keypressed()/readkey() APIs, because they serve two different purposes (keyboard state, vs key events).

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

newn01

Member #12,120

July 2010

Okay, and what about those ascii codes? I couldn't find any on the google of arrow keys...

And for scancodes, i don't even heard about such.

There are commands from them to chars. But to them from chars - nop. :/

And you cannot use readkey(); with normal codes like KEY_UP. :/

LennyLen

Member #5,313

December 2004

newn01 said:

Okay, and what about those ascii codes? I couldn't find any on the google of arrow keys...

That's because ASCII has nothing to do with mapping a code to a key; it only maps codes to characters.

Quote:

And you cannot use readkey(); with normal codes like KEY_UP

Yes you can. The manual entry for readkey() even shows you how to.

Tobias Dammers

Member #2,604

August 2002

newn01 said:

I have also tried using while operators, but the texture just went invisible, when you press a key (movement key). So... I have no good ideas anymore.

A few things.
1. while is not an operator, it's a program flow control construct.
2. You didn't provide any code. As a rule of thumb, try to reduce the problem you're experiencing to 10 to 100 lines of code (ideally a code sample that still compiles and runs by itself). If you manage to come up with 10 lines of code demonstrating the problem, people will find it, and they will tell you how to fix it.
3. From what you're telling, I can only guess, but I bet you don't know how to set up the basic program structure for a game (any game). The very least you need is a main loop with timing, and three functions for the things happening in the main loop: input, logic, drawing. Flesh this out first - the general idea is that the input function reads input (keys, joystick, mouse) and stores the result somewhere; the logic then picks up the input, and updates the game's state (where things are, who is alive and who is not, which objects collide and what to do about it, etc.); the drawing function finally reads the game state and uses it to draw a frame. If you have anything like this in your code:

if (key[KEY_UP]) {
  draw_sprite(screen, player, player_x, player_y - 1);
}

...then you're doing it wrong.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Kayle OTS

Member #11,638

January 2010

Direct C+P of the main.cpp file of my physics engine practice program.

#SelectExpand
  1#include "map.h"
  2
  3int s = 0;
  4
  5void inc();
  6
  7void main()
  8{
  9  allegro_init();
 10  set_color_depth(24);
 11  set_gfx_mode(GFX_SAFE, 360, 270, 0, 0);
 12  install_keyboard();
 13  //*****************************
 14  //****Character Declaration****
 15  //*****************************
 16  character rei;
 17  //***********************
 18  //****Map Declaration****
 19  //***********************
 20  MAP level;
 21
 22  while (!key[KEY_ESC]) //This is the main game loop
 23  {
 24    clear_keybuf(); //needed
 25
 26    //Move.
 27    //Check dash?
 28    if (key[KEY_C] && rei.candash()) //input
 29      rei.dash(true); //logic
 30    if (!key[KEY_C]) //input
 31      rei.dash(false); //logic
 32
 33    if (key[KEY_RIGHT]) rei.moveR(s); //input + logic
 34    else if (key[KEY_LEFT]) rei.moveL(s); //input + logic
 35    else rei.standspr(s); //input + logic
 36
 37    //jump?
 38    if (key[KEY_UP] && rei.can_jump()) //input
 39    {
 40      rei.jump(s); //logic
 41      rei.setjump(false);
 42    }
 43    if (!key[KEY_UP]) //input
 44      rei.setjump(true); //logic
 45
 46    rei.go(s); // logic
 47    level.check_all_cols(&rei); //collision checking (logic)
 48
 49    acquire_screen(); //now all of this is drawing
 50    //Clear previous screen
 51    rectfill(screen, 0, 0, 360, 270, makecol(0,0,0));
 52    //draw map
 53    level.draw(rei.getx(), rei.gety());
 54    //draw sprite
 55    draw_sprite(screen, rei.getsprite(), rei.getdispx(), rei.getdispy());
 56    release_screen();
 57    inc(); // Increment.
 58  }
 59
 60  //end.
 61  allegro_exit();
 62
 63}   
 64END_OF_MAIN()
 65
 66void inc()
 67{
 68  rest(10);
 69  s++;
 70}

It's very messy and unprofessional because it is just a test - I would normally have a game class, which in turn would contain a massive amount of information (an array of characters/creatures that would all run their "go" functions sequentially).

The moveR, moveL, jump, etc. functions do not actually do anything to the screen, all they do is change Rei's (the main character's) velocity in the appropriate direction.

Then, when I get to "go", Rei actually moves; I take her velocities and add them to her x and y position. Then I check collisions to make sure I haven't moved her into any invalid places, and if I have, I put her back where she belongs (at the edge of the wall or on the top of the floor, etc).

Only after all of that is done do I bother drawing sprites.