You might recall this from two posts ago:
Code: Select all
while(true) {
handlePlayerInput()
updateGameState()
renderGraphics()
}In some games, we can tightly couple the player input with the game state, so that it looks more like this:
Code: Select all
while(true) {
handlePlayerInputAndUpdateGameState()
renderGraphics()
}Code: Select all
boolean isAPressed = Gdx.input.isKeyPressed(Keys.A);Code: Select all
public class MyInputProcessor implements InputProcessor {
public boolean keyDown (int keycode) {
// your code here
}
public boolean keyUp (int keycode) {
// your code here
}
...
Now, you might look at this and think, "It looks like polling has less overhead and more flexibility. Why would you ever use InputProcessor?" This mostly boils down to InputProcessor handling more events. Polling lets us check if a key is pressed, which is great. It also offers isKeyJustPressed, which tells us if a key is newly pressed. It does not tell us when a key is released, though, and InputProcessor does. InputProcessor also gives better exposure to mouse events such as the scroll wheel.
Like the above title suggests, the game now accepts keyboard input: you can wander around the demo map. This is great news, and at this pace, the game will be done in approximately 20 years.
Ha! I am only half serious. But in other news, I realized as I was doing this that I need to adjust the camera. I had it set back by half a tile, which looked nice until you turned 90 degrees, at which point it was apparent that you were between tiles.
I tried moving the camera all the way back up, which fixes the issue of being between tiles, but now it looks like you have your nose smooshed up against the wall when you're right next to it. The fix here was to have the camera "float" behind the player's current position, similar to how it was before, but adjusting when the player rotates.
