• Create Account

## Input Mapping

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

3 replies to this topic

### #1Kanefa  Members

122
Like
0Likes
Like

Posted 26 March 2014 - 12:05 PM

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;

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
{
public:
enum Type
{
Trigger,  // one time use
RealTime, // holds state (poll it)
Range,    // axis
};

public:
Action(Type type, const Event& gameEvent);

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

private:
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;
};

### #2haegarr  Members

7186
Like
3Likes
Like

Posted 26 March 2014 - 01:23 PM

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.

(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:

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:

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.

### #3ApochPiQ  Moderators

21387
Like
1Likes
Like

Posted 26 March 2014 - 04:42 PM

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.

Wielder of the Sacred Wands

### #4Kanefa  Members

122
Like
0Likes
Like

Posted 26 March 2014 - 08:02 PM

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, 26 March 2014 - 08:41 PM.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.