31
Window / Handling User Input
« on: April 21, 2011, 03:28:07 am »
The input class, internally, is functionally equivalent to your class except that the input class does not register callback functions. Instead, the input class can be queried for the state of an input by calling the appropriate function. Here's the code to show you just how equivalent they are.
Futhermore, SFML runs the OnEvent callback of the Input class always. This means that you always have the SFML input manager running even when you're not using it. It's unnecessary to have two implementations of the same thing running at the same time. Even if you want to create your own input manager for portability to other input managing libraries, you should simply rebind the functions of your input manager to use SFML's input manager. You won't be able to use callback functions like this, but instead, just give the objects in your application an update method that is run every frame and checks for it's own input. Those callback functions add some extremely minor overhead too that is unnecessary. Your method doesn't have any code encapsulation benefits over my method either. Both implementations make classes fully aware of what input they're going to receive. The same amount of internal information is exposed.
Code: [Select]
bool Input::IsKeyDown(Key::Code key) const
{
return myKeys[key];
}
void Input::OnEvent(const Event& event)
{
switch (event.Type)
{
// Key events
case Event::KeyPressed : myKeys[event.Key.Code] = true; break;
case Event::KeyReleased : myKeys[event.Key.Code] = false; break;
// Mouse event
case Event::MouseButtonPressed : myMouseButtons[event.MouseButton.Button] = true; break;
case Event::MouseButtonReleased : myMouseButtons[event.MouseButton.Button] = false; break;
// Mouse move event
case Event::MouseMoved :
myMouseX = event.MouseMove.X;
myMouseY = event.MouseMove.Y;
break;
// Joystick button events
case Event::JoyButtonPressed : myJoystickButtons[event.JoyButton.JoystickId][event.JoyButton.Button] = true; break;
case Event::JoyButtonReleased : myJoystickButtons[event.JoyButton.JoystickId][event.JoyButton.Button] = false; break;
// Joystick move event
case Event::JoyMoved :
myJoystickAxis[event.JoyMove.JoystickId][event.JoyMove.Axis] = event.JoyMove.Position;
break;
// Lost focus event : we must reset all persistent states
case Event::LostFocus :
ResetStates();
break;
default :
break;
}
}
Futhermore, SFML runs the OnEvent callback of the Input class always. This means that you always have the SFML input manager running even when you're not using it. It's unnecessary to have two implementations of the same thing running at the same time. Even if you want to create your own input manager for portability to other input managing libraries, you should simply rebind the functions of your input manager to use SFML's input manager. You won't be able to use callback functions like this, but instead, just give the objects in your application an update method that is run every frame and checks for it's own input. Those callback functions add some extremely minor overhead too that is unnecessary. Your method doesn't have any code encapsulation benefits over my method either. Both implementations make classes fully aware of what input they're going to receive. The same amount of internal information is exposed.