plib-devel

Re: [Plib-devel] Number of buttons on a joystick

[Frederic B. <fre...@fr...>]

Bram Stolk wrote :
> Also, I changed jsWindows.cxx to properly set num_buttons.
> I did not build the windows version.
> If someone could please test wether it still compiles,
> and maybe even test the getNumButtons() output, that would
> be great.
>   

It compiles, runs and the num_buttons member variable seems to have the
right value.

Thanks,
-Fred

Re: [Plib-devel] Number of buttons on a joystick

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

Trammell Hudson wrote:
> I see in the plib 1.8.4 release that there is a protected data member
> named 'num_buttons' in the jsJoystick class, but nothing that exposes
> this to the user of the class.  For a joystick configuration tool I
> need to know how many buttons can be configured and can get it by
> inheriting from jsJoystick and writing my own accessor.
> 
> This works great for me under Linux, although I'd prefer not to
> depend that closely on an implementation detail.  More problematic,
> however, is that it looks like the Windows version doesn't fill in
> this member.  Is there a way to portably get the number of buttons?

Trammell,

As there is a getNumAxes(), I saw no reason why not to add
getNumButtons().

It's in CVS.

Also, I changed jsWindows.cxx to properly set num_buttons.
I did not build the windows version.
If someone could please test wether it still compiles,
and maybe even test the getNumButtons() output, that would
be great.

   Bram

> 
> Thanks,
> -- Trammell
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

[Plib-devel] Number of buttons on a joystick

[Trammell H. <hud...@sw...>]

I see in the plib 1.8.4 release that there is a protected data member
named 'num_buttons' in the jsJoystick class, but nothing that exposes
this to the user of the class.  For a joystick configuration tool I
need to know how many buttons can be configured and can get it by
inheriting from jsJoystick and writing my own accessor.

This works great for me under Linux, although I'd prefer not to
depend that closely on an implementation detail.  More problematic,
however, is that it looks like the Windows version doesn't fill in
this member.  Is there a way to portably get the number of buttons?

Thanks,
-- Trammell

[Plib-devel] build fix for msvc8 and texture loading improovement

[Mathias <Mat...@gm...>]

Hi all,

I have two patches attached here. Credits belong to Olaf Flebbe and our=20
discussions during meals ...
:)

1. The const-char-hack-removal.diff is required to build on windows using t=
he=20
current msvc8 compiler. It corrects the usage of the const qualifier and=20
obsolete some ifdef's in cases where correct usage of consts will make it=20
work without preprocessor.

2. The texture-size-limit.diff which implements an API to limit the maximum=
=20
texture size which is thrown into OpenGL.
Mipmaps are computed as usual, but if the size of a mipmap level exceeds th=
e=20
maximum texture size it is just not handed off to OpenGL.
The default behavour is unchanged until you call ssgSetTextureMaxSize with =
a=20
positive argument from your application to activate that limit.
We have also a patch for flightgear in the works which makes use of that=20
feature.

I for myself used a similar but hardcoded approach to be able to run=20
flightgear on my notebook with 32MB gpu memory. Without such a limit=20
flightgear just creeps instead of runs ...

Please apply!

    Many thanks

               Mathias

=2D-=20
Mathias Fr=F6hlich, email: Mat...@gm...

Re: [Plib-devel] UL_BSD

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

Hello Alex,

Alex Perry wrote:
> Current CVS has a bunch of dependencies on the "UL_BSD" symbol,
> mostly in source code and thus appear to be handled by "ul.h",
> but there is one reference for Automake in "src/js/Makefile.am".
> Is there an addition to the auto* scripting that hasn't committed?

It appears that this breackage is intentionally ....

You'll see a track of the changes in the "BSD analog joystick fixes"
and the recent "New release" thread. This part is known to be broken
but nobody dares to touch it and fix that - neither the contributor nor
the committer.
Simply revert Makefile.am to '-D 2006-01-02' and you'll get a working
copy.

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

[Plib-devel] UL_BSD

[Alex P. <ale...@ie...>]

Current CVS has a bunch of dependencies on the "UL_BSD" symbol,
mostly in source code and thus appear to be handled by "ul.h",
but there is one reference for Automake in "src/js/Makefile.am".
Is there an addition to the auto* scripting that hasn't committed?

Re: R: [Plib-devel] texture compression

[<tia...@sa...>]

Hello

If i understand correctly, .DDS are pre-compressed image files. I think 
coding what you are suggesting would be easy, but it would require that 
we decompress the textures ourselves in case the user doesn't have the 
extension (and the final result would have the same compression artifacts).

In FG's case, i think the best option is make it so we can override the 
default Z from FG/SimGear, thus making extension checking our problem 
and allowing the user to choose if he prefers no compression (and so no 
compression artifacts).


Cheers




Paolo Leoncini wrote:
> Sorry, just a question: what about actually loading the DDS texture image
> data?
> 
> I.e. putting a new zsize mode parameter in the glTexImage2D call suppose we
> are supplying proper pixed data, and, beside the large pixel data block, we
> should also read w, h, and the GL_COMPRESSED_RGBx_S3TC_DXTx_EXT mode off the
> file. Is there code for this too?
> 
> Greetings -
> 
> Paolo Leoncini

Re: [Plib-devel] New release

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

Jean-Yves Lefort wrote:

>> Do I or could we abandon the change to src/js/Makefile.am ?
> 
> Up to you to decide.

So I'd propose to revert the recent patch to src/js/Makefile.am as long
as there's no clean solution,

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

R: [Plib-devel] texture compression

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

Sorry, just a question: what about actually loading the DDS texture =
image
data?

I.e. putting a new zsize mode parameter in the glTexImage2D call suppose =
we
are supplying proper pixed data, and, beside the large pixel data block, =
we
should also read w, h, and the GL_COMPRESSED_RGBx_S3TC_DXTx_EXT mode off =
the
file. Is there code for this too?

Greetings -

Paolo Leoncini


> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto di=20
> Tiago Gusm=E3o
> Inviato: marted=EC 10 gennaio 2006 17.51
> A: pli...@li...
> Oggetto: [Plib-devel] texture compression
>=20
>=20
> Hello
>=20
> I was wondering if i or someone else can add texture=20
> compression support=20
> to plib, which i believe can be done without disrupting the=20
> current plib=20
> behaviour and with few files being affected.
>=20
> Below is my original post to the FlightGear devel list, with a quick=20
> hack patch.
>=20
> Currently we're still discussing this, so no further details,=20
> but if we=20
> go ahead with it, is it alright regarding plib?
>=20
>=20
> Thanks
>=20
> Cheers,
> Tiago
>=20
>=20
> **************************************************************
> *********
> **************************************************************
> *********
> Hello
>=20
> I'm having a HW problem and i can't enable AGP in linux,=20
> which makes the hunter, b1900d and the Nimitz lower FPSs=20
> dramatically, which i believe is caused by the NVRAM filling=20
> up with textures thus forcing texture transfers to the card=20
> (GF4 MX 440 64MB)
>=20
> so after Surge mentioned texture compression, i added it in=20
> plib, with amazing performance improvements in those=20
> situations, It also appears to be improving FPS in general in=20
> other situations.
>=20
> it doesn't check for the extension, **before trying**, check=20
> glxinfo for the presence of "EXT_texture_compression_s3tc"=20
> it's just an ugly hack, works for me and likely everyone else=20
> with s3tc,=20
> but it's bad code, i know,
>=20
> a brief explanation:=20
> http://www.digit-life.com/articles/reviews3tcfxt1/
> spec:=20
> http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_co
> mpression_s3tc.txt
>=20
>=20
> i have no experience with patches, but here it is, against=20
> plib 1.8.4,for those interested. added one line, made one=20
> token change:
>=20
> diff -cr plib-1.8.4/src/ssg/ssgLoadTexture.cxx
> plib-1.8.4ext/src/ssg/ssgLoadTexture.cxx
> *** plib-1.8.4/src/ssg/ssgLoadTexture.cxx    2003-06-27=20
> 08:15:15.000000000
> +0000
> --- plib-1.8.4ext/src/ssg/ssgLoadTexture.cxx    2006-01-07
> 16:44:17.000000000 +0000
> ***************
> *** 24,29 ****
> --- 24,30 ----
>=20
>    #include "ssgLocal.h"
>=20
> + #define PROXY_TEXTURES_ARE_BROKEN
>=20
>    struct _ssgTextureFormat
>    {
> ***************
> *** 161,167 ****
>        total_texels_loaded +=3D w * h ;
>=20
>        glTexImage2D  ( GL_TEXTURE_2D,
> !                      map_level, zsize, w, h, FALSE /* Border */,
>                                (zsize=3D=3D1)?GL_LUMINANCE:
>                                (zsize=3D=3D2)?GL_LUMINANCE_ALPHA:
>                                (zsize=3D=3D3)?GL_RGB:
> --- 162,168 ----
>        total_texels_loaded +=3D w * h ;
>=20
>        glTexImage2D  ( GL_TEXTURE_2D,
> !                      map_level, /*zsize*/ 0x83F3, w, h, FALSE /*
> Border */,
>                                (zsize=3D=3D1)?GL_LUMINANCE:
>                                (zsize=3D=3D2)?GL_LUMINANCE_ALPHA:
>                                (zsize=3D=3D3)?GL_RGB:
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files for problems?  Stop!  Download the new AJAX=20
> search engine that makes searching your log files as easy as=20
> surfing the  web.  DOWNLOAD SPLUNK!=20
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> plib-devel mailing list
> pli...@li...=20
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>=20

[Plib-devel] texture compression

[<tia...@sa...>]

Hello

I was wondering if i or someone else can add texture compression support 
to plib, which i believe can be done without disrupting the current plib 
behaviour and with few files being affected.

Below is my original post to the FlightGear devel list, with a quick 
hack patch.

Currently we're still discussing this, so no further details, but if we 
go ahead with it, is it alright regarding plib?


Thanks

Cheers,
Tiago


***********************************************************************
***********************************************************************
Hello

I'm having a HW problem and i can't enable AGP in linux, which makes the
hunter, b1900d and the Nimitz lower FPSs dramatically, which i believe
is caused by the NVRAM filling up with textures thus forcing texture
transfers to the card (GF4 MX 440 64MB)

so after Surge mentioned texture compression, i added it in plib, with
amazing performance improvements in those situations, It also appears to
be improving FPS in general in other situations.

it doesn't check for the extension, **before trying**, check glxinfo for
the presence of "EXT_texture_compression_s3tc"
it's just an ugly hack, works for me and likely everyone else with s3tc, 
but it's bad code, i know,

a brief explanation: http://www.digit-life.com/articles/reviews3tcfxt1/
spec:
http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt


i have no experience with patches, but here it is, against plib
1.8.4,for those interested.
added one line, made one token change:

diff -cr plib-1.8.4/src/ssg/ssgLoadTexture.cxx
plib-1.8.4ext/src/ssg/ssgLoadTexture.cxx
*** plib-1.8.4/src/ssg/ssgLoadTexture.cxx    2003-06-27 08:15:15.000000000
+0000
--- plib-1.8.4ext/src/ssg/ssgLoadTexture.cxx    2006-01-07
16:44:17.000000000 +0000
***************
*** 24,29 ****
--- 24,30 ----

   #include "ssgLocal.h"

+ #define PROXY_TEXTURES_ARE_BROKEN

   struct _ssgTextureFormat
   {
***************
*** 161,167 ****
       total_texels_loaded += w * h ;

       glTexImage2D  ( GL_TEXTURE_2D,
!                      map_level, zsize, w, h, FALSE /* Border */,
                               (zsize==1)?GL_LUMINANCE:
                               (zsize==2)?GL_LUMINANCE_ALPHA:
                               (zsize==3)?GL_RGB:
--- 162,168 ----
       total_texels_loaded += w * h ;

       glTexImage2D  ( GL_TEXTURE_2D,
!                      map_level, /*zsize*/ 0x83F3, w, h, FALSE /*
Border */,
                               (zsize==1)?GL_LUMINANCE:
                               (zsize==2)?GL_LUMINANCE_ALPHA:
                               (zsize==3)?GL_RGB:

Re: [Plib-devel] New release

[Jean-Yves L. <jyl...@Fr...>]

On Mon, 9 Jan 2006 15:10:26 +0000 (UTC)
Martin Spott <Mar...@mg...> wrote:

> Jean-Yves Lefort wrote:
>=20
> > Install devel/gnu-autoconf, devel/gnu-automake and devel/gnu-libtool,
> > then add /usr/local/gnu-autotools/bin to your PATH (preferably before
> > /usr/local/bin). It will allow you to use SimGear's and FlightGear's
> > autogen.sh without modifications (I didn't test PLIB's).
>=20
> This sounds like a nice idea but I hope I don't have to install these
> packages in order to be able to build PLIB after your recent changes !?

No, these ports have nothing to do with my changes.

> Do I or could we abandon the change to src/js/Makefile.am ?

Up to you to decide.

--=20
Jean-Yves Lefort

jyl...@Fr...
http://lefort.be.eu.org/

Re: [Plib-devel] New release

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

Hello Jean-Yves,

Jean-Yves Lefort wrote:

> Install devel/gnu-autoconf, devel/gnu-automake and devel/gnu-libtool,
> then add /usr/local/gnu-autotools/bin to your PATH (preferably before
> /usr/local/bin). It will allow you to use SimGear's and FlightGear's
> autogen.sh without modifications (I didn't test PLIB's).

This sounds like a nice idea but I hope I don't have to install these
packages in order to be able to build PLIB after your recent changes !?
Do I or could we abandon the change to src/js/Makefile.am ?

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

Re: [Plib-devel] New release

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

"Norman Vine" wrote:

> http://lists.sourceforge.net/lists/listinfo/plib-cvs

Thanks to you both, Frederic and Norman,
	Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] New release

[Jean-Yves L. <jyl...@Fr...>]

On Mon, 9 Jan 2006 13:58:07 +0000 (UTC)
Martin Spott <Mar...@mg...> wrote:

> "Norman Vine" wrote:
>=20
> > When working with the CVS files=20
> > run autogen.sh before configure
>=20
> The stock 'autogen.sh' does not work on FreeBSD. I'm typically using
> this set with FreeBSD for a very long time and I've been happy with it
> ever since, not only for PLIB but for every package that is required
> in order to build FlightGear:
>=20
> # ~> libtoolize15 --copy --force; aclocal19 -I .; autoheader259; automake=
19 -a -i; autoconf259

Install devel/gnu-autoconf, devel/gnu-automake and devel/gnu-libtool,
then add /usr/local/gnu-autotools/bin to your PATH (preferably before
/usr/local/bin). It will allow you to use SimGear's and FlightGear's
autogen.sh without modifications (I didn't test PLIB's).

--=20
Jean-Yves Lefort

jyl...@Fr...
http://lefort.be.eu.org/

RE: [Plib-devel] New release

[Norman V. <nh...@ca...>]

Martin Spott writes:
> 
> Does PLIB have a mailing list that enables me to track CVS changes ? I
> didn't find such a list

http://lists.sourceforge.net/lists/listinfo/plib-cvs

Re: [Plib-devel] New release

[Frederic B. <fre...@fr...>]

> Does PLIB have a mailing list that enables me to track CVS changes ? I
> didn't find such a list

http://sourceforge.net/mailarchive/forum.php?forum_id=3D7201

-Fred

Re: [Plib-devel] New release

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

Ni Norman !

"Norman Vine" wrote:

> When working with the CVS files 
> run autogen.sh before configure

The stock 'autogen.sh' does not work on FreeBSD. I'm typically using
this set with FreeBSD for a very long time and I've been happy with it
ever since, not only for PLIB but for every package that is required
in order to build FlightGear:

# ~> libtoolize15 --copy --force; aclocal19 -I .; autoheader259; automake19 -a -i; autoconf259

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

Re: [Plib-devel] New release

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

Martin Spott wrote:

> I'm currently investigating. Please hold the release back until this
> obvious bug is fixed,

Now here it is, 'automake19' exits with:

src/js/Makefile.am:4: UL_BSD does not appear in AM_CONDITIONAL


This error is triggered by the following change:

diff ~/CVS/FlightGear/plib/src/js/Makefile.am ./src/js/Makefile.am
--- /home/mas/CVS/FlightGear/plib/src/js/Makefile.am    Mon Jan  9 14:35:24 2006
+++ ./src/js/Makefile.am        Mon Jan  9 14:34:04 2006
@@ -1,5 +1,10 @@
 if BUILD_JS
 
+# FIXME set the UL_BSD conditional using AM_CONDITIONAL in configure.ac
+if UL_BSD
+bin_PROGRAMS = plib-jscal
+plib_jscal_SOURCES = jsBSDCal.c
+endif
 lib_LIBRARIES = libplibjs.a
 
 include_HEADERS = js.h


Does anyone need this ? If not, then I'd suggest to back it out ASAP.

Does PLIB have a mailing list that enables me to track CVS changes ? I
didn't find such a list

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

RE: [Plib-devel] New release

[Norman V. <nh...@ca...>]

Martin Spott writes:
> 
> Last week I was able to build PLIB on FreeBSD, after recent changes I
> am not. While running 'configure' I see this message:
> 
> [...]
> checking for socklen_t... yes
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: error: cannot find input file: Makefile.in
> 

When working with the CVS files 
run autogen.sh before configure

HTH

Norman

Re: [Plib-devel] New release

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

Erik Hofman wrote:

> After that, wouldn't it be time for the new release to happen, that way 
> you might not miss the next release of FlightGear.

Good idea, but not in this case  :-)
Last week I was able to build PLIB on FreeBSD, after recent changes I
am not. While running 'configure' I see this message:

[...]
checking for socklen_t... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: Makefile.in


I'm currently investigating. Please hold the release back until this
obvious bug is fixed,

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

Re: [Plib-devel] New release (Was: puAuxList.cxx)

[Jean-Yves L. <jyl...@Fr...>]

On Fri, 06 Jan 2006 13:59:06 +0100
Bram Stolk <br...@sa...> wrote:

> Erik Hofman wrote:
> >=20
> > It might be a good idea to fix this first:
> >=20
> > Running automake
> > src/js/Makefile.am:4: UL_BSD does not appear in AM_CONDITIONAL
>=20
> that Makefile.am makes no sense to me:
> it refers to jsBSDCal.c which is not in CVS.

The person who committed my patch forgot to add it.

It can be found here:
http://sourceforge.net/mailarchive/forum.php?thread_id=3D9171926&forum_id=
=3D4479

> Because it wants to build this calibration program (apparently
> BSD-only?) the Makefile.am is screwed.
>=20
> I say: remove the bin_PROGRAMS alltogether, as well as the
> test on UL_BSD which cannot be done in Makefile.am without
> a conditional.
>=20
> PLIB platform defines are in C++, not in autoconf-speak.

cpp is not appropriate in this case, since the calibration program is
useless (and does not even compile) on non-BSD.

--=20
Jean-Yves Lefort

jyl...@Fr...
http://lefort.be.eu.org/

Re: [Plib-devel] New release (Was: puAuxList.cxx)

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

Erik Hofman wrote:
> 
> It might be a good idea to fix this first:
> 
> Running automake
> src/js/Makefile.am:4: UL_BSD does not appear in AM_CONDITIONAL

that Makefile.am makes no sense to me:
it refers to jsBSDCal.c which is not in CVS.

Because it wants to build this calibration program (apparently
BSD-only?) the Makefile.am is screwed.

I say: remove the bin_PROGRAMS alltogether, as well as the
test on UL_BSD which cannot be done in Makefile.am without
a conditional.

PLIB platform defines are in C++, not in autoconf-speak.

    Bram

> 
> Erik
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] New release (Was: puAuxList.cxx)

[Erik H. <er...@eh...>]

It might be a good idea to fix this first:

Running automake
src/js/Makefile.am:4: UL_BSD does not appear in AM_CONDITIONAL

Erik

Re: [Plib-devel] New release (Was: puAuxList.cxx)

[Erik H. <er...@eh...>]

Frederic Bouvier wrote:

> Erik, to my knowledge, it *is* committed :
> http://cvs.sourceforge.net/viewcvs.py/plib/plib/src/puAux/puAuxList.cxx?rev=1.1&view=log

That's odd, I've first checked this before sending the message and it 
wasn't according to CVS. But after checking it again I got a conflicting 
file ??!?

Anyhow, it it already committed indeed.

Erik

Re: [Plib-devel] New release (Was: puAuxList.cxx)

[Frederic B. <fre...@fr...>]

Quoting Erik Hofman :

> Bram Stolk wrote:
>
> > What's the status on this?
>
> I't not yet committed.
>
> > Wasn't there an issue that someone forget to check in, and is now
> > having cvs troubles?
>
> Yep, if you would want to do this for me.
>
> After that, wouldn't it be time for the new release to happen, that way
> you might not miss the next release of FlightGear.

Erik, to my knowledge, it *is* committed :
http://cvs.sourceforge.net/viewcvs.py/plib/plib/src/puAux/puAuxList.cxx?r=
ev=3D1.1&view=3Dlog

-Fred