plib-devel

Re: [Plib-devel] Exposed bitmap loaders in SSG?

[steve <sjb...@ai...>]

Jan Reucker wrote:

> actually I never thought about exposing the loader subclasses.
> You call a non-class loader function that determines the file
> type and creates an object of the matching sub-class, then
> it returns a base-class-pointer.

Yeah - that's exactly what I'm talking about when I talk
about a 'factory' function.  Give it a filename - get back
the base class from which specific formats may either load
into or derive from.

Re: [Plib-devel] Exposed bitmap loaders in SSG?

[Jan R. <slo...@gm...>]

Am Sun, 07 Jan 2007 12:56:43 -0600 schrieb steve <sjb...@ai...>:

> We certainly want a way for the application to ASK what formats
> we support - or whether we support a specific format - but we
> certainly don't want to have a specific class for each image
> format that is exposed to the application (although internally
> to the library, that makes a lot of sense).

Steve,

actually I never thought about exposing the loader subclasses.
You call a non-class loader function that determines the file
type and creates an object of the matching sub-class, then
it returns a base-class-pointer. To the application this is pretty
much the same as directly creating an object of the piImage
class by calling the ctor which then dispatches the task of
loading the pixel data to a matching function.

If the library uses a set of non-class loader functions or if it
uses subclasses of a generic loader class shouldn't bother
the user in any way. Maybe it would be an elegant solution to
use a family of classes, but maybe it's not worth the effort
of converting the existing loader code from SSG.

I'll start with a very simple "pi" library that only supports
one or two image formats and upload the source code to my
webspace for a design review. Then we can decide if this is
the way to go before converting the rest of the loaders.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] Exposed bitmap loaders in SSG?

[steve <sjb...@ai...>]

Jan Reucker wrote:
> Am Sat, 6 Jan 2007 20:54:16 +0100 schrieb Jan Reucker <slo...@gm...>:
> 
> Some additional thoughts:
> 
>> - define a unified API for the raw loaders, maybe using
>>   some kind of piImage object to store the raw image data and some
>>   additional information (width, height, pixel format)
> 
> This approach would be similar to ssgTexture. There's one class
> for all texture formats. The ctor can be called with any file
> type and hands it over to a non-class loader mechanism, which in
> turn calls one of many non-class loaders to get the raw pixel
> data and some additional info.

Yeah - I like this.

> On the other hand we could define a piImage base class and a set
> of derived classes, one for each file type. Then we'd need a
> non-class loader function that uses one of the derived classes
> to load the image and then returns a piImage* base pointer to the
> caller. To the user, this is similar to ssgLoad().

I've come to dislike this approach.  One of the nice things about
OSS software is that you can replace the library without rewriting
the application that uses it.

If PLIB added a new image format (say 'TIFF') sometime in the
future - then only applications that were compiled with 'piImageTIFF'
would be able to load TIFF images.  That's unnecessarily
restrictive.

If on the other hand we had a classless 'factory' function that
you passed the filename into - and got a class piImage back (
which might in fact be a derived class of piImage) - then the
issue of which image formats are supported becomes largely
irrelevent to the application.  All it does is pass in the
filename (which the end user may have picked from a file picker
dialog box) - and it gets back a standard structure with stuff
like the actual pixel data, the height, width, bytes-per-pixel,
etc.

Then, the application doesn't have to care what image formats
are supported.   All the ones we support 'just work' without
the application having to know.

We certainly want a way for the application to ASK what formats
we support - or whether we support a specific format - but we
certainly don't want to have a specific class for each image
format that is exposed to the application (although internally
to the library, that makes a lot of sense).

Re: [Plib-devel] Exposed bitmap loaders in SSG?

[Jan R. <slo...@gm...>]

Am Sun, 7 Jan 2007 09:01:38 +0100 schrieb Jan Reucker <slo...@gm...>:

> Any pro's and con's?

I don't want to turn this thread into a blog ;), but I'd like
to add that I've just started doing it the first way. I don't
see any real benefit in the second approach besides more work
for me... But I haven't invested too much time yet, so don't
hesitate to stop me if there's a good reason not to do it the
way that ssgTexture does it right now.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

[Plib-devel] X45 and X52 and buttons

[Jim C. <j.c...@zy...>]

Hi,
Without wishing to extend this thread too far - as well as the buttons 
on X52 problem (ie more than 32) there was also a problem with X45 not 
having its "dial" recognised so I added patch to jsMacOSX.cxx :
		if (page == kHIDPage_GenericDesktop) {		
			switch (usage) /* look at usage to determine function */
			{
				case kHIDUsage_GD_X:
				case kHIDUsage_GD_Y:
				case kHIDUsage_GD_Z:
				case kHIDUsage_GD_Rx:
				case kHIDUsage_GD_Ry:
				case kHIDUsage_GD_Rz:
				case kHIDUsage_GD_Slider: // for throttle / trim controls
            case kHIDUsage_GD_Dial:
					//printf(" axis\n");
					/*joy->os->*/addAxisElement(joy, (CFDictionaryRef) element);
					break;
					
				case kHIDUsage_GD_Hatswitch:
					//printf(" hat\n");
					/*joy->os->*/addHatElement(joy, (CFDictionaryRef) element);
					break;
					
				default:
					ulSetError(UL_WARNING, "input type element has weird usage 
(%lx)\n", usage);

whether this was the case on other platforms I dont know! It does show 
that more advanced joysticks have facilities that may have to be 
tailored!! - we may need to recognise GD_Wheel as well for instance.
The HIDusage tables on the Mac do give a pointer to the range of 
possibilities (including a special section for simulation) - see "HID 
Usage Tables" specification:
      http://www.usb.org/developers/hidpage/#Class_Definition
under "GenericDesktop" and "Simulation" pages.

cheers
Jim

Re: [Plib-devel] Exposed bitmap loaders in SSG?

[Jan R. <slo...@gm...>]

Am Sat, 6 Jan 2007 20:54:16 +0100 schrieb Jan Reucker <slo...@gm...>:

Some additional thoughts:

> - define a unified API for the raw loaders, maybe using
>   some kind of piImage object to store the raw image data and some
>   additional information (width, height, pixel format)

This approach would be similar to ssgTexture. There's one class
for all texture formats. The ctor can be called with any file
type and hands it over to a non-class loader mechanism, which in
turn calls one of many non-class loaders to get the raw pixel
data and some additional info.

On the other hand we could define a piImage base class and a set
of derived classes, one for each file type. Then we'd need a
non-class loader function that uses one of the derived classes
to load the image and then returns a piImage* base pointer to the
caller. To the user, this is similar to ssgLoad().

Any pro's and con's? While the first one seems to be closer to
the existing code in SSG, the second might be more C++ish. And
it might be easier to handle a loader failure: you can simply
return a NULL pointer instead of a valid piImage*, while in
the first case you have to deal with a failed constructor so you
must provide some kind of "default image" like ssgTexture does.
Of course you have the same problem internally when one of
the piImage subclasses fails (e.g. because of a corrupted image
file), but it's hidden from the user.

Kind regards,
Jan R.


-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] Exposed bitmap loaders in SSG?

[Jan R. <slo...@gm...>]

Am Sat, 06 Jan 2007 09:03:55 -0600 schrieb steve <sjb...@ai...>:

> If you want to take on this task, I think you should start a new
> PLIB library component (plibImage with a 'pi' prefix or something)
> - get it all up and working as a stand-alone thing (probably
> copying/stealing code from SSG to do that).   When it's all running
> and reliable, we could just switch SSG over to using it.  This would
> mean zero changes to SSG until we are ready to do the switch.

Steve,

if I want to - read: if my limited spare time allows me to - take
on this task or not depends on how much extra work is involved
to do this.

Let's think about a least-effort-approach to get "plibImage" started:

- copy the raw image loader code to new "PI" files
- define a unified API for the raw loaders, maybe using
  some kind of piImage object to store the raw image data and some
  additional information (width, height, pixel format)
- write some central functions like piInit() and piLoadImage()
  (or piImageFactory() or whatever)
- write piHaveLoaderFor() which, at the moment, does not try
  to dynamically load any additional libraries and only returns
  "true" for the PLIB-internal loaders

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] Exposed bitmap loaders in SSG?

[steve <sjb...@ai...>]

Jan Reucker wrote:
> Hello!
> 
> In August 2005 I wrote to this list asking what you'd think about
> exposing the bitmap loader functions from SSG. This would allow
> PLIB users to use these loaders for more than only texture loading,
> or it would simplify writing more complex texture classes for
> SSG. During the last 1.5 years I didn't find the time to start the
> project for which I needed this, but now it would really come in 
> handy.

Yeah - I've been thinking for a long time that we could use a proper
set of image loaders somewhere in PLIB...and if we had them it would
make sense to change the SSG texture map loaders to use them.

But if we are going to do this - let's think carefully up-front and
do it properly.

If you want to take on this task, I think you should start a new
PLIB library component (plibImage with a 'pi' prefix or something)
- get it all up and working as a stand-alone thing (probably
copying/stealing code from SSG to do that).   When it's all running
and reliable, we could just switch SSG over to using it.  This would
mean zero changes to SSG until we are ready to do the switch.

One thing though - we need to be careful about adding external
dependencies.  Relative lack of external dependancies is one of
the things people really value about PLIB and we don't want to
lose that.

I'd like to avoid having PLIB require libjpeg, libpng and a bunch of
other libXXX's before it'll compile.  Whilst you can rely on those
being present in Linux these days, they aren't always there under
Windows and MacOSX.

On the other hand, we don't want to copy the code from those
libraries into PLIB (thereby causing a code-fork for those
projects) and we CERTAINLY don't want to be writing and maintaining
our own JPEG and PNG loaders!

I think we should consider dynamically loading those libraries
(using dlopen/dlsym/dlclose) on-demand so that PLIB will still
build and run without any external image libraries if the user
only wants to use '.rgb' images.

The system should have a 'piInit()' call that goes out and looks
for available libXXX's (where 'XXX' is png, jpeg, gif, tif, etc)
and posts a list of available loaders that one can easily query
from the application level.  eg

    piInit() ;

    if ( piHaveLoaderFor ( "png" ) )
      image = piImageFactory ( "myimage.png" ) ;
    else
    if ( piHaveLoaderFor ( "jpg" ) )  // Urgh - lower quality!
      image = piImageFactory ( "myimage.jpg" ) ;
    else
      ulSetError ( UL_FATAL, "Can't load myimage because both"
                             " libpng and libjpeg are missing" ) ;

[Plib-devel] Exposed bitmap loaders in SSG?

[Jan R. <slo...@gm...>]

Hello!

In August 2005 I wrote to this list asking what you'd think about
exposing the bitmap loader functions from SSG. This would allow
PLIB users to use these loaders for more than only texture loading,
or it would simplify writing more complex texture classes for
SSG. During the last 1.5 years I didn't find the time to start the
project for which I needed this, but now it would really come in 
handy.

Background: I need to load a huge image (bigger than GL_MAX_TEXTURE_SIZE
in usual OpenGL implementations) and split it into smaller
tiles. Then each tile will be used to create a texture. With the
current SSG API I'd have to write my own bitmap loaders, because
each loader automatically invokes ssgMakeMipmaps() and then
discards the pixel data.

So what I suggest is basically the following:

- Each bitmap loader provides a new public function "ssgLoadFOORaw()"
  or something similar, which opens the file, allocates memory
  for the pixel data and loads it into memory. This is basically
  what the existing "ssgLoadFOO()" functions do, but they do two
  more steps: they implicitly call ssgMakeMipmaps() which then
  will free the pixel data.

- A replacement "ssgLoadFOO()" calls "ssgLoadFOORaw()" to load the
  file, then creates the mipmaps and discards the pixel data.

So this wouldn't change the existing API in any way. It would just
expose the functionality of the raw pixel loader functions to
make them useful for the user. Internally it's ideally just one
more function call when loading a texture, so this shouldn't
really hurt in any way. Again, it's no additional functionality,
it's just a matter of splitting the existing loaders into two
separate, useful pieces.

Of course I'd prepare the patches with these changes.

What do you think?

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] __indirect_glTexCoordPointer

[Bram S. <br...@sa...>]

On Sat, 2007-01-06 at 01:03 +0100, Bram Stolk wrote:
> Hi,
> 
> 
> Was the assertion error from __indirect_glTexCoordPointer() ever solved?

Ah... i've been able to find it in the Mesa3D bug database:
https://bugs.freedesktop.org/show_bug.cgi?id=6863

It looks like I need to upgrade to a development release of mesa.

  bram

> It is a very proliferated bug:
> http://www.google.com/search?q=__indirect_glTexCoordPointer
> 
> It is always related to PLIB, and it occurs on systems that do
> not have accelerated X.
> 
> Currently, I'm getting this on a fresh install of Yellow Dog Linux
> on the PS/3, with plib.
> 
> What I've found out:
> 
> - The assert goes away if I remove change ssgVtxArray.cxx
>   in ssgVtxArray::draw_geometry() I replace the 
>   glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
>   and glPopClientAttrib() with a 
>   glDisableClientState ( GL_VERTEX_ARRAY ) ;
> 
> - Most plib examples work with the fix, yet some do not render
>   geometry, and some even crash my X11.
> 
> - I suspect this is a protocol mismatch issue.
>   I think the client and server of GLX are using different opcodes.
>   The assert seems to get triggered even when glTexCoordPointer is
>   not used.
> 
> thx
> 
>   Bram
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] __indirect_glTexCoordPointer

[Bram S. <br...@sa...>]

Hi,


Was the assertion error from __indirect_glTexCoordPointer() ever solved?
It is a very proliferated bug:
http://www.google.com/search?q=__indirect_glTexCoordPointer

It is always related to PLIB, and it occurs on systems that do
not have accelerated X.

Currently, I'm getting this on a fresh install of Yellow Dog Linux
on the PS/3, with plib.

What I've found out:

- The assert goes away if I remove change ssgVtxArray.cxx
  in ssgVtxArray::draw_geometry() I replace the 
  glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
  and glPopClientAttrib() with a 
  glDisableClientState ( GL_VERTEX_ARRAY ) ;

- Most plib examples work with the fix, yet some do not render
  geometry, and some even crash my X11.

- I suspect this is a protocol mismatch issue.
  I think the client and server of GLX are using different opcodes.
  The assert seems to get triggered even when glTexCoordPointer is
  not used.

thx

  Bram

[Plib-devel] Out for ten days

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 
Gentlemen,

	I will be away from my keyboard/mouse for the next ten days or so;
if something comes up that needs putting into SVN, if nobody else handles it
while I'm gone I will get to it when I return.  I just don't want anybody to
think I had lost interest.

	- John Fay

Re: [Plib-devel] 32 bit integer button limit

[Andy R. <an...@pl...>]

Steve Baker wrote:
 > Look: the problem with supporting more than 32 buttons is
 > that only one guy with only one application needs it

No, this is actually a rather common stick.  It is comparatively
inexpensive.  You can buy them at retail stores pretty much
everywhere.  I have one too.  It's the follow-on product to a
very successful stick (the X-45) that I've recommended to many
FlightGear users over the past several years.

Sorry, but the 32 button limit is a real problem affecting real
people, and one for which you guys need to come up with a
solution.  The bitmask was a poor API choice, and isn't scaling
to common joystick hardware.  You can't brush this one under the
rug via an invocation of KISS, sorry.

Andy

[Plib-devel] arbitrarily many buttons

[John D. <sf...@av...>]

On 01/02/2007 11:41 AM, I wrote:

> With the amount of effort people have spent arguing about whether
> it's a bug or not, we could have fixed the bug already.

If anyone doubts this point, take a look at
  http://www.av8n.com/fly/fgfs/js.h
  http://www.av8n.com/fly/fgfs/js.cxx
  http://www.av8n.com/fly/fgfs/jsLinux.cxx

The new features are there, notably support for arbitrarily
many buttons.

The old interface is still there and is upward-compatible.

The only change is that for buttons numbered 32 and higher,
their actions are silently discarded by the legacy interface.
(In contrast all previous versions produced an undefined result
in response to high-numbered buttons.)

For regression testing of the old features, you can use whatever
old programs you like.  Obviously I haven't had time for extensive
testing, but I did some basic "smoke tests" using the js_demo
program that comes in the FlightGear package.  There shouldn't be
any change except the bugfix noted above.

A example/test program that exercises the _new_ features can be
found at:
  http://www.av8n.com/fly/fgfs/js_test.cxx

If there is any doubt of how to compile js_test, all you need to
know is that it is a descendant of js_demo.

I didn't touch (or even look at) jsWindows or jsMacOS.  I can't
imagine there will be any trouble with those, because the stuff
I touched wasn't machine dependent.

On 01/02/2007 05:10 PM, steve wrote:
>>  only one guy with only one application needs it

False.  The archives indicate that this topic has come up more
than once.  Previous guys got the brush-off.

>> the rest of us can't test the code, 

Also false, indeed absurd.  We have here an entire community of
simulation aficionados;  perhaps "somebody" might figure out a
way of /simulating/ the existence of high-numbered buttons.

Forsooth, if you look at the new js.h you will find some DfT
(Design for Test) features already built in, along with a brief
explanation of how to use them.  The JS_SHIFT parameter allows
folks to test arbitrarily high-numbered buttons using only modest,
generic hardware.

DfT is important.  If you want to have a polite discussion of DfT,
we can discuss it.

Re: [Plib-devel] 32 bit integer button limit

[steve <sjb...@ai...>]

Look: the problem with supporting more than 32 buttons is
that only one guy with only one application needs it - the
rest of us can't test the code, we can't maintain the code
we can't verify that it runs under MacOS and five different
flavors of windows and a couple of different Linux drivers
because none of the rest of us have (or are likely to have)
34 button joysticks - nor yet code to use it.

You have to aim projects like this at the 95% line - what
95% of the people need.  The 0.1% of people with 34
button joysticks of whom 0.1% have applications that need
all of those buttons - are just not worth the support grief.

For those very few people running those very few applications,
congratulations - it's OpenSourced - you can make a copy,
stick it into your application code and maintain it yourself.
If there are problems with it - you'll be the one that
answers the mail.

We've had MANY instances of people dumping fancy little
features into our laps then running off and never being
heard from again - it's just not useful to anyone other
than the person that first asked for it - it just adds
to the support load for the remaining few.

Keep it simple.

That's the mantra that got us this library suite in the
first place - and it's what keeps it running with very
little support from very few people.

[Plib-devel] 32 bit integer button limit

[Jim C. <j.c...@zy...>]

Hi,
The problem with only 32 bits in an integer so allowing only 32 buttons 
can be handled in a similiar fashion to the method used in standard 
unix libraries for handling file descriptors. This uses an "fd_set" 
data type which is a "descriptor set" (read button set!!) which can be 
reset,written to, read from and checked using the 
FD_ZERO,FD_SET,FD_ISSET,FD_CLR macros. File descriptors can be up to 
1024 for example so this technique can handle many buttons.(see p396 
etc of Stevens - Advanced Programming in the Unix Environment).
Also one way to build a cockpit may be to cannibalise a standard 
joystick and use the buttons and rotaries accordingly.(This allows 
re-use of existing sware without having to write new "plib" bits to 
handle for example a USB interface such as a Velleman module with 
digital/analogue input and outputs).
cheers
Jim

Re: [Plib-devel] Saitek X52 joystick with 34 buttons

[John D. <sf...@av...>]

I am reminded of the little girl who caught a tarantula and wanted
to keep it as a pet.  They make great pets;  they don't eat much,
they don't make noise, they don't smell, they don't bite, and they
exhibit a lot more interesting behavior than (say) a goldfish.  But
her father said "ewwwww, get that thing out of here".

She asked what was wrong.  He said "they give me the willies ...
too many legs."  She said that earlier she had caught a snake,
and he didn't approve of that either.  What's wrong with that?
Not enough legs?

I told her she should keep a pet tarantula *and* a pet snake.
That way there would be the right number of legs /on average/.

=============

In the case of plib I've just been told that anything less than a
full cockpit simulator isn't acceptable.  I've also told that
anything with more than 32 buttons isn't acceptable.  Hmmmm.

==========================

I'm also told the 34-buttons but is not a bug, but rather "an
application problem".

Horsefeathers.  The language spec says that an out-of-range shift
returns an _undefined_ result.

I try not to return undefined results from my code.  Customers
generally don't like that sort of thing.

With the amount of effort people have spent arguing about whether
it's a bug or not, we could have fixed the bug already.

On 01/02/2007 10:50 AM, Fay John F Dr CTR USAF AFSEO/SK wrote:

>>        .... didn't use STDLIB in the first place is that
>> when PLIB was first written, STDLIB was neither standard, nor
>> widespread, nor reliable.

I think the expiration date on that argument is long past.  The
stdlib is part of the language specification, and has been for
several years.  If there is any evidence that vector<bool> is not
reliable, you should report it through proper channels.

I say again:  with the amount of effort people have spent arguing
about whether it's a bug or not, we could have fixed the bug already.

Re: [Plib-devel] Saitek X52 joystick with 34 buttons

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

John,

	Hmmm ... it appears from Steve's latest e-mail that while you have
permission to make your own "PLIB-Denker" library he isn't really interested
in changing PLIB proper.  PLIB is licensed under the LGPL so you can make
your own copy and change it as you wish, so long as you offer your changes
back to the PLIB community itself.  It appears that the PLIB community's
response will be a polite "Thank you, but no thank you."

	The reason Steve didn't use STDLIB in the first place is that when
PLIB was first written, STDLIB was neither standard, nor widespread, nor
reliable.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of John Denker
Sent: Tuesday, January 02, 2007 9:41 AM
To: PLIB Developers
Subject: Re: [Plib-devel] Saitek X52 joystick with 34 buttons

On 01/02/2007 10:06 AM, Fay John F Dr CTR USAF AFSEO/SK wrote:
> 
>         The next step is to get Steve Baker's permission to add the
> capability without breaking the old applications.

And how do we do that?

>         Do you have one of these joysticks so that we can test the
changes?

Yes.

>         The step after that is actually to implement something.
> 
>         I have SVN access (hint:  a year ago I didn't have CVS access)
> and so things that need changing can get changed.

It seems like the obvious approach is to represent the buttons and axes
as
    vector<bool>   and
    vector<float>
respectively.

If it had been done that way all along, we wouldn't be having the bugs we
have now.

Using  vector<bool>  is the c++ way of doing things.  Indeed, one of the
reasons for inventing the c++ language was to exterminate bugs of this
kind, which are appallingly common in old-style c code.

Does anybody have any better suggestions?


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Saitek X52 joystick with 34 buttons

[John D. <sf...@av...>]

On 01/02/2007 10:06 AM, Fay John F Dr CTR USAF AFSEO/SK wrote:
> 
>         The next step is to get Steve Baker's permission to add the
> capability without breaking the old applications.

And how do we do that?

>         Do you have one of these joysticks so that we can test the changes?

Yes.

>         The step after that is actually to implement something.
> 
>         I have SVN access (hint:  a year ago I didn't have CVS access)
> and so things that need changing can get changed.

It seems like the obvious approach is to represent the buttons and axes
as
    vector<bool>   and
    vector<float>
respectively.

If it had been done that way all along, we wouldn't be having the bugs we
have now.

Using  vector<bool>  is the c++ way of doing things.  Indeed, one of the
reasons for inventing the c++ language was to exterminate bugs of this
kind, which are appallingly common in old-style c code.

Does anybody have any better suggestions?

Re: [Plib-devel] Saitek X52 joystick with 34 buttons

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

John,

	The next step is to get Steve Baker's permission to add the
capability without breaking the old applications.

	The step after that is actually to implement something.

	Do you have one of these joysticks so that we can test the changes?

	I have SVN access (hint:  a year ago I didn't have CVS access) and
so things that need changing can get changed.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of John Denker
Sent: Tuesday, January 02, 2007 12:25 AM
To: pli...@li...; John Denker
Subject: Re: [Plib-devel] Saitek X52 joystick with 34 buttons

Back in December of '05 Trammell Hudson wrote:
>> I"ve recently started using a Saitek X52 joystick with my Linux box and
>> have run into problems with plib"s JS module limitation in the number
>> of supported buttons. It only supports up to 32 buttons due to the
>> MAX_BUTTONS definition and the fact that it uses an int to store the
>> button state, but the X52 has 34 buttons (and 12 axes).

On 2005-05-04 14:20 Steve Baker replied:
> 
> That"s practically a keyboard!

(lots of good stuff snipped)

-- I think that's more-or-less all there is to it.

So, what's the next step?


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Saitek X52 joystick with 34 buttons

[steve <sjb...@ai...>]

John Denker wrote:
> Back in December of '05 Trammell Hudson wrote:
>>> I"ve recently started using a Saitek X52 joystick with my Linux box and
>>> have run into problems with plib"s JS module limitation in the number
>>> of supported buttons. It only supports up to 32 buttons due to the
>>> MAX_BUTTONS definition and the fact that it uses an int to store the
>>> button state, but the X52 has 34 buttons (and 12 axes).
> 
> On 2005-05-04 14:20 Steve Baker replied:
>> That"s practically a keyboard!
> 
> No, it's not a keyboard.
> 
> Do you have any idea how many switches and knobs there are in a
> real airplane?

Actually - yes.  I design flight simulators for a living for
L3 Link Simulation.  Every F117, F22 and F16 pilot - and
almost every F18 and helicopter pilot in the US military
was trained on one of my simulators!  Over 25 years in the
business, I've worked on simulators for over 100 different
aircraft types - and also cars, submarines, railroad
locomotives, the space shuttle and space station, air
traffic control towers and even a roller coaster.

So yeah - I have a fair idea what's involved.

> It looks like we may be approaching a culture clash:
>  -- gamer viewpoint, versus
>  -- flight instructor viewpoint.

Well, as a practical matter - if you are a serious flight
instructor and training beyond the 'stick and rudder' level,
you very much need the buttons to have the right kinds of
shape and labelling - and to be in more or less the right
place. I very much doubt that anything Saitek would produce
would be of very much use for serious training.

> Hint:  I'm coming from the flight instructor viewpoint.  There
> are reasonable people in this world who want to build PC-based
> flight simulators that are good enough to ... well ... to simulate
> flight.  You know, flight in real aircraft.

To do this properly, you need a mock-up cockpit - that means that
whilst you might use the electronics from an off-the shelf
joystick - you'll be pulling it apart and using more realistic
switches and knobs.

That means that you can (and will) need to use multiple joysticks
in order to get all of the rotary knobs and such right.

The limit of 32 per joystick controller is not at all unreasonable.

Also, if you are sufficiently hard-core to take on a project like
this, hacking your own version of the PLIB Joystick code is going
to be a very, very tiny percentage of the software work you'll
end up needing to do.

> I assure you that the X52 is a real and practical product.
> It receives good reviews in the usual places.  Indeed IMHO it does
> not have /enough/ knobs and buttons;  the X52 /plus/ a keyboard
> is marginally OK for a modest single-engine aircraft but nearly
> enough for a multi-engine aircraft, or even for a complex single.

Sure - but it IS a gaming device.  No serious flight simulator
designer would even consider using it - it's a joke from a training
perspective.  It's got a heck of a lot of buttons - but they aren't
properly labelled and they are about as far from the right places as
you could imagine - you might just as well use a keyboard for all
the relevence it has to training.  I almost fell off my chair laughing
at the "MFD" display!

The PLIB interface is 'good enough' for all but maybe one joystick
type and then in maybe one application.   The idea that 32 buttons
map onto 32 bits in an integer is a very clean, simple - and efficient
way to handle joystick buttons.  To hack all of that around to deal
with one or two types joystick and for a very, very special class
of user...it's ridiculous.

Please feel free to take the PLIB joystick code and make your
own version of it - it's under LGPL - so there aren't obstacles
to doing that.

Right now - I'm not interested in supporting more than 32
buttons.   If these kinds of devices become ubiquitous and
lots of applications demand them - I might reconsider - but
in general, the world is moving away from joysticks as gamer
interfaces.

> These are rather significant bugs.  If you roll the trim wheel
> it fires the gun!

That's an application problem - PLIB gives you the axes and
buttons in the order the joystick provides them.  The meaning
of them is entirely down to what the application does with them.

Re: [Plib-devel] Saitek X52 joystick with 34 buttons

[John D. <sf...@av...>]

On 01/02/2007 01:25 AM, I wrote:

>       void nread    ( unsigned char *buttons, const size_t nb,
>                               float *axes, const size_t na ) ;

That is, of course, the pedestrian approach.  If I were designing
the code, I would seriously consider using stdlib vectors instead.
There's not much you can do with a float* that you can't do as well
(or better) with a vector<float>.

The compatibility non-issues remain non-issues for the same reasons.

Reference:
  http://www.cprogramming.com/tutorial/stl/vector.html

Re: [Plib-devel] Saitek X52 joystick with 34 buttons

[John D. <sf...@av...>]

Back in December of '05 Trammell Hudson wrote:
>> I"ve recently started using a Saitek X52 joystick with my Linux box and
>> have run into problems with plib"s JS module limitation in the number
>> of supported buttons. It only supports up to 32 buttons due to the
>> MAX_BUTTONS definition and the fact that it uses an int to store the
>> button state, but the X52 has 34 buttons (and 12 axes).

On 2005-05-04 14:20 Steve Baker replied:
> 
> That"s practically a keyboard!

No, it's not a keyboard.

Do you have any idea how many switches and knobs there are in a
real airplane?

It looks like we may be approaching a culture clash:
 -- gamer viewpoint, versus
 -- flight instructor viewpoint.

Hint:  I'm coming from the flight instructor viewpoint.  There
are reasonable people in this world who want to build PC-based
flight simulators that are good enough to ... well ... to simulate
flight.  You know, flight in real aircraft.

I assure you that the X52 is a real and practical product.  It
receives good reviews in the usual places.  Indeed IMHO it does
not have /enough/ knobs and buttons;  the X52 /plus/ a keyboard
is marginally OK for a modest single-engine aircraft but nearly
enough for a multi-engine aircraft, or even for a complex single.

If you just want to fly around and look at the scenery, then you
don't need dozens and dozens of buttons.  But please don't assume
what /you/ want is what everybody else wants.

> Changing PLIB to support more than 32 buttons would break 100% of
> joystick using applications.

Not if it it's done properly.

It can be done upward-compatibly.  It doesn't even require a
major release;  a few hours of work and a minor point-release
would be quite sufficient, unless I am much mistaken.

> I personally find it very hard to believe that there are any
> applications out there that would actually use that many 

Maybe you can't imagine such applications, but there are plenty
of people who can.

> If there is a bug to fix in *limiting* the number of buttons
> to 32 - then we should fix that.

These are rather significant bugs.  If you roll the trim wheel
it fires the gun!

Here we are more than a year after the initial report and the
bugs still haven't been fixed.  They haven't even made it into
the TODO files AFAICT.

>> Changing tmp_buttons to a uint64_t, updating the arguments to
>> jsJoystick::rawRead and jsJoystick::read fixed that for me.

That's not the smart solution.  There are multiple problems with
that.

> But it would break other applications. We absolutely cannot do that.

So we need to do something else.

Hey, this isn't rocket science.  We can see how to do it by
looking at how  snprintf  was introduced.  It solved a big set
of problems and did *not* require breaking any old applications.

Here's how this applies to the present case:

-- In line 70 of js.h, define getNumButtons() in analogy to getNumAxes().

-- In *addition* to (not instead of) things like this:
      void read    ( int *buttons, float *axes ) ;
   we need to define
      void nread    ( unsigned char *buttons, const size_t nb,
                              float *axes, const size_t na ) ;

-- Then anybody who wants to call nread is free to do so.  (FWIW
   the name "nread" could be simply "read";  the c++ overloading
   features are quite capable of figure out which function is wanted.)

-- On the other side of the coin, people who don't know (or don't
   care) are free to continue calling the old read(,) function.

-- We put all the smarts in the nread(,,,) function.  The read(,)
   function is easily implemented in terms of nread(,4,,) plus a
   call to ntohl().  It's not rocket science.

-- In nread(,,,), the number of buttons returned is limited by the
   number of buttons that exist /or/ by the amount of space available,
   whichever is less.

-- I think that's more-or-less all there is to it.

So, what's the next step?

Re: [Plib-devel] Windows, multiple joystick support

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Oh, and to make things perfectly clear, I did put the patch into SVN.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Fay John F Dr
CTR USAF AFSEO/SK
Sent: Thursday, December 21, 2006 2:54 PM
To: 'PLIB Developers'
Subject: Re: [Plib-devel] Windows, multiple joystick support

Jonah, 

        Hello and welcome to the PLIB development community.  Thank you for
the patch. 

        I had a question about the platform-independence of your patch, but
it seems that at least the BSD code supports more than one joystick.  So
that appears not to be an issue.

        Your timing is superb; I am leaving for a week in about two hours.
If anybody has a heartburn over this patch, please either let me know
prestissimo, wait a week, or ask somebody else to take it out.

        Incidentally, a different patch format would help people.  In that
format (which you can get in Linux with a "diff -u" command, I think),
unchanged lines are unmarked, lines that are deleted are preceded by a "-",
and lines that are added are preceded by a "+".

John F. Fay 
Technical Fellow 
Jacobs/Sverdrup TEAS Group 
850-883-1294 

-----Original Message----- 
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Jonah
Williams (RIT Student)

Sent: Thursday, December 21, 2006 2:36 PM 
To: pli...@li... 
Subject: Re: [Plib-devel] Windows, multiple joystick support 


Would a member of the devel list be kind enough to grant me access to commit
changes to subversion or commit the following patch for me?

In jsWindows.cxx I suggest replacing the current constructor with the
following code to allow support for more than 2 joystick devices. Windows 95
and higher support at least 16 devices and there does not seem to be any
reason why plib should artificially limit itself to only 2.

jsJoystick::jsJoystick ( int ident ) 
{ 
  id = ident ; 
  os = new struct os_specific_s; 

  if (ident >= 0 && ident < joyGetNumDevs()) { 
        os->js_id = JOYSTICKID1 + ident; 
        open(); 
  } 
  else { 
        num_axes = 0; 
        setError(); 
  } 
} 

joyGetNumDevs() is documented here:
http://msdn2.microsoft.com/en-us/library/ms709351.aspx 

Thanks, 
-Jonah (sourceforge account "jw_rit") 

Re: [Plib-devel] Windows, multiple joystick support

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Jonah,

	Hello and welcome to the PLIB development community.  Thank you for
the patch.

	I had a question about the platform-independence of your patch, but
it seems that at least the BSD code supports more than one joystick.  So
that appears not to be an issue.

	Your timing is superb; I am leaving for a week in about two hours.
If anybody has a heartburn over this patch, please either let me know
prestissimo, wait a week, or ask somebody else to take it out.

	Incidentally, a different patch format would help people.  In that
format (which you can get in Linux with a "diff -u" command, I think),
unchanged lines are unmarked, lines that are deleted are preceded by a "-",
and lines that are added are preceded by a "+".

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Jonah
Williams (RIT Student)
Sent: Thursday, December 21, 2006 2:36 PM
To: pli...@li...
Subject: Re: [Plib-devel] Windows, multiple joystick support


Would a member of the devel list be kind enough to grant me access to commit
changes to subversion or commit the following patch for me?

In jsWindows.cxx I suggest replacing the current constructor with the
following code to allow support for more than 2 joystick devices. Windows 95
and higher support at least 16 devices and there does not seem to be any
reason why plib should artificially limit itself to only 2.

jsJoystick::jsJoystick ( int ident )
{
  id = ident ;
  os = new struct os_specific_s;

  if (ident >= 0 && ident < joyGetNumDevs()) {
        os->js_id = JOYSTICKID1 + ident;
        open();
  }
  else {
        num_axes = 0;
        setError();
  }
}

joyGetNumDevs() is documented here:
http://msdn2.microsoft.com/en-us/library/ms709351.aspx

Thanks,
-Jonah (sourceforge account "jw_rit")