plib-devel

[Plib-devel] Re: PLIB's JS and generality

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

Alexander Perry wrote:
<SNIP>
> 1.  plib does not place an upper limit on the number of /dev/js devices,
> which is good because I've currently got eight devices declared and four
> running (and in use) at the same time.  I expect more, see below.

This was a misunderstanding on my part; I have got a new library (that
layers above JS) being discussed on the PLIB list. It will detect as
many joysticks as you like!
So you can breath out.

> 
> > > 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.
> 
> Yes, also need to convert combinations of buttons/menuitems into an
> emulation of an analog quantity so that people with few analog channels
> can emulate things such as throttle steps and fast sweeps easily.

This is an area I need to think about, and some input (hah!) would be
appreciated; using the 'at' functions is an issue here since my stick
reports it jas axes 4/5, but with only -1, 0 or 1 reported for each
axes. Are there stick out there where the hat is analog?

Again right now I have a total seperation of analog and digital inputs,
so for exmaple flaps is two digitals, a 'raise' and a 'lower'.
Potentially someone may desire to hook-up an analog input, BUT then we
need to specify a 'step-size', since only certain postions of the level
make sense (correct?) Similalry for spoliers.....

possibly a 'dual-mode' input which can be either digital or analog? With
a 'step-size' specified; digital moves in steps, analouge rounds to
nearest. (Or not at all if the input really is linear) And then when a
digital input is set (like 'move to max'), can lock at that position
until the analog source moves by a threshold ....

Comments?

<SNIP>
> I've currently got 12 analog channels and 15 buttons so far,
> and expect to hit about 25 analog and 100 buttons within one year.

Well these are just shortcuts : you can *USE* 0 ... n as the device
number :-)
But also defining the CTL_JS(n) macro is trivial. Personally I'm just
using raw numbers, but I thought that it might be awkward to rember
'what the '1' does' after 6 months :-)

> 
> > ctlAnalouge*
> 
> Either "Analog" for americans or "Analogue" for the europeans.
> Omitting the "u" changes the sound of the "g" so that the word
> will rhyme with "rouge".

Yah, please excuse my lack of spelling; I will convert to Yankee style I
think (dammed colonials!) [happy, Steve?]

<SNIP>
> 
> Don't forget leftbrakeCtl rightbrakeCtl propspeedCtl nosesteeringCtl
> radiovolumeCtl nextradiovolumeCtl panelinstrument[i]Ctl etc etc
> 
This list was not mean to be exhaustive. Obviously adding more axes is
trivial, the FG code was simply meant to test the PLIB library's
functioning.

> You're better off having the various control channels in the simulator
> request the joystick channels that they'd like to offer more generically.

Please explain this in more detail : the current method certainly
doesn't look pretty, but it works (kinda).

James Turner

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

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

Some more points that have come up:

the need for controls with both analog inputs and digital buttons. Hence
I have a new input type, ctlDual, which clan be used as follows:
	
ctlDual *t = new ctlDual("Throttle", 0.1, 0.05, CTL_JS_0, 3);
	2 parameter is the 'step size', explained below
	3 param is a threshold, also explained below

then:

t->addDigital(new ctlDigital("100% Throttle", CTL_KEYBOARD, '#'),
CTL_DUAL_MAX);
t->addDigital(new ctlDigital("Increase Throttle", CTL_KEYBOARD, '+'),
CTL_DUAL_INC);

The current 'ops' for dual inputs are centre, min, max, increase and
decrease. A digital source can be bound to any of these operations.
Increase and decrease will use the specified step size. (10% in this
example). The threshold specifies what change is required in the analog
source before it 'overrides' the previous digital setting. So if full
throttle is set, the analog source must change by > 5% before becoming
'active' again.

There also needs to be a flag to determine whether the analog axis is
rounded to step values or not.

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.

As ever feedback is appreciated especially from non-FG users of PLIB,
who I suspect are all looking on in amazement and thinking 'when would I
*ever* use this junk' :-) 

James Turner

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

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

James Turner wrote:
> 
> Some more points that have come up:
> 
> the need for controls with both analog inputs and digital buttons. Hence
> I have a new input type, ctlDual, which clan be used as follows:
> 
> ctlDual *t = new ctlDual("Throttle", 0.1, 0.05, CTL_JS_0, 3);
>         2 parameter is the 'step size', explained below
>         3 param is a threshold, also explained below

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)

> then:
> 
> t->addDigital(new ctlDigital("100% Throttle", CTL_KEYBOARD, '#'),
> CTL_DUAL_MAX);
> t->addDigital(new ctlDigital("Increase Throttle", CTL_KEYBOARD, '+'),
> CTL_DUAL_INC);

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.

> 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.
 
> As ever feedback is appreciated especially from non-FG users of PLIB,
> who I suspect are all looking on in amazement and thinking 'when would I
> *ever* use this junk' :-)

To the contrary - I'm hoping that this will allow me to get mouse and
keyboard drivers for my two Tux games (A Quest for Herring - and the
upcoming 'TuxKart') - with zero effort on my part!
 
-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

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

[Sam S. <sa...@sp...>]

> > As ever feedback is appreciated especially from non-FG users of
PLIB,
> > who I suspect are all looking on in amazement and thinking 'when
would I
> > *ever* use this junk' :-)
>
> To the contrary - I'm hoping that this will allow me to get mouse and
> keyboard drivers for my two Tux games (A Quest for Herring - and the
> upcoming 'TuxKart') - with zero effort on my part!

Me too..  I quickly knocked up a keyboard callback system for my game
about 7 months ago, and I haven't touched it much since, and it's kinda
groaning under the strain of having mouse and joystick code hacked into
it.  I wasn't looking forward to ripping it to pieces and rebuilding it
over the next couple of weeks - but with a bit of luck now I won't have
to!

Sam

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

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

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

James Turner wrote:

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

I don't know either of those.

> With a system as 'lose' as you propose, that won't be
> possible.

Explain?

What I propose would have a standardized (external) GUI tool for
setting up all the controls for *any* game.  If one specific
game wanted to have a GUI interface for tweaking it's controls
then it could simply call the API to write out the current
control settings to disk, then invoke the external GUI tool - and
when that exists simply read the file back in again to make the
new control setting active.

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

Well, the range of a variable certainly needs to be controlled by the
application - we don't want the user to be able to configure his throttle
to deliver 200% of the maximum that the real plane has.

Personally, I'd keep things simple and have EVERY analog variable have
a range of either 0..1 or -1..+1 and let the application multiply that
by whatever it needs...however, it wouldn't hurt for the library to
handle all that stuff internally.

The step size should *certainly* be under user control (although the
application should be able to provide a default in the control file).
Some people will want to be really careful fliers and will want minutely
accurate control over (say) the flap settings - others will be 'fun fliers'
who won't want to have to push the 'Flaps-up-a-bit' button 20 times to get
from full down to full up.
 
> 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.

Yes.  I agree.
 
> 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)

That doesn't seem too onerous - and the application should come delivered
with a file of 'sensible' settings.  If the flaps don't need a 'center'
preset - then the application won't set it that way in the default settings
file - and the users won't bother to change it to have a 'center' preset
unless he has a good reason to do so.

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

But you'll have to write a config file parser anyway so that you can make
changes to the setup persistant between sessions.  Without that, the whole
thing just becomes a pain in the ass.

If you are going to the trouble of writing a GUI then it might as well be
useful to every application by being a standalone program as be a one-off
effort.
 
> 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.

Perhaps - but as I said, providing a standardized 0..1 or -1..1 range
as the interface between library an application solves that problem
completely.

You'll also need the option to have values that wrap around so you
can accept things like heading angles that go from +180 to -180.

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

But sensible defaults can be provided in the configuration file rather
than being an additional burden for the application programmer and a
vast complexifier to the API between application and library.

API's need to be kept as simple and clean as possible.

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

But it's not an either/or situation.  You have to be able to load and
save those settings - so you'll end up spending that extra hour writing
the parser anyway.

The difference between a UNIX coder and the 'other' kinds is that we
have a philosophy that every program (or library) should do one task
extremely well - and that large packages are made from lots of little
modules glued together.  UNIX has a rich set of intercommunication
mechanisms to make that easier - but Windoze is catching up.

In Windoze (and MacOS), the philosophy is that every single program
has every conceivably bell and whistle.  This results in the kind
of bloatware that M$ do best.

In this case, taking the 'user controls configurator' out of FGFS
and making it a standalone program - with a little more generality
than it would have needed otherwise - gets you to a situation where:

a) Application writers don't have to re-invent a configuration
   GUI for every single application.

b) Users don't have to learn how to configure each and every
   application using a completely different GUI each time.

I think this is just common sense...but YMMV.

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