Re: [Plib-devel] Control Abstraction

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

Steve Baker wrote:
> 

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

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

Hmm, right how I'm sitting ontop of GLUT, but the API is rather
irritating.
[I just re-read that sentance - it sounds kinda strange]

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

I had completely failed to consider this one, but can add it pretty
easily; I need to determine the best way to find the velocity though.
Using (new_pos - old_pos / time) is 'theoretically' accurate, but I
wonder what the stability will be like. Also, how do I get timing
information portably? Examining the last 2 values would help noise
reduction, etc..

<SNIP>
> > I am unsure of a few points:
> >         - whether the GUI should be compulsory (probably not),
> 
> ...certainly not...IMHO.
Agreed

> 
> > 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.
The interface does get larger but forcing people to use one fixed GUI is
what killed 'InputSprocket' on the Mac (and that GUI was *ugly*)

Right now I am intending to build a basic GUI using PUI, and include
that as an extra, and a template for people who wnat to build their own
GUI

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

I'm not sure the best way to implement this; I wil give it some thought

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

Well I don't want to create a stdio / iostreams / etc dpendance
unecessarily.
But yes obviously the settings must be persistence. How do the various
libary users feel about this?

My current status:

I re-wrote the code from scratch to be stand-alone (on-top of JS); the
library is currently called 'ctl' and is sitting in my plib directory
building and running fine.

It supports arbitrary analouge and digital inputs; input using joysticks
via JS and keys via a GLUT-callback thingy. ('special' keys need to be
handled or the whole interface just re-designed not to use GLUT)

The mouse stuff is not hooked up because I don't want to break that bit
of FG :-)
Right now I have used the library to re-write the FG joystick module; I
have the primary flight controls working fine. In addition I have
modified 'keyboard.cxx' to pass key events to the library, and hence I
have sucessfuly driven flaps, brakes and other options with the joystick
buttons and keys.

Before I do any more damage I would appreciate some comments on the API;
I have attached the header file for review.

Please feel free to rip it apart; it's really a 'first draft' (if a
working one) and has only had one pair of eyes reviewing it so far.

To make it clearer how this works for the client program I have also
included my hacked-up FG joystick.cxx file; hopefully it will explain
what the hell I've done :-)

James Turner