Re: [Plib-devel] Re: control abstraction, continued (ad infinitum)

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

Steve Baker wrote:

<SNIP>

Why should there be a new type?   I think that all analog inputs
> should have the capability of being driven from digital inputs
> because some people don't like using the mouse or joystick at
> all. (eg Quake fanatics)

Agreed.

> I don't think this should be under program control.  I think the application
> should just state it's needs:
> 
>   addDigital ( "RetractSwitch" ) ;
>   addAnalog  ( "Throttle" ) ;
> 
> ...and have an external file (say '.fgfs_controls' for FlightGear,
> '.tux_aqfh_controls' for Tux, etc) that binds physical controllers
> to each application variable:
> 
> RetractSwitch:DIGITAL:  'R'==1, 'U'==0
> Throttle:ANALOG:  MOUSE_NORTH_SOUTH + MOUSE_MIDDLE_BUTTON, scale=1.5,
>                   deadzone=0.3, linear
> Flaps:ANALOG: '<'==++0.1, '>'==--0.1
> 
> ...and so on.  Then (initially) we can create such a file that installs
> with FGFS (or whatever) which has the default controllers - possibly
> one file for people with joysticks and one without.  Experts can then
> hand-edit that file to set their own personal preferences - and perhaps
> some kind person would create a GUI-driven configuration widget that
> would be application-independent.

Okay the reason for my 'heavy handed' interface is being my goal with
the APIs was to be able to build a GUI pretty mucch exactly like Fly!'s
or FS2000's. With a system as 'lose' as you propose, that won't be
possible. [At least in the standard 'here's a list of analog inputs,
choose a joystick axis,' and 'here's a list of digital inputs, choose a
button / key' method, which I'd like to stick too]

Certain parameters are fixed for the control by the program, such as the
step size and scale, whether the axis is positional or velocity, and
having them in the control file seems pointless. (or for digitals,
whether it is debounced)

Further more, in order to provide a sensible GUI, the list of analog and
digital inputs need to be complete; so the bindings which are 'legal'
need to be specifed by the program.

Eg for a 'flaps' analog axis, probably the 'important' bindings are
increase and decrease; 'center' is probably useless. But without the
program specifying these, the GUI must list all possible digital
bindings on every analog axis. (Currently that's 5 possible bindings for
every analog)

I'd much prefer to sacrifice some configurability in order to keep the
GUIs nice and clean since I certainly can't be bothered hacking a config
file. (But then, I did start coding on the Mac :-)

Seriously, I think that at least scale and legal linkages need to be
specified:
	flaps = ctlAnalog("Flaps", 0.0, 1.0, CTL_ANALOG_POSITIONAL);
	flaps->addDigital(INC, new ctlDigital("Raise Flaps"));
	flaps->addDigital(DEC, new ctlDigital("Lower Flaps"));		

The scale seems important to prevent the returned values exceding the
range the simulation / game is 'expecting'. Similarly the pos /
velocity selector would otherwise affect the code so allowing
customization seems unwise.

And I suppose having an 'advanced' GUI that allows things like step
size, etc to be specified is doable, but I'd still prefer that sensible
defaults were specifed so that I could just bind my favourite buttons to
'increase flaps' without worrying about choosing a step size.

You can tell I'm not a Unix coder; I'd much rather spend a day writing
the GUI than an hour writing a parser for your text config file format
;-)

> 
> > One other suggested change is that digital inputs drive callbacks rather
> > than being polled; this makes a lot of sense I suspect, so I will add a
> > setCallback method and alternate constructor to ctlDigital. I don't
> > think callback behaviour makes sense for analog inputs, but if people
> > disagree then it could be included.
> 
> It should be possible to use three mechanisms:
> 
> 1) Polling (that doesn't work well with GLUT - but it can be done)
> 2) Callbacks.
> 3) Direct variable drive (ie you call a single 'update' function and
>    it updates a bunch of variables that the application bound to the
>    controllers).
> 
> Each method has its benefits.

Eeewwww. I suppose this is true :-(
I suppose the public has the right to choose, hence all 3 options will
be available; this is actually pretty simple to implement.

I will probably just have 3 flavous of the construtor; one will tkae a
variable address and one a function pointer.

James