A key press funtion

hi there,

im making a small game which uses to getch() for key press

the code is as follows

Code:

---

if(getch() == KEY_DOWN)
{
 move object down
}
if(getch() == KEY_UP)
{
move object up
}

---

the problem is when the code reaches getch() the program doesnt move onrward until u actually press something.

is there a similar function that gets ur key press but doesn't cause the program to loop on the function until a key is pressed?

ty.

You used to use kbhit() to detect if a key had been pressed. Then if one had you would use getch to get the keycode of the key that was pressed.

However inside of Windows this is different. It's also different inside of DirectInput which IMO is much closer to the old school interrupt 09h keyboard interrupt handlers than anything.

Inside of DirectInput you can either choose polling mode or buffered mode. Polling mode is usually used for real-time games. What happens is when you init DirectInput you give it a 256 char array each representing a specific keypress. During a poll you first tell DirectInput to update which causes it to fill the keystate buffer with the correct data. If keystate[key_code] is non-zero then the key is down, else it is up. So checking keypresses becomes:

Code:

---


if (keystate[key_code])
{
  ..Do something
}

---

And for extended keys or key combos

Code:

---

if (keystate[key_code] && keystate[DK_LCTRL))
{
  ..Do something
}

---

This is how most keyboard handlers work which is why I showed you the basics of it.

For your situation and provided you have the correct headers:

Code:

---

int hit = kbhit();

if (hit)
{
  int ch = getch();

  if (ch == key_code)
  {
    ..do something
  }
}

---

However this code is old, deprecated, not completely valid under XP or protected mode, and still won't work perfect since it relies on the OEM interrupt 09h handler which basically sucks.

You can also grab data from port 60h however if you don't do some housekeeping you will soon encounter a keyboard buffer overflow which causes a very annoying beeping to occur. Please note that both port 60h and kbhit() or any combination therein will NEVER produce a robust keyboard handler. The ONLY way to have robust keyboard handler is to write a new interrupt 09h keyboard handler. The default BIOS implemented 09h keyboard handler is not designed for time critical keyboard functionality. It is also extremely cryptic when it comes to multiple keypresses and the like. It is essentially useless for games. Also under Windows XP it is possible that Windows has hooked this already and reimplemented their own. In short you cannot rely on kbhit(), getch(), or port 60h in Windows XP or in a Windows XP DOS session.

Furthermore since interrupts are not allowed in Windows and since Windows would frown on you trying to reimplement the 09h handler your best bet is to use Windows built-in messaging scheme for keyboard handling or use DirectInput. DirectInput is far better than Win32 but with the caveat that you must know how to use it.

You could use the kbhit function to test to see if a key has been hit and you could then use a switch on a single getche to do the job.

Code:

---

if (kbhit()) //see if key has been hit
{
    switch (getche()) //check to see what key was hit
    {
        case 'a': //if the key was 'a'
            //...
            break;
        //etc...
    }
}

---

A switch implies keys are mutually exclusive. That is it implies that only one key press at a time can be handled and no key combos are supported. This is a bad idea.