Jump to content
  • Advertisement
Sign in to follow this  

Input Mapping

This topic is 2030 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am struggling to map inputs from different devices to actions (i.e jump).  Axes are giving me the majority of the issue.


I have started by creating an Action class.  The idea was Action can bind one action to one device button/axis by calling fcn Add().  The game code decides what device is active, so correct usage of Add() is left to the user.


The usage would be like this.


Action jump;



jump.Add(sf::Joystick::Axis::Y);               // Problem


The problem is an axis is not a button.  An axis has two max ranges and a button has one.  Should I add another thin layer to differentiate between this.  For example, Joystick::Axis::YMin and Joystick::Axis::YMax.  Or am I in this position, because of poor design choices?  Maybe I should not be trying to treat axes and buttons as the same.


I have included Action.h below, because I wanted to get some feedback.  I am concerned my approach may be incorrect.  Particularly, my attempt to hold each devices input type.  I have read a number of articles (including this one here at gamedev.net) , but the topic of input mapping seems to be glossed over.

class Action : public Event
   enum Type
      Trigger,  // one time use
      RealTime, // holds state (poll it)
      Range,    // axis 

   Action(Type type, const Event& gameEvent);

   void Add(sf::Keyboard::Key key);
   void Add(sf::Mouse::Button button);
   void Add(sf::Vector2i cursor);
   void Add(unsigned int button);
   void Add(sf::Joystick::Axis axis);

   void Remove(sf::Keyboard::Key key);
   void Remove(sf::Mouse::Button button);
   void Remove(sf::Vector2i cursor);
   void Remove(unsigned int button);
   void Remove(sf::Joystick::Axis axis);

   void HandleEvent(const sf::Event inputEvent);

   virtual SendEvent(); // inherited from Event

   const Type mType;
   const Event mGameEvent;

   sf::Keyboard::Key mKeyboardKey;
   sf::Mouse::Button mMouseButton;
   sf::Vector2i mMouseCursor;
   unsigned int mJoystickButton;
   sf::Joystick::Axis mJoystickAxis;

   static std::vector<Action*> mInputMapping;


Share this post

Link to post
Share on other sites

You need to differentiate some things. A keyboard button, a mouse button, a joystick button, … usually has a stable inactive state and a momentary active state. It is momentary because the user needs to actively hold it. The caps lock key, num lock key, … can be interpreted so, too, but usually they are seen with a stable inactive and a stable active state. Some buttons on joysticks and joypads may show such a toggle behavior, too. Toggling can also be emulated by momentary push buttons: Each second push enables or disables, resp., a binary state.


If you wish you can interpret buttons as absolute axes, too. E.g. such an axis ranges from 0 for inactive to 1 for active with no valid values in-between. That would mean that you could use a value besides the axis of interest, e.g.

     jump.Add(sf::Keyboard::Key::Space, 1);

     jump.Add(sf::Joystick::Axis::Y, 1);

(don't know whether the above code is valid, but you see what I mean).


However, an action like jump is probably not state but transition oriented. I.e. the Action is triggered due to the state change from inactive to active (or perhaps active to inactive, if you wish so). Another action like crouch is indeed state oriented. A possibility is to denote the previous as well as the current value of the axis. The preceding transition triggers the beginning and keeping the state continues it, like e.g. here:

    kneelDown.Add(sf::Keyboard::Key::Space, 0, 1);

    standUp.Add(sf::Keyboard::Key::Space, 1, 0);

With a state in the animation system you usually don't need to detect the continuing state from input, but if you wish you could do so, too:

    crouch.Add(sf::Keyboard::Key::Space, 1, 1);


Things get even more complicated if you need to support input combos. This can be handled by not only having alternative "add" methods but also one for declaring a temporal dependency.


You may further need to support relative continuous axes (e.g. mouse movement), absolute continuous axes (e.g. analog joystick), or multi level states. This could be done be having other input translators besides Action. Obviously, these classes differ in what kind of input devices or input device emulation can be configured for use.

Share this post

Link to post
Share on other sites

The article you linked specifically deals with precisely this problem.


You're missing a layer. There should be inputs from actual devices, a mapping layer, and then the layer that actually responds to events/input axes from the mapping system.



The article should have code linked that gives a concrete example of the architecture.

Share this post

Link to post
Share on other sites

Here are the three layer summaries from the article.


1. The first layer gathers raw input data from the hardware, and optionally normalizes ranged inputs

2. The second layer examines what game contexts are active, and maps the raw inputs into high-level actions, states, and ranges. These are then passed on to a series of callbacks

3. The third layer receives the callbacks and processes the input in priority order, performing game activity as needed



My first layer passes SFML input data to my second layer.  My second layer handles input mapping and dispatching (context switching is ignored for the time being).  While I did not implement callbacks, I thought I had handled dispatching of input with my function SendEvent().  If a component is listening for a particular action it will be notified when it is occurs.  The third layer is the game code that handles the callbacks, or in my case each component's HandleEvent function.

Edited by Kanefa

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!