plib-devel

Re: [Plib-devel] code for joystick in Solaris

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Thanks for the reminder, I will add it to my list of things to do
tonight.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Martin
Spott
Sent: Friday, September 14, 2007 7:13 AM
To: pli...@li...
Subject: Re: [Plib-devel] code for joystick in Solaris

May I remind PLIB developers of the patch and the corresponding thread:

Mark Francis Villa wrote:

> I created a patch for PLIB's 'js' code to add support for joysticks
> in Solaris using 'libusb'.
>=20
> Documentation:
>=20
> http://www.dpo.uab.edu/~drmark/Solaris/README_Solaris.html
>=20
>=20
> Source Download:
>=20
>
http://www.dpo.uab.edu/~drmark/Solaris/PLIB_Patch_Protoype_For_Solaris_2
0060808.tgz

	Martin.
--=20
 Unix _IS_ user friendly - it's just selective about who its friends are
!
------------------------------------------------------------------------
--

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] A new plib release?

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Joerg,

	Your first change, from "IOkitLib" to "IOKitLib", has not been
implemented.  The second change, removing the "static" from the function
definition, has been implemented.  I'm at work now so I can't get to
SVN, but I will put the first change in when I get home tonight.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Joerg
Henrichs
Sent: Thursday, September 13, 2007 9:15 PM
To: PLIB Developers
Subject: Re: [Plib-devel] A new plib release?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again,

I just checked with the SuperTuxKart documentation for the Mac, and
there are two more changes they have to do ... sorry, missed that
before:

1) In jsMacOSX.cxx replace
        #include <IOKit/IOkitLib.h>
   with:
        #include <IOKit/IOKitLib.h>

2) In jsMacOSX.cxx replace:
       static void os_specific_s::elementEnumerator( const void
             *element, void* vjs)
   with
       void os_specific_s::elementEnumerator( const void
             *element, void* vjs)

As mentioned before, I can't really comment on that (but if you need any
information I can try contacting the Mac people on our team, though that
might take a few days since they are busy at the moment).

Cheers,
   Joerg

- --
- ----------------------------------------------------------------
Joerg Henrichs
Luding Administration
e-mail: jo...@lu...
URL:    http://luding.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6e6oLC0mrNKFwF4RAjtVAJ9on6CKgFADaJHmbKOPrQGiuacfZACgj5Zd
04mbUtJHha/r9mGLoSJKLn8=3D
=3DXTru
-----END PGP SIGNATURE-----

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] A new plib release?

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Joerg,

	The first fix, to "ssgLoadAC.cxx", is indeed in.  I haven't
looked at the "pwMacOSX.cxx" file itself, but the last check-in to SVN
has the comment "pw macosx fixes by Hayden M." so I think we're covered.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Joerg
Henrichs
Sent: Thursday, September 13, 2007 9:10 PM
To: PLIB Developers
Subject: Re: [Plib-devel] A new plib release?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I am not using the current SVN version of plib (and am too busy atm to
check it out - sorry), but it would be nice if you could check that the
following fixes are in:

1) In src/ssg/ssgLoadAC.cxx replace:
      loader_fd =3D fopen ( filename, "ra" ) ;
   with
      loader_fd =3D fopen ( filename, "r" ) ;

   Since 'ra' is not accepted by visual C (or #ifdef this).

2) Attached a new version of pwMacOSX.cxx. This file was
   given to the SuperTuxKart team by Hayden M.
   (contact me if you need the email address), with the following
   comments:

"""
...
The clipping issues are due to PW, when it initialises AGL it doesn't
set the z-buffer depth. I guess AGL defaults to 8bit.

Also PW has some other issues with the menubar in Mac OS X. Carbon's
functions read past the end of the string (upto 255 chars). So on the
end of every string being displayed there would be an extra (255 -
string length) characters from whatever's after it on the stack. Also
clicking anywhere on the menubar caused the game to quit.

I've attached the fixed PW src file (pwMacOSX.cxx). I don't know what
you can do with it, I guess include a patch for plib or include plib
itself in the src archive. As far as I can tell plib is no longer
maintained (?).

The only significant change I made was setting z-buffer to 32bit. I'm
not sure how this will affect other mac users but I don't think it will
cause much issues.
"""

Not having a Mac I can't really comment on that, but I know that the
people creating the Mac binary package for SuperTuxKart always have to
patch plib with this file to get it to work.

Good luck with the new release!

Cheers,
   Joerg


- --
- ----------------------------------------------------------------
Joerg Henrichs
Luding Administration
e-mail: jo...@lu...
URL:    http://luding.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6e1xLC0mrNKFwF4RAlihAKC8NZUVBZRnvRn3sLeDPRkCTGomGgCfYOU6
RkqjYyC3GmIb6aYw5PD/aYQ=3D
=3D7jp8
-----END PGP SIGNATURE-----

[Plib-devel] Serious problem with Windows SVN build

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Gentlemen,

	While trying to build the examples in my SVN tree last night I
realized that the SVN checkout no longer puts the top-level PLIB
directory files into a directory named "plib".  This means that the
"#include <plib/ul.h>" statements are now broken.  Has anybody run into
this before?  What do you propose that we do about it?

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

Re: [Plib-devel] code for joystick in Solaris

[Martin S. <Mar...@mg...>]

May I remind PLIB developers of the patch and the corresponding thread:

Mark Francis Villa wrote:

> I created a patch for PLIB's 'js' code to add support for joysticks
> in Solaris using 'libusb'.
> 
> Documentation:
> 
> http://www.dpo.uab.edu/~drmark/Solaris/README_Solaris.html
> 
> 
> Source Download:
> 
> http://www.dpo.uab.edu/~drmark/Solaris/PLIB_Patch_Protoype_For_Solaris_20060808.tgz

	Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] A new plib release?

[Joerg H. <jo...@lu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again,

I just checked with the SuperTuxKart documentation for the Mac, and
there are two more changes they have to do ... sorry, missed that before:

1) In jsMacOSX.cxx replace
        #include <IOKit/IOkitLib.h>
   with:
        #include <IOKit/IOKitLib.h>

2) In jsMacOSX.cxx replace:
       static void os_specific_s::elementEnumerator( const void
             *element, void* vjs)
   with
       void os_specific_s::elementEnumerator( const void
             *element, void* vjs)

As mentioned before, I can't really comment on that (but if you need any
information I can try contacting the Mac people on our team, though that
might take a few days since they are busy at the moment).

Cheers,
   Joerg

- --
- ----------------------------------------------------------------
Joerg Henrichs
Luding Administration
e-mail: jo...@lu...
URL:    http://luding.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6e6oLC0mrNKFwF4RAjtVAJ9on6CKgFADaJHmbKOPrQGiuacfZACgj5Zd
04mbUtJHha/r9mGLoSJKLn8=
=XTru
-----END PGP SIGNATURE-----

Re: [Plib-devel] A new plib release?

[Joerg H. <jo...@lu...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I am not using the current SVN version of plib (and am too busy atm to
check it out - sorry), but it would be nice if you could check that the
following fixes are in:

1) In src/ssg/ssgLoadAC.cxx replace:
      loader_fd = fopen ( filename, "ra" ) ;
   with
      loader_fd = fopen ( filename, "r" ) ;

   Since 'ra' is not accepted by visual C (or #ifdef this).

2) Attached a new version of pwMacOSX.cxx. This file was
   given to the SuperTuxKart team by Hayden M.
   (contact me if you need the email address), with the following
   comments:

"""
...
The clipping issues are due to PW, when it initialises AGL it doesn't
set the z-buffer depth. I guess AGL defaults to 8bit.

Also PW has some other issues with the menubar in Mac OS X. Carbon's
functions read past the end of the string (upto 255 chars). So on the
end of every string being displayed there would be an extra (255 -
string length) characters from whatever's after it on the stack. Also
clicking anywhere on the menubar caused the game to quit.

I've attached the fixed PW src file (pwMacOSX.cxx). I don't know what
you can do with it, I guess include a patch for plib or include plib
itself in the src archive. As far as I can tell plib is no longer
maintained (?).

The only significant change I made was setting z-buffer to 32bit. I'm
not sure how this will affect other mac users but I don't think it will
cause much issues.
"""

Not having a Mac I can't really comment on that, but I know that the
people creating the Mac binary package for SuperTuxKart always have to
patch plib with this file to get it to work.

Good luck with the new release!

Cheers,
   Joerg


- --
- ----------------------------------------------------------------
Joerg Henrichs
Luding Administration
e-mail: jo...@lu...
URL:    http://luding.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6e1xLC0mrNKFwF4RAlihAKC8NZUVBZRnvRn3sLeDPRkCTGomGgCfYOU6
RkqjYyC3GmIb6aYw5PD/aYQ=
=7jp8
-----END PGP SIGNATURE-----

Re: [Plib-devel] patch for current svn

[John F. F. <joh...@cy...>]

Gentlemen,

	I have just put this patch into SVN.  Please download the new version and 
check whether it still works with your applications.

	The patch was put in from a Window machine.  It would be good also if 
people were to check for Windows line endings and, if any are found, please 
remove them.

		- John Fay


-----Original Message-----
From:	Olaf Flebbe
Sent:	Thursday, September 13, 2007 2:31 PM
To:	PLIB Developers
Subject:	Re: [Plib-devel] patch for current svn

John,

>
> 	Thank you very much for your contribution here.  Did I get it right that 
you have already put the patch into SVN, or do you need somebody to put it 
in for you?
>

No, I do not have SVN access. I kindly ask a plib developer to apply it,
or explain to me how to improve this patch.

Cheers
Olaf

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] patch for current svn

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Gentlemen,

	I do not have SVN access from work any more, but I should be
able to do this from home.  Unless somebody speaks, and speaks quickly,
I will most likely put Olaf's patch into SVN tonight--in the next six
hours or so.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Olaf
Flebbe
Sent: Thursday, September 13, 2007 2:31 PM
To: PLIB Developers
Subject: Re: [Plib-devel] patch for current svn

John,

>=20
> 	Thank you very much for your contribution here.  Did I get it
right that you have already put the patch into SVN, or do you need
somebody to put it in for you?
>=20

No, I do not have SVN access. I kindly ask a plib developer to apply it,

or explain to me how to improve this patch.

Cheers
Olaf

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] patch for current svn

[Olaf F. <fg...@of...>]

John,

> 
> 	Thank you very much for your contribution here.  Did I get it right that you have already put the patch into SVN, or do you need somebody to put it in for you?
> 

No, I do not have SVN access. I kindly ask a plib developer to apply it, 
or explain to me how to improve this patch.

Cheers
Olaf

Re: [Plib-devel] patch for current svn

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Olaf,

	Thank you very much for your contribution here.  Did I get it right =
that you have already put the patch into SVN, or do you need somebody to =
put it in for you?

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li... =
[mailto:pli...@li...] On Behalf Of olaf =
flebbe
Sent: Friday, September 07, 2007 2:43 PM
To: pli...@li...
Subject: [Plib-devel] patch for current svn

Hi,

I just updated my patch for plib to the current SVN. There is a real bug
in src/ssg/ssgLoadMDL_BGLTexture.cxx

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1584727&grou=
p_id=3D382&atid=3D100382

If one would supply the Texture Loader with a character constant like
"example.0af_100"  the TextureLoader will bomb, because it will try to
write into the constant placed into R/O memory.

The bug is hidden under a workaround for standard conforming strchr()
implementations which I cleaned up. (The rest of the patch)

<standard blurb>
  strchr is defined in ANSI C++ =A721.4.4  as

      char *strchr( char *, int);
      const char *strchr( const char *, int);

  (the fine point: it is only required to be in <cstring>, but anyway)

  in contrast to ANSI C (For instance 7.21.5.2 in
      http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf)

      char *strchr( const char *, int);

  This is one of the tiny differences between ANSI C++ and ANSI C.Please
  see for instance http://david.tribble.com/text/cdiffs.htm

  Unfortunatly GNU C++/glibc is not conforming to ANSI C++ by only
defining

   char *strchr( const char *, int); // see yourself in <string.h>
                                     //                 <cstring>

</standard blurb>

The quintessence is: plib code compiles perfectly for Linux (except for
the runtime problem mentioned above), but not for an ANSI C++ standard
conforming strchr() implementation. As a side effect the code now works
even for MSVC8. It should work for gcc, SUN Studio too.

I like to get a fix upstream, because compiling plib is a prerequisite
for the next planned FlightGear release.

Please apply.

Thanks,
    Olaf


-------------------------------------------------------------------------=

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] A new plib release?

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Steve,

	I signed up last night from home as "fayjf2".  If you will sign
me on as an admin I will get the thing out the door.



Everybody else,

	If you have anything you want to get into PLIB before the
feature freeze please announce it immediately and put the changes in as
soon as possible.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Steve
Baker
Sent: Saturday, September 08, 2007 11:30 AM
To: PLIB Developers
Subject: Re: [Plib-devel] A new plib release?

If someone else would care to do it - I'll make sure they have whatever=20
admin privilages
are needed.

    Steve.


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] simple tessellation help

[Peijing <est...@si...>]

Hi,
I'm new to plib and I need to create a rectangular polygon with a triangular 
hole like this:
_______
|           |
|__/\___|

but I do not know how to do this with plibs. I've got some examples from the 
opengl redbook and I'm looking for a plib equivalent of it.
Could someone enlighten me regarding how to go about doing this or any 
online references I can refer to?

The opengl code is such:
 GLUtesselator *tobj;

  GLdouble rect[4][3] = {50.0, 50.0, 0.0,
                          200.0, 50.0, 0.0,
                          200.0, 200.0, 0.0,
                          50.0, 200.0, 0.0};
   GLdouble tri[3][3] = {75.0, 75.0, 0.0,
                         125.0, 175.0, 0.0,
                         175.0, 75.0, 0.0};

   glClearColor(0.0, 0.0, 0.0, 0.0);

   startList = glGenLists(2);

   tobj = gluNewTess();
   gluTessCallback(tobj, GLU_TESS_VERTEX,
                   glVertex3dv);
   gluTessCallback(tobj, GLU_TESS_BEGIN,
                   beginCallback);
   gluTessCallback(tobj, GLU_TESS_END,
                   endCallback);
   gluTessCallback(tobj, GLU_TESS_ERROR,
                   errorCallback);

   /*  rectangle with triangular hole inside  */
   glNewList(startList, GL_COMPILE);
   glShadeModel(GL_FLAT);
   gluTessBeginPolygon(tobj, NULL);
      gluTessBeginContour(tobj);
         gluTessVertex(tobj, rect[0], rect[0]);
         gluTessVertex(tobj, rect[1], rect[1]);
         gluTessVertex(tobj, rect[2], rect[2]);
         gluTessVertex(tobj, rect[3], rect[3]);
      gluTessEndContour(tobj);
      gluTessBeginContour(tobj);
         gluTessVertex(tobj, tri[0], tri[0]);
         gluTessVertex(tobj, tri[1], tri[1]);
         gluTessVertex(tobj, tri[2], tri[2]);
      gluTessEndContour(tobj);
   gluTessEndPolygon(tobj);
   glEndList();
   gluDeleteTess(tobj);

Any help is appreciated.

Thanks,
EL 

Re: [Plib-devel] A new plib release?

[Steve B. <st...@sj...>]

Durk Talsma wrote:
> Dear Plib developers,
>
> Just to follow-up on Olaf Flebbe's message posted yesterday. FlightGear is 
> currently preparing for the release of version 0.9.11. I am currently 
> assisting Curt Olson in investigating FlightGear's dependencies. While we 
> currently still support plib 1.8.4, we found a number of reasons that make it 
> desirable to switch to a higher version. These reasons include the patch 
> proposed by Olaf yesterday, but also the fact that the released version of 
> plib no longer compiles on some systems, including my not so very bleeding 
> edge Linux box. (The compilation error has long since been fixed in CVS/SVN). 
> In addition to that, the current plib SVN contains many other bugfixes and 
> features that would be useful for FlightGear.
>
> To make a long story short: I would like to inquire if there is any 
> possibility of seeing a new Plib release in the near future. We haven't set a 
> firm release date yet, but I would like to be ready for the new release 
> around October 1st.
>
> Thanks in advance,
> Durk
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>   
We're certainly overdue for a release - but I'm not going to have the 
time to do it.

If someone else would care to do it - I'll make sure they have whatever 
admin privilages
are needed.

    Steve.

Re: [Plib-devel] A new plib release?

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

Am Sat, 8 Sep 2007 08:17:53 +0200 schrieb Durk Talsma <d.t...@xs...>:

> To make a long story short: I would like to inquire if there is any 
> possibility of seeing a new Plib release in the near future. We haven't set a 
> firm release date yet, but I would like to be ready for the new release 
> around October 1st.

Please add me to the list of developers waiting for a new PLIB release...
I'm using PLIB in the CRRCsim project and would really like to see
all the 3D model loader fixes since 1.8.4 in the next CRRCsim
release. Especially the fixed .x-loader would help those users who'd
like to convert FMS models made with Metasequoia into CRRCsim models.

Kind regards,
Jan R.

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

[Plib-devel] A new plib release?

[Durk T. <d.t...@xs...>]

Dear Plib developers,

Just to follow-up on Olaf Flebbe's message posted yesterday. FlightGear is 
currently preparing for the release of version 0.9.11. I am currently 
assisting Curt Olson in investigating FlightGear's dependencies. While we 
currently still support plib 1.8.4, we found a number of reasons that make it 
desirable to switch to a higher version. These reasons include the patch 
proposed by Olaf yesterday, but also the fact that the released version of 
plib no longer compiles on some systems, including my not so very bleeding 
edge Linux box. (The compilation error has long since been fixed in CVS/SVN). 
In addition to that, the current plib SVN contains many other bugfixes and 
features that would be useful for FlightGear.

To make a long story short: I would like to inquire if there is any 
possibility of seeing a new Plib release in the near future. We haven't set a 
firm release date yet, but I would like to be ready for the new release 
around October 1st.

Thanks in advance,
Durk

[Plib-devel] patch for current svn

[olaf f. <fg...@of...>]

Hi,

I just updated my patch for plib to the current SVN. There is a real bug
in src/ssg/ssgLoadMDL_BGLTexture.cxx

http://sourceforge.net/tracker/index.php?func=detail&aid=1584727&group_id=382&atid=100382

If one would supply the Texture Loader with a character constant like
"example.0af_100"  the TextureLoader will bomb, because it will try to
write into the constant placed into R/O memory.

The bug is hidden under a workaround for standard conforming strchr()
implementations which I cleaned up. (The rest of the patch)

<standard blurb>
  strchr is defined in ANSI C++ §21.4.4  as

      char *strchr( char *, int);
      const char *strchr( const char *, int);

  (the fine point: it is only required to be in <cstring>, but anyway)

  in contrast to ANSI C (For instance 7.21.5.2 in
      http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf)

      char *strchr( const char *, int);

  This is one of the tiny differences between ANSI C++ and ANSI C.Please
  see for instance http://david.tribble.com/text/cdiffs.htm

  Unfortunatly GNU C++/glibc is not conforming to ANSI C++ by only
defining

   char *strchr( const char *, int); // see yourself in <string.h>
                                     //                 <cstring>

</standard blurb>

The quintessence is: plib code compiles perfectly for Linux (except for
the runtime problem mentioned above), but not for an ANSI C++ standard
conforming strchr() implementation. As a side effect the code now works
even for MSVC8. It should work for gcc, SUN Studio too.

I like to get a fix upstream, because compiling plib is a prerequisite
for the next planned FlightGear release.

Please apply.

Thanks,
    Olaf

[Plib-devel] R: Dynamic Overlay Texture

[Paolo L. <p.l...@ci...>]

________________________________

	Da: pli...@li...
[mailto:pli...@li...] Per conto di Noah =
Brickman
	Inviato: luned=EC 2 luglio 2007 19.43
	A: 'Noah Brickman'; pli...@li...
	Oggetto: [Plib-devel] Dynamic Overlay Texture
	=09

	I=92m looking into adding a dynamic overlay texture to Plib. I=92ll be
copying frames of video data into the overlay texture for some HUD-like
features in Flightgear. If anyone could give me some suggestions as to =
where
to get started with this I would be most grateful. I=92ve set this up =
with
some other graphics libraries but I=92m totally new to Plib.  I=92m =
guessing
that it needs to be added to the SSG component, but beyond that I=92m =
starting
from scratch.

I'm not sure to have understood your needs, yet updating an SSG texture
(i.e. the texture set for a ssgSimpleState, i.e. the SSG "material" =
node)
can be done this way:

1. in your update_texture function, which could be called by your GLUT =
idle
callback,
  - get the state pointer in some way (could be the state set for a leaf
node), then its texture handle:
	ssgSimpleState *state /* =3D leaf->getState() */;  // or any other way
to get it
	ssgTexture *tex =3D state->getTexture();
	if ( tex ) GLuint tex_id =3D tex->getTextureHandle();
  - bind and update it through OpenGL calls:
	glBindTexture( GL_TEXTURE_2D, tex_id );
	glTexSubImage2D(
		GL_TEXTURE_2D,
		0 /* map level */,
		x, y, dx, dy, /* offset, size */
		GL_RGB /* internal format */,  // or whatever
		GL_UNSIGNED_BYTE /* type */,   // or whatever
		bmp_data /* image data */
	);
	glBindTexture( GL_TEXTURE_2D, 0 );  // unbind

2. now your texture gets updated, so the next ssgCullAndDraw will use =
the
update texture. If you need to modify the texture matrix, just do it =
through
leaf pre/post-draw callbacks, not in state pre-apply (since you'll not =
get
the control on the state post-apply for resetting the matrix):

	// in the setup stage, find the leaf node using the state with
texture update facility
	// in some way, e.g. searching by name
	ssgLeaf *leaf =3D scene->getByName( "leaf name here" );
	if ( leaf ) {
		leaf->setCallback( SSG_CALLBACK_PREDRAW, leaf_pre_cb );
		leaf->setCallback( SSG_CALLBACK_POSTDRAW, leaf_post_cb );
	}

// these are sample callbacks for changing the texture matrix

int leaf_pre_cb( ssgEntity *obj ) {
	glMatrixMode( GL_TEXTURE );
	glLoadMatrixf( (float *)tex_matrix );  // as far as tex_matrix is a
sgMat4
	// more tex xforms here such as glTranslatef, ...
	return TRUE;
}

int leaf_post_cb( ssgEntity *obj ) {
	// resetting texture matrix and matrix mode
	glMatrixMode( GL_TEXTURE );
	glLoadIdentity();
	glMatrixMode( GL_MODELVIEW );
	return TRUE;
}

Such approach is suitable when the texture to be updated is used by some =
SSG
node - alternatively if you need to draw a full-screen texture quad in =
HUD
mode with no relation to 3D and the scene graph you could prefer to do =
it
entirely in OpenGL by setting up a gluOrtho2D projection mode.

	Thanks,

	-Noah

Greetings -

Paolo

[Plib-devel] Dynamic Overlay Texture

[Noah B. <no...@sy...>]

I'm looking into adding a dynamic overlay texture to Plib. I'll be copying
frames of video data into the overlay texture for some HUD-like features in
Flightgear. If anyone could give me some suggestions as to where to get
started with this I would be most grateful. I've set this up with some other
graphics libraries but I'm totally new to Plib.  I'm guessing that it needs
to be added to the SSG component, but beyond that I'm starting from scratch.

 

Thanks,

-Noah

[Plib-devel] Offer for a VRML2 to SSG converter

[Paolo L. <p.l...@ci...>]

Dear Plib SSG friends,

I have written a 3D model file converter from the VRML2/97/X3D to SSG, which
I'd like to offer in source code to the Plib community. It is based on the
CyberX3D library (http://www.cybergarage.org/vrml/cx3d/cx3dcc/index.html),
which, in turn, relies on the xerces-c XML parsing library
(http://xml.apache.org/xerces-c/). All the libraries and the converter are
multi-platform, even if I'll only supply MS VC++ 6/Express project files
(Windows) and the Win32 exe.
The converter includes optimization option on the command line, and loads
every non-VRML file through ssgLoad, so it can also be used for model
conversion and optimization.

In principle it would be quite easy to make it a SSG format loader (it
actually reads the VRML data into its own scene graph, then this is walked
for conversion into corresponding SSG nodes), but the dependency on these
additional libraries doesn't properly fit into the Plib philosophy. On the
other hand it's hard to start from scratch for every model format. I choose
CyberX3D over other similar libraries for the easiness to walk the
scenegraph, and because nodes are very similar, and are accessed similarly,
to the SSG ones.

In the present form we could consider to put it into the "tools" section of
the distribution.

Greetings -

Paolo Leoncini

Re: [Plib-devel] How many triangles in a leaf?

[Vikas N K. <vik...@us...>]

Hi John and Paolo,

As you might already know,
unsigned int is always 4 bytes.
short is 2 bytes (signed and unsigned).

So going to assembly syntax on x86 and x86-64 machines, unsigned int
will read values from the register EAX wheras short will read values
from the register AX.

If for example, the user's applicaiton is doing tricky bitmap stuff
with the 2 byte short values, then it might break his code if you move
from short* to unsigned int* because now suddenly the memory is 4
bytes and a rotate bit operation will not work the way it should.

As you might already know, a pointer to unsigned int points to 4 bytes
and pointer to short points to 2 bytes. Typecasting from short to
unsigned int or vice versa also will not work correctly if the user's
app is doing tricky stuff with the bits in the short.

C++ compilers "should" take care of the overloading of the functions
whether pointer or not a pointer correctly since they mangle the names
of the functions with the argument types (eg. g++ does it. On Linux,
run "nm --defined" on your object file and you can see mangled names
of symbols. Once you select your symbol of choice you can run c++filt
on it and it will show you the demangled name of the symbol.  MSFT
VC++ does it too depending on the calling convention. The standard
calling convention adds the number of bytes of size of the arguments
to the function name as well, IIRC )

if you are upgrading the function you might want to use size_t*
instead of the short* or unsigned int* so that it works fine on both
64 bit and 32 bit systems in the near future.

Regards
Vikas




On 6/19/07, Fay John F Dr CTR USAF 46 SK <joh...@eg...> wrote:
> Paolo,
>
>         SSG is not my forte, but here is my reaction.
>
> (1)  I don't think we want to keep the limitation on the number of
> vertices.  We will need a method that returns unsigned int rather than
> short.
>
> (2)  We definitely do not want to break existing applications that are
> expecting a "short *" argument type.
>
> (3)  I don't think we want two functions of the same name, one public
> and one private, with different argument types.
>
>         Something I don't know (my C++ is a little rusty) is whether
> applications will be able to distinguish between two public functions
>
> ssgVtxTable::getTriangle( int n, short *v1, short *v2, short *v3)
>
> and
>
> ssgVtxTable::getTriangle( int n, unsigned int *v1, unsigned int *v2,
> unsigned int *v3)
>
> Since the arguments are pointers, I think C++ can make the distinction.
> If this is the case, I would suggest that we add a new public function
> with "unsigned int *" arguments and that we deprecate the present
> function.
>
> John F. Fay
> Technical Fellow
> Jacobs Technology TEAS Group
> 850-883-1294
>
> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...] On Behalf Of Paolo
> Leoncini
> Sent: Tuesday, June 19, 2007 3:31 AM
> To: pli...@li...
> Subject: [Plib-devel] How many triangles in a leaf?
>
> Dear Plib friends,
>
> I'd faced again (see my post on the list "Large geometry objects and
> crash
> in ssgLOS" on 2005-11-24) with the unclear limit on the number of
> primitives
> the IndexArray can index.
>
> Even if we accept filling the VertexArray with no more than
> sizeof(short)
> vertices, the problem is that we can't index more than sizeof(short)/3
> triangles per ssgVtxTable (and derived leaf types), and it only arises
> when
> doing LOS or other queries on the geometry.
>
> Look at the code in ssgVtxArray.cxx:
>
> void ssgVtxArray::getTriangle ( int n, short *v1, short *v2, short *v3 )
> {
>   short vv1, vv2, vv3 ;
>
>   ssgVtxTable::getTriangle ( n, &vv1, &vv2, &vv3 ) ;
>
>   *v1 = *( indices -> get ( vv1 ) ) ;
>   *v2 = *( indices -> get ( vv2 ) ) ;
>   *v3 = *( indices -> get ( vv3 ) ) ;
> }
>
> ssgIndexArray::get would take unsigned int argument type, but it is fed
> with
> the results from ssgVtxTable::getTriangle, which does return short
> indices.
>
> Thus, by summarizing: max number of triangles in LOS-compatible
> ssgVtxTable
> and ssgVtxArray: 10922.
>
> For overcoming the limit we could either
>
> - leave such limitaion for ssgVtxTable, yet making
> ssgVtxArray::getTriangle
> independent of the ssgVtxTable::getTriangle call;
>
> Or
>
> - change the return type for ssgVtxTable::getTriangle indices to
> unsigned
> int;
>
> Or even
>
> - introduce a private method ssgVtxTable::getTriangle( int n, unsigned
> int
> *v1, unsigned int *v2, unsigned int *v3 ), and call this from both the
> official ssgVtxTable::getTriangle ( int n, short *v1, short *v2, short
> *v3 )
> and from the ssgVtxArray::getTriangle above.
>
> Waiting for reactions -
>
> Paolo
>
>
> ------------------------------------------------------------------------
> -
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>


-- 
http://www.vikaskumar.org/

Re: [Plib-devel] How many triangles in a leaf?

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Paolo,

	SSG is not my forte, but here is my reaction.

(1)  I don't think we want to keep the limitation on the number of
vertices.  We will need a method that returns unsigned int rather than
short.

(2)  We definitely do not want to break existing applications that are
expecting a "short *" argument type.

(3)  I don't think we want two functions of the same name, one public
and one private, with different argument types.

	Something I don't know (my C++ is a little rusty) is whether
applications will be able to distinguish between two public functions

ssgVtxTable::getTriangle( int n, short *v1, short *v2, short *v3)

and

ssgVtxTable::getTriangle( int n, unsigned int *v1, unsigned int *v2,
unsigned int *v3)

Since the arguments are pointers, I think C++ can make the distinction.
If this is the case, I would suggest that we add a new public function
with "unsigned int *" arguments and that we deprecate the present
function.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Paolo
Leoncini
Sent: Tuesday, June 19, 2007 3:31 AM
To: pli...@li...
Subject: [Plib-devel] How many triangles in a leaf?

Dear Plib friends,

I'd faced again (see my post on the list "Large geometry objects and
crash
in ssgLOS" on 2005-11-24) with the unclear limit on the number of
primitives
the IndexArray can index.

Even if we accept filling the VertexArray with no more than
sizeof(short)
vertices, the problem is that we can't index more than sizeof(short)/3
triangles per ssgVtxTable (and derived leaf types), and it only arises
when
doing LOS or other queries on the geometry.

Look at the code in ssgVtxArray.cxx:

void ssgVtxArray::getTriangle ( int n, short *v1, short *v2, short *v3 )
{
  short vv1, vv2, vv3 ;

  ssgVtxTable::getTriangle ( n, &vv1, &vv2, &vv3 ) ;

  *v1 =3D *( indices -> get ( vv1 ) ) ;
  *v2 =3D *( indices -> get ( vv2 ) ) ;
  *v3 =3D *( indices -> get ( vv3 ) ) ;
}

ssgIndexArray::get would take unsigned int argument type, but it is fed
with
the results from ssgVtxTable::getTriangle, which does return short
indices.

Thus, by summarizing: max number of triangles in LOS-compatible
ssgVtxTable
and ssgVtxArray: 10922.

For overcoming the limit we could either

- leave such limitaion for ssgVtxTable, yet making
ssgVtxArray::getTriangle
independent of the ssgVtxTable::getTriangle call;

Or

- change the return type for ssgVtxTable::getTriangle indices to
unsigned
int;

Or even

- introduce a private method ssgVtxTable::getTriangle( int n, unsigned
int
*v1, unsigned int *v2, unsigned int *v3 ), and call this from both the
official ssgVtxTable::getTriangle ( int n, short *v1, short *v2, short
*v3 )
and from the ssgVtxArray::getTriangle above.

Waiting for reactions -

Paolo


------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] How many triangles in a leaf?

[Paolo L. <p.l...@ci...>]

Dear Plib friends,

I'd faced again (see my post on the list "Large geometry objects and crash
in ssgLOS" on 2005-11-24) with the unclear limit on the number of primitives
the IndexArray can index.

Even if we accept filling the VertexArray with no more than sizeof(short)
vertices, the problem is that we can't index more than sizeof(short)/3
triangles per ssgVtxTable (and derived leaf types), and it only arises when
doing LOS or other queries on the geometry.

Look at the code in ssgVtxArray.cxx:

void ssgVtxArray::getTriangle ( int n, short *v1, short *v2, short *v3 )
{
  short vv1, vv2, vv3 ;

  ssgVtxTable::getTriangle ( n, &vv1, &vv2, &vv3 ) ;

  *v1 = *( indices -> get ( vv1 ) ) ;
  *v2 = *( indices -> get ( vv2 ) ) ;
  *v3 = *( indices -> get ( vv3 ) ) ;
}

ssgIndexArray::get would take unsigned int argument type, but it is fed with
the results from ssgVtxTable::getTriangle, which does return short indices.

Thus, by summarizing: max number of triangles in LOS-compatible ssgVtxTable
and ssgVtxArray: 10922.

For overcoming the limit we could either

- leave such limitaion for ssgVtxTable, yet making ssgVtxArray::getTriangle
independent of the ssgVtxTable::getTriangle call;

Or

- change the return type for ssgVtxTable::getTriangle indices to unsigned
int;

Or even

- introduce a private method ssgVtxTable::getTriangle( int n, unsigned int
*v1, unsigned int *v2, unsigned int *v3 ), and call this from both the
official ssgVtxTable::getTriangle ( int n, short *v1, short *v2, short *v3 )
and from the ssgVtxArray::getTriangle above.

Waiting for reactions -

Paolo

Re: [Plib-devel] code for joystick in Solaris

[Mark F. V. <dr...@ua...>]

John -

    I'm looking  at the USB code in "jsBSD.cxx" to see if we
can drop the dependency on 'libusb',  but, to my understanding,
the intent in Solaris is to use libusb for such things. From the
'ugen' (USB generic driver) man page:

     "...libusb(3LIB) uses ugen to access devices that do not contain
     drivers   such   as  digital  cameras  and  PDAs.  Refer  to
     /usr/sfw/share/doc/libusb/libusb.txt for details"


I'm also working on picking up more information about the joystick
from the USB report descriptors.

I'll try to have this posted in the next couple of days.

Thanks for the response.

- Mark

Re: [Plib-devel] code for joystick in Solaris

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

Mark,

	Thank you very much for the patch.  I have downloaded it.

	Before it gets put into PLIB proper, I will need Steve Baker's
approval.  He is the owner.  One of the guiding principles of PLIB is
that external dependencies (such as your code's dependency on "libusb")
should be minimized.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Mark
Francis Villa
Sent: Friday, June 08, 2007 10:06 PM
To: pli...@li...
Subject: [Plib-devel] code for joystick in Solaris


I created a patch for PLIB's 'js' code to add support for joysticks
in Solaris using 'libusb'.

Documentation:

http://www.dpo.uab.edu/~drmark/Solaris/README_Solaris.html


Source Download:

http://www.dpo.uab.edu/~drmark/Solaris/PLIB_Patch_Protoype_For_Solaris_2
0060808.tgz

------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel