Hi Guys,
I just want to ask if can I check for "KEY"(keyboard) that is HOLD/PRESSED for a long time, because I am to create a clone of breakout with air hockey for 2 different human players.
Here's the list of my concern:
1. Do I need other/ 3rd party library for KEY HOLDS?
2. Is multi-threading needed? I don't know anything about this multi-threading stuff and
I don't think about using one(I'm just a NEWBIE).
3. One more thing, what if the two players pressed their respective key at the same time,
how can I program to avoid error or worse one player's key is prioritized first before
the the key of the other.
example:
Player 1 = W for UP & S for DOWN
Player 2 = O for UP & L for DOWN
(example: W & L is pressed at the same time)
Great thanks for help.
PS: I use GLUT for the visuals of the game.
0
PROBLEM - Block breaker with air hockey PLAYED as 2 HUMAN PLAYERS
Started by nightrobin, Oct 29 2012 12:20 PM
algorithm opengl c++ input
2 replies to this topic
#2
-
- Moderators
-
- 1718 posts
Senior Member
- LocationCyberspace
Posted 29 October 2012 - 03:21 PM
I don't remember the specifics of how GLUT manages keyboard input, but in general:
1. No, you shouldn't need a 3rd party library. GLUT already supports this. See this.
2. No, you don't need to thread this. Nothing you do in the keyboard event callback should delay the processor. AI and physics are examples of things you would offload to a separate thread. Window management and user input should be handled in the same thread (typically the main thread).
3. Keys are sent in the order they were pressed on the keyboard. All you have to do is create the necessary logical states for each of your player objects and update them as keyboard input is received. You only have to check for one key-down and one key-up event. I'm not sure which events GLUT is hooked into, but it's possible you may receive multiple key-down events on the last keyboard key that is held down by the user. The speed of this is actually controlled by your OS (check your keyboard control panel). Nevertheless, you should ignore this behaviour. Game logic should not depend on repetitive key events sent from the OS. On the first press, update a boolean flag or logical state. When that key is released, once again update your flag or state.
1. No, you shouldn't need a 3rd party library. GLUT already supports this. See this.
2. No, you don't need to thread this. Nothing you do in the keyboard event callback should delay the processor. AI and physics are examples of things you would offload to a separate thread. Window management and user input should be handled in the same thread (typically the main thread).
3. Keys are sent in the order they were pressed on the keyboard. All you have to do is create the necessary logical states for each of your player objects and update them as keyboard input is received. You only have to check for one key-down and one key-up event. I'm not sure which events GLUT is hooked into, but it's possible you may receive multiple key-down events on the last keyboard key that is held down by the user. The speed of this is actually controlled by your OS (check your keyboard control panel). Nevertheless, you should ignore this behaviour. Game logic should not depend on repetitive key events sent from the OS. On the first press, update a boolean flag or logical state. When that key is released, once again update your flag or state.
http://www.nutty.ca - Being a nut has its advantages.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
