Input Manager

Oct 24, 2007 at 4:58 AM
Currently all input is handled inside the Input class, which means that all key/mouse/pad controls are setup in there and it's not possible (for a user) to change that mapping.

I purpose that we rework this and add a overall InputManager which handles assignment and redirects input events to specific listeners. This should enable users to create custom key/mouse/pad mappings.

Are there any specific requirements?
Coordinator
Oct 24, 2007 at 5:29 AM
It has already been re-designed in the prototype, you can check it out if you'd like. I haven't had a lot of time to look at it, but I believe it uses messages so that anything can pickup the inputs.
Oct 24, 2007 at 5:39 AM
Yes it's reworked in the the protptype. Is it there I should concentrate on doing code/comment on or should I just ignore that for now?
Coordinator
Oct 24, 2007 at 5:47 AM
You'll have to ask shaw about prototype stuff, he's in the middle of designing a prototype and commenting it out. After he finishes the prototype he is going to release a simple tutorial and then I'll begin integrating components and touching them up as I go. If you feel you have something to add to the prototype you can experiment with it, just don't commit any changes without talking to Shaw as he may be in the middle of redesigning it.

I've simply continued adding features to the existing engine, and I figure I can convert it over when we get the prototype, although I wouldn't redo the input class on the current framework as that would be a waste being that you'd have to implement a message system which is already in the prototype.

Shaw might like some help on the prototype, might be worth asking him.
Coordinator
Oct 24, 2007 at 5:49 AM
There are plenty of issues and new features in the 'issue tracker' section that could be worked on while we wait for the new framework as well.
Oct 24, 2007 at 1:50 PM
It would be useful if you could make a call like "if (Input.IsButtonNewlyPressed(GamepadButtons.A))", rather than have to setup messages and delegate callbacks and such all the time.
Oct 24, 2007 at 2:47 PM
How about using eventing? OnKeyDown OnKeyPress OnKeyUp etc?

I used that method in my current implementation. It works, but did require some additional logic for locking input for specific entities, i.e. input controls/screens.

All mapping should be configurational, in another project I achieved that using two lists, one to map method and keyword and one for mapping keyword to input (keyboard or mouse).

But this would require a substantial rewrite of the current behavior.
Oct 24, 2007 at 6:32 PM
If you want to commit changes to the prototype, go ahead. Though if you're going to make interface-breaking changes, at least make a note on the forums here to I know about it, and make sure you patch up the changes so the project compiles/executes.

In the prototype, the input is configurable. Clients bind enumerated events to key presses, mouse presses, etc., and then they receive events like InputEventBegin and InputEventEnd, representing KeyDown and KeyUp, respectively. There's also an AxisMove move for when the mouse is moved. For gamepads, I'll probably send an AxisMove event once per frame representing the thumbstick positions.


Oct 24, 2007 at 7:09 PM
I'll have a look and see what I can com up with :)