Re: [Plib-devel] Control Abstraction

[Steve B. <sjb...@ai...>]

James Turner wrote:
> 
> 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.

In fact, that idea (or a very close cousin of it) originated on this
list - and whilst we all agreed that it was a great idea - and a perfect
candidate for a PLIB library, nobody wanted to do the work of implementing
it.  It was subsequently discussed on the FGFS list - but I wasn't aware
that anyone had actually worked on it.

> 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?)

Well, you could either use the existing GLUT API - or steal the
code for doing that from the freeglut library and embed it directly
into this new package.

> 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)

...also it would need to have the ability to take the physical device
input and treat that as either the absolute value of the output data
or as the velocity of the output (or even possibly the accelleration).

That's needed (IMHO) in order to cope with things like wanting (say)
the absolute data value to be tied to the position of the joystick - but
to allow someone to use the keyboard to move the object - which might
require a velocity drive in order to make it usable.

> Enough interface must be exposed to allow building a configuration
> dialog in PUI, and saving / restoring the bindings of game controls to
> physical inputs.

Yes - with some kind of configuration widget to allow the end user
to bind whatever controllers he has (and likes) to whatever controls
the game/simulation requires.


> 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),

...certainly not...IMHO.

> or
> seperate but
>         related. If the GUI is seperate a much larger interface must be
> exposed
>         by the library (as shown above)

Hmm. I need to think about that.

It would be nice to have the button-type controls be able to take
input from a GUI widget (eg a menu entry) as well as/instead of
a physical button (on mouse, keyboard or joystick) so that people
who are learning (say) FGFS wouldn't have to remember that Alt-Shift-W
means "tune the radio up by 1KHz" and could use the menu instead.
 
>         - how to handle persistece of all these settings [some kind of
> global
>         save / restore to an iostream? a file? a chunk of memory?]

They certainly have to be in a file because the user won't want to
go through and re-configure all those controls to his/her personal
preferences every time the game is started.  Quite how they get into
and out of the file is not a big deal IMHO.
 
>         - how the keyboard / mouse sources will interact with
>         the GLUT input handlers. Probably setCapture()-style
>         calls by them game will be required?

Yep - perhaps.

> 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.

Wonderful!
 
-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)