# (I don't actually have a gamepad with a trackball on it. So this code &nbnbsp self.joystick_config = ( 'is_hat', hat_index, 'y', 1) 5 and not self.is_hat_used(hat_index, 'y', 1):
5 and not self.is_hat_used(hat_index, 'x', 1): # if the button is configured to a trackball direction. # if the button is configured to a hat direction. Pushed = _button(config)Įvents.append(InputEvent(button, pushed)) # if the button is configured to an actual button. # determine what something like "Y" actually means in terms of the joystickĬonfig = self.joystick_config.get(button) # And this is where each configured button is checked. If event.type = KEYDOWN or event.type = KEYUP:Įvents.append(InputEvent(button, key_pushed_down)) # This is where the keyboard events are checked If event.type = QUIT or (event.type = KEYDOWN and event.key = K_ESCAPE): # This is basically a proxy method for pygame's event pump and will likewise return # then the PyGame window will start to lock up. # This will pump the pygame events. If this is not called every frame, # button is a string of the designation in the list above # everything else. When escape is pressed or the user closes the window via its # want to configure on the joystick. That's why it's wired separately from # that event raised when the user presses escape which is not something you # Quitting the window is raised as an input event. And typically you also want # This is a list of joystick configurations that will be populated during the # This dictionary will tell you which logical buttons are pressed, whether it's # keyboard. But that's getting fancy for a simple tutorial.
# probably copy the same sort of system I use for the joystick configuration for the # here in this mapping. If you wanted the keyboard keys to be configurable, you could # If you would like there to be a keyboard fallback configuration, fill those out # Either way. Up to you. You could change them altogether if you want. # Or you could pretend that these were XBox button layout designations. # and are only used internally to consistently identify buttons. # I like SNES button designations. My decision to use them are arbitrary # This comment is actually longer than the class definition itself. # and the key field is one of the strings in the button list listed below # This serves as a proxy to pygame's event object # The individual event object that is returned If you have the right idea, you should change this line. I used the SNES/XBox controller designations as an example (up, down, left, right, start, A, B, X, Y, L, R) but it's probably most wise to give these names that contextually make sense for your game. It's not important what these names are since they are only used as consistent identifiers for the buttons. For this reason, the InputManager can have arbitrarily named buttons. What does a tab have to do with firing a bazooka in a game? Nothing, really. PyGame event names are constants that map to the keyboard and have names like "K_TAB". The button names I use are also different than the PyGame event names. It's not a good layout for scene or graphics management.
#Pygame key codes code#
I tried to keep this code fairly minimalistic.
#Pygame key codes how to#
Much of the code here is irrelevant but the important part is it demonstrates how to use the InputManager not only for game play, but also for configuring the joystick buttons. My arbitrary game with sample code: This is a simple game where you have a blue circle move around the screen according to the arrow keys pressed or the game pad directions pressed.Both of these methods will take into account both the joystick and keyboard and work seamlessly together so you can safely fall back to keyboard input when a joystick is not present. It features a get_events method that acts as a proxy to PyGame's get_events method. The InputManager: This chunk can basically be copy and pasted into your code.This looks like a lot of code, but it mostly falls into 2 main chunks. The latter solution is what I've done here. You'll either write complicated stuff in your main game loop during the input phase turning your core engine into spaghetti code, or you need to write an abstraction layer that makes the keyboard and joystick events work seamlessly in the same fashion that the rest of your code can easily process. If you wanted to create a game where you could use a joystick but fall back to a keyboard if a joystick was not present, then you're in for some fun times. You can poll to see if a button is pressed, and that's it. It only serves as a small rickety rope bridge to the underlying hardware. One annoying thing about PyGame is the joystick API doesn't really give you much high level flexibility.
0 kommentar(er)
