Sign in to follow this  
GroZZleR

Abstracting Input

Recommended Posts

Hey all, I've devised a system of events (jump, move forward, etc.) that works flawlessly with any input device (it's pretty much the same as Quake / Half-Life). The problem I'm having is that other systems are dependent on certain input devices. For example: the GUI is dependent on the mouse to move the cursor and trigger actions. I'd really like to abstract this to the point where arrow keys or a controller's analog stick could be used to move the cursor. I'm stuck on a system of events / structures that would allow this. The best I've been able to come up is a hierarchy of preferred input devices. Basically the GUI would poll for mouse messages, then analog messages, then arrow key messages assuming the previous one wasn't found. This makes the GUI input scheme incredibly bulky and unwieldy. The other alternative is to send the GUI messages directly from the Input task in the Kernel, but that breaks the abstracted task-based design I'm using. No task should know about any other task, it can just send messages and see if a task replies. Does anyone have any articles on input abstraction or would be willing to explain their own system of abstraction? Thanks.

Share this post


Link to post
Share on other sites
You could have the arrow-key interface construct the adjacency graph (which arrow key selects which component), and the mouse interface construct the cursor. Then the arrow key interface will send a widget selection event whenever the user presses a key, and the mouse interface will send a selection event whenever the user mouses-over the control.

I don't know whether you'd want the analog device to emulate the arrow keys or the cursors (I've seen both). If you really want to emulate the cursor, then you'll have to couple the mouse and the analog since they need to share the same state (the cursor location).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Another possibility: Build the GUI to interact with a positional/selector interface. Then, any input device that is capable of describing a position and making a selection action can use the GUI. If the GUI is also responsible for drawing the cursor, then it can take non-selecting positional updates in the form of deltas or absolutes from the interface; this allows whatever device the user has to hand to control the GUI cursor and perform actions with it.

Then, a small amount of very readable code can implement your preferred input hierarchy just by looking at what's available and binding the best one to the GUI.

Share this post


Link to post
Share on other sites
Define a pair of actions for moving the cursor around - one for horizontal movement, one for vertical. Attach a value to each action to describe the magnitude and direction of movement.

Next, define a priority chain for mapping raw input (say, a press of the arrow key) into an in-game action. Allow this priority chain to be adjusted on the fly. When running around shooting stuff, the chain should map the arrow keys to movement (or whatever) as the first choice. When in the GUI, the chain should map the keys to the cursor-control actions. Alternately, if the user can configure mappings, they can map (for instance) F1-F4 as the direction control keys, and these will always be connected to the cursor-control actions by default.

Finally, restructure your mouse code to poll the mouse coordinates, generate deltas per frame, and translate those deltas into movement values for the cursor control actions. Send those action messages to the system, and it should respond properly.

Once all that works, repeat with an action for "UI selection" which can be bound to mouse buttons, Enter key, etc. I personally find it useful to treat all button input as the same type of data, regardless of source: mouse buttons, keys, joypad buttons, etc. This makes it trivial to abstract away the handling of an action ("UI selection") from the method of input that generates it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this