[Plib-devel] Control Abstraction

[James T. <jm...@dc...>]

Hi y'all, this is my first post to plib-devel so go easy :-)

This is an off-shoot from some ideas I had for FlightGear; Norman Vine
suggested they might be applied more generally.

I propose creating a new library that allows the game to define input
'controls'; initally either digital or analouge. The game would pass a
name for the function, and an identifier. So 'Fire' and 'Jump' might be
defined as digital controls, and 'throttle' or 'elevator' would be
defined as analouge controls.

The library then handles the mapping of the game inputs to physical
inputs, either joysticks (via JS) or key-presses. (I don't know how to
clealny handle mouse input, myabe a capture() function?)

For analouge inputs, the library may track additional data such as
dead-zone, scaling and inversion. This overall design is very similar to
'InputSprocket' on the Macintosh, and bit more high-level than
DirectInput (since it includes game controls, as well as physical
inputs)

Enough interface must be exposed to allow building a configuration
dialog in PUI, and saving / restoring the bindings of game controls to
physical inputs. I would assume defining an abstract class 'Input' with
derived clases for digital and analouge inputs.

class inDigital : public Input
{
public:
        inDigital(string &label, int input, int button);

        // interface used by game
        bool get_value();

        // interface used to configure
        string& get_label();

        int get_input();
        void set_input(int i);

        int get_button();
        void set_button(int i);
}

class inAnalouge : public Input
{
public:
        inAnalouge(string &label, int input, int axis, bool invert,
float
nullZone);
        
        // interface used by game
        float get_value();

        // interface used to configure
        string& get_label();
        
        int get_input();
        void set_input(int i);

        float get_null_zone();
        void set_null_zone();

        // etc .....
}

The library would also provide functions to allow enumeration of the
physical devices attached; again this is for use in building a GUI. For
configuring the analouge inputs, a simple menu of each available
physical axes can be provided. For the digital inputs, a more
intelligent scheme would be desirable : the ability to watch for a
button / key press and record the source. I.e the standard 'press a key
or button to assign to this function' behaviour most games use now.

I am unsure of a few points:
        - whether the GUI should be compulsory (probably not), or
seperate but
        related. If the GUI is seperate a much larger interface must be
exposed
        by the library (as shown above)

        - how to handle persistece of all these settings [some kind of
global
        save / restore to an iostream? a file? a chunk of memory?]
        
        - how the keyboard / mouse sources will interact with
        the GLUT input handlers. Probably setCapture()-style
        calls by them game will be required?

I have a FG specific implementation of the above (for analouge inputs
only) working right now, without a GUI. I will augment it tomorrow and
generally tidy it up, and then see about making it available for review,
etc. Since this is my inital attempt at this it will obviously need a
lot of refinement; please let me know any suggestions you have.

James Turner