RE: [gluon] FW: Input Actions for Gluon Input GCI Task

["Tony Young" <rofflwaffls@xxxxxxxxx>]

> -----Original Message-----
> From: Listengine [mailto:listengine@xxxxxxxxxxxxxxxxx] On Behalf Of Arjen
> Hiemstra
> Sent: Thursday, 2 December 2010 3:16 a.m.
> To: gluon@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [gluon] FW: Input Actions for Gluon Input GCI Task
> 
> On Wednesday 01 December 2010 13:49:46 Tony Young wrote:
> > > From the conversations I've had with leinir and djszapi in #gluon,
> > > I've come up with http://pastebin.com/b8Z6FiF6
> > >
> > > There are no GluonInput-specific implementations in the code and
> > > it's very generic. It uses Qt signals for notifying anything
> > > interested in input actions and, by overriding checkActionState of
> > > InputAction, one can determine if their action has triggered or not,
> > > and which state it's in (Up or Down) by calling update on the
> > > InputAction every frame (simplified by using InputActionManager).
> 
> An important thing to consider is that the idea is that the actions system
> abstracts away the actual input devices. This means that, as a game
> developer, you would create a set of actions, not directly knowing what
> device will be performing these actions. You seem to have approached this
> already, however the previous person who wanted to attempt this task
> pointed out that there are two major types of actions. Actions relating to
> some form of button press, such as a keyboard key press, mouse button
> press or touchscreen tap and actions relating to movement along an axis,
> such as basic mouse movement or a joystick throttle movement. He suggested
> creating two main action types, one for axis movement and one for button
> press.
> 
> > >
> > > An action can be created by subclassing InputAction and overriding
> > > the pure virtual method checkActionState which returns either None,
> > > Up or Down depending on the action's state.
> > >
> 
> Hmm, I would really prefer not having to do this. The idea here is that at
> some point we will have a generic input component handling a list of
> actions.
> The game developer simply creates a bunch of actions with a default input
> device binding and a name. Having to do subclass-magic for this would make
> it rather awkward, I think.
> 
> Another important thing to consider here is that most of this should be
> event driven. If I recall correctly, it is necessary to update the input
> devices during the game loop, however, this could be handled by the
> component. The actions themselves are triggered whenever the key
> associated with the actions is pressed. These actions will then trigger an
> event in our yet-to-be- implemented game-wide event system. The game
> developer can then write code that responds to this event.
> 
> > > What I'm not sure about is whether or not if I actually need to
> > > implement any interface to GluonInput. I've been told that I don't
> > > need to, and an abstract implementation of actions is fine, but
> > > since this is your task I'd like to just check with you.
> 
> No, you do not need to. What I want to see is a proof of concept
> implementation of the system. This can be using any toolkit you prefer and
> basically any language you prefer, although C/C++ is preferred as we will
> still need to be able to use it to some degree. :p
> 
> Another thing I would want to see is a bit of a somewhat higher-level
> overview of how you think the system needs to work. I'd love to have a few
> paragraphs of text explaining, on a higher level, the design.
> 
> > >
> > > Waiting for your reply,
> > > Tony
> >
> 
> - Arjen
> 
> 
> ---
> +----------------------------------------------+
> Gluon is a high-level game development library for the KDE desktop
> enviornment.
> http://gluon.tuxfamily.org/
> http://gitorious.org/gluon
> 

Hi again,

Here's a revised version of my proposal: http://pastebin.com/yPaNTHxc

I've subclassed InputAction into AxisMovementInputAction and
ButtonPressInputAction which have their own binding methods (bindDevice)
to avoid any excessive subclass magic.

As for the actual input handling code, I haven't implemented anything yet
that interfaces with GluonInput, as it seems that's not related to me.

Included at the top of the paste is an example of the implementation of
attaching subscribers to an InputAction.

The basic idea for the InputAction framework are, of course, events.
Every time the InputActionManager updates, it updates all its children
InputActions which will dispatch events to anything interested in
receiving them. The receivers will then run their own input handlers,
if they wish.

Let me know if you have any more requirements. I'd really like to talk
to you on IRC discussing this. When would be a suitable time for us to
talk?

Thanks,
Tony


---
+----------------------------------------------+
Gluon is a high-level game development library for the KDE desktop enviornment.
http://gluon.tuxfamily.org/
http://gitorious.org/gluon