plib-devel

[Plib-devel] ANNOUNCING - PLIB 1.8.4

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

**ANNOUNCING PLIB-1.8.4**

It's been a while since we made a PLIB release and we've accumulated
quite a few small bug fixes and minor enhancements.

Download the new release from the usual place:

   http://plib.sourceforge.net/download.html

Have fun!

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Minor Issues with PLIB Release Candidate

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

Frederic Bouvier wrote:
> Bram Stolk a =E9crit :
>=20
>> Fay John F Contr AAC/WMG wrote:
>>
>>>     - ssgSaveIV.cxx:100,233,240,246,255,270 - dynamic-cast used on
>>> polymorphic type with "/GR-"; behavior is unpredictable
>>
>>
>>
>> I assume that "/GR-" is a flag for your win32 compiler?
>> What does this flag do?
>> Is removing this flag an option?
>>
>> If not, using isAKindOf() coupled with a static_cast<>() should
>> be a possible replacement of the dynamic cast.
>>
>> I find it strange that win32 is not able to cope with this.
>> I would guess that *all* base classes that have derived
>> classes are polymorphic. That means dynamic_cast cant be used
>> at all in your setup.
>=20
>=20
> /GR- is the default option, when you don't specify it in your MSVC=20
> project. Somebody should edit ssg.dsp to add the /GR option ( preferabl=
y=20
> in the IDE, not in vi ). This flag enable C++ RTTI and it is needed=20
> because this file use dynamic_cast<>. As rtti introduce some penalty,=20
> the flag is not on by default.

It's easier (and faster) to remove the need.

I've just committed a version of ssgSaveIV that doesn't use dynamic_cast.=


---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++=

-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Minor Issues with PLIB Release Candidate

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

Bram Stolk wrote:
> Fay John F Contr AAC/WMG wrote:
> 
>>     - ssgSaveIV.cxx:100,233,240,246,255,270 - dynamic-cast used on
>> polymorphic type with "/GR-"; behavior is unpredictable
> 
> 
> I assume that "/GR-" is a flag for your win32 compiler?
> What does this flag do?
> Is removing this flag an option?
> 
> If not, using isAKindOf() coupled with a static_cast<>() should
> be a possible replacement of the dynamic cast.
> 
> I find it strange that win32 is not able to cope with this.
> I would guess that *all* base classes that have derived
> classes are polymorphic. That means dynamic_cast cant be used
> at all in your setup.

I don't see why a dynamic cast is needed here.  I'm going to dump
it and use isAKindOf() and a static cast instead.

These relatively new C++ features are always tricky - we should
avoid them in software like PLIB where portability is a key feature.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Minor Issues with PLIB Release Candidate

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

Bram Stolk a =E9crit :

> Fay John F Contr AAC/WMG wrote:
>
>>     - ssgSaveIV.cxx:100,233,240,246,255,270 - dynamic-cast used on
>> polymorphic type with "/GR-"; behavior is unpredictable
>
>
> I assume that "/GR-" is a flag for your win32 compiler?
> What does this flag do?
> Is removing this flag an option?
>
> If not, using isAKindOf() coupled with a static_cast<>() should
> be a possible replacement of the dynamic cast.
>
> I find it strange that win32 is not able to cope with this.
> I would guess that *all* base classes that have derived
> classes are polymorphic. That means dynamic_cast cant be used
> at all in your setup.

/GR- is the default option, when you don't specify it in your MSVC=20
project. Somebody should edit ssg.dsp to add the /GR option ( preferably=20
in the IDE, not in vi ). This flag enable C++ RTTI and it is needed=20
because this file use dynamic_cast<>. As rtti introduce some penalty,=20
the flag is not on by default.

-Fred

Re: [Plib-devel] Minor Issues with PLIB Release Candidate

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

Fay John F Contr AAC/WMG wrote:

> 	- ssgSaveIV.cxx:100,233,240,246,255,270 - dynamic-cast used on
> polymorphic type with "/GR-"; behavior is unpredictable

I assume that "/GR-" is a flag for your win32 compiler?
What does this flag do?
Is removing this flag an option?

If not, using isAKindOf() coupled with a static_cast<>() should
be a possible replacement of the dynamic cast.

I find it strange that win32 is not able to cope with this.
I would guess that *all* base classes that have derived
classes are polymorphic. That means dynamic_cast cant be used
at all in your setup.

   bram

Re: [Plib-devel] Minor Issues with PLIB Release Candidate

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

Fay John F Contr AAC/WMG wrote:
> Gentlemen,
> 
>         I'm compiling the PLIB release candidate and also comparing the 
> code with my personal version.  There are some points I'd like to 
> raise.  It is too bad that I waited this long before looking at it...

It's not too late.  I promised the FGFS guys a release tomorrow *if*
nothing fatal came up.  We can probably delay a day or two to fix
these things.

If need be, we can always do another release in a week or two, remember:
Version numbers are cheap!

> (1) There are some compiler warnings under MSVC:
>         - ssgLoadAC.cxx:60 - truncation from const double to float
>         - ssgLoadMDL.cxx:390 - conversion from double to float
>         - ssgSaveIV.cxx:100,233,240,246,255,270 - dynamic-cast used on 
> polymorphic type with "/GR-"; behavior is unpredictable

I can live with those for now.

> (2) "puAux" is missing a whole lot of changes that I have made in using 
> the library.  Some "puAux" widgets refer to deprecated PUI widgets, for 
> example, and some "puaComboBox" behavior fixes that I have made haven't 
> found their way in yet.  Another change, which allows the user to 
> activate the widgets with some mouse button other than the left button, 
> also aren't there yet.

Again, those are nice things to have - but not essential to make a release.

> (3) There is some PUI functionality about when to deactivate the widget 
> that isn't in the release candidate.  The arbitrary mouse button change 
> mentioned in connection with "puAux" is also an issue here.  Finally, a 
> bug in "puPopupMenu" that puts the subwidgets into the same window as 
> their parent widgets has not been put in either.

It would be nice to fix that if we can.

>         Are these worth holding up the release?

They are worth holding the release for a day or two - but not for more
than that.  Dunno if you are able to do this over the weekend.  If so,
I'll hold up the release - if not - or if I don't hear from you - I'll
make the release tomorrow and we'll think in terms of making a second
release in a couple of weeks.

> I personally doubt it, 
> although I would push for fixing the compiler warnings.  Most users have 
> lived quite happily with the present PUI and "puAux" and that probably 
> won't change.  If you do decide to hold up the release, it will be at 
> least until Tuesday because I am about to go home and won't be back 
> until then.

OK.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] Minor Issues with PLIB Release Candidate

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

	I'm compiling the PLIB release candidate and also comparing the code
with my personal version.  There are some points I'd like to raise.  It is
too bad that I waited this long before looking at it, but I just got back.
Anyway, here's the laundry list.

(1) There are some compiler warnings under MSVC:
	- ssgLoadAC.cxx:60 - truncation from const double to float
	- ssgLoadMDL.cxx:390 - conversion from double to float
	- ssgSaveIV.cxx:100,233,240,246,255,270 - dynamic-cast used on
polymorphic type with "/GR-"; behavior is unpredictable

(2) "puAux" is missing a whole lot of changes that I have made in using the
library.  Some "puAux" widgets refer to deprecated PUI widgets, for example,
and some "puaComboBox" behavior fixes that I have made haven't found their
way in yet.  Another change, which allows the user to activate the widgets
with some mouse button other than the left button, also aren't there yet.

(3) There is some PUI functionality about when to deactivate the widget that
isn't in the release candidate.  The arbitrary mouse button change mentioned
in connection with "puAux" is also an issue here.  Finally, a bug in
"puPopupMenu" that puts the subwidgets into the same window as their parent
widgets has not been put in either.

	Are these worth holding up the release?  I personally doubt it,
although I would push for fixing the compiler warnings.  Most users have
lived quite happily with the present PUI and "puAux" and that probably won't
change.  If you do decide to hold up the release, it will be at least until
Tuesday because I am about to go home and won't be back until then.

John F. Fay
joh...@eg...
850-729-6330 

[Plib-devel] I'm back

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

	I'm back from a week in West Africa.  I didn't expect to come into
work today but did anyway so I'm a few days earlier than I had planned.  My
unread e-mail list is at 200 and counting.

	Anything happen while I was away?
	
John F Fay
joh...@eg...
850-729-6330 

Re: [Plib-devel] Making a PLIB release.

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

Steve Baker wrote:

> For those without CVS access, you can download the 1.8.4 release
> candidate from:
> 
>     http://plib.sourceforge.net/dist/plib-1.8.4_RC.tar.gz

The patch against src/sl/slPortability.h is still missing:

--- ./src/sl/slPortability.h.orig	Sat Sep  7 17:54:59 2002
+++ ./src/sl/slPortability.h	Sat Sep  7 17:55:22 2002
@@ -74,7 +74,7 @@
 #  if defined(__linux__)
 #    include <linux/soundcard.h>
 #  elif defined(__FreeBSD__)
-#    include <machine/soundcard.h>
+#    include <sys/soundcard.h>
 #  else
     /*
       Tom thinks this file may be <sys/soundcard.h> under some


Without this one the build actually still breaks on current FreeBSD
RELEASE - in contrast to the respective clause in the ChangeLog !!
Bert promised to apply _two_ patches but in fact he only applied one.

I really don't understand why this is soooo difficult:
A patch is present, it has been mentioned several times, it is
_obvious_ that the patch is necessary in order to build PLIB on recent
FreeBSD RELEASEs, someone promised to apply the patch, the ChangeLog
has already been updated accordingly - but the patch did never get in.

So please apply this patch or don't pretend that the package builds
cleanly on FreeBSD.

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

Re: [Plib-devel] Making a PLIB release.

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

br...@sa... wrote:

> What list exactly? There is a cvs mail archive at:
> http://sourceforge.net/mailarchive/forum.php?forum_id=7201

Ah, thanks, I didn't notice that one,

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

Re: [Plib-devel] Making a PLIB release.

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

I also spun a release candidate for the PLIB examples:

    http://plib.sourceforge.net/dist/plib_examples-1.8.4_RC.tar.gz


---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Making a PLIB release.

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

For those without CVS access, you can download the 1.8.4 release
candidate from:

    http://plib.sourceforge.net/dist/plib-1.8.4_RC.tar.gz


---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Making a PLIB release.

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

Could everyone who has added significant features or fixed bugs since
PLIB 1.8.3 (April 2004) please update the CVS version of the 'ChangeLog'
file (and also make sure they are mentioned in 'AUTHORS').

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Making a PLIB release.

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

Martin Spott wrote:

> It would be nice to give users a few days util the changes have shown
> up in anonymous CVS and give them a chance to test against their
> favourite application,

I'll put out a release candidate tarball later tonight.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Making a PLIB release.

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

Bram Stolk wrote:

> If you have time: try a build with mipspro on irix.
> For me, this doesnt work (many errors of all sorts, mainly
> in net code).

Try this one after running 'configure':

#!/bin/bash
for i in `find . -type f -name Makefile`; do
  echo -e ",s/-Dsocklen_t=int//g\nwq" | ed $i
done


Works fine with MIPSpro-7.4.1,

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

Re: [Plib-devel] Making a PLIB release.

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

> Unfortunately there is no plib-cvslogs mailing list to track such
> changes,

What list exactly? There is a cvs mail archive at:
http://sourceforge.net/mailarchive/forum.php?forum_id=7201

But surely, cvs itself can give you any information on past
activity whatsoever.

Re: [Plib-devel] Making a PLIB release.

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

Bert Driehuis wrote:

> I just applied the two patches from the FreeBSD ports tree that are 
> required to unbreak the build on FreeBSD 5.3.

Not yet - at least still not in the anonymous CVS area. The patch
against ./src/sl/slPortability.h is missing and required for
FreeBSD-5.3 - and according to the CVS browser the file has been
unchanged for 19 months.
Unfortunately there is no plib-cvslogs mailing list to track such
changes,

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

Re: [Plib-devel] Making a PLIB release.

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

Steve Baker wrote:
> I think it's time we made another PLIB release.
> 
> There have been quite a few bug fixes and minor enhancements
> since last time.
> 
> Unless anyone has any burning issues, I'll cut a release from
> the current CVS tomorrow evening (that's Wednesday 11th Jan).

If you have time: try a build with mipspro on irix.
For me, this doesnt work (many errors of all sorts, mainly
in net code).

But I doubt the quality of my mipspro installation, so
if someone else could do an irix test...

I used:
bram@vger:~$ CC -v
MIPSpro Compilers: Version 7.41
On an Onyx4.

   bram

Re: [Plib-devel] Making a PLIB release.

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

Bert Driehuis wrote:

> Anyway, when all is said and done, I think we're golden. I'm pretty 
> convinced that I didn't break anything, but I'll be watching my mailbox 
> like a hawk during the release period.

It would be nice to give users a few days util the changes have shown
up in anonymous CVS and give them a chance to test against their
favourite application,

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

Re: [Plib-devel] Making a PLIB release.

[Bert D. <dri...@pl...>]

On Tue, 11 Jan 2005, Steve Baker wrote:

> I think it's time we made another PLIB release.
>
> There have been quite a few bug fixes and minor enhancements
> since last time.
>
> Unless anyone has any burning issues, I'll cut a release from
> the current CVS tomorrow evening (that's Wednesday 11th Jan).

I just applied the two patches from the FreeBSD ports tree that are 
required to unbreak the build on FreeBSD 5.3. The patch to jsBSD.cxx is 
ugly and I'd have rewritten it if I had the couple of hours required to 
do it in autoconf and verify the change at least won't break Linux. But 
the patch works and it does unbreak the build, and it's isolated so it 
won't break other platforms. I've made a mental note to clean it up when 
I'm bored.

I did not apply the patch to src/ssg/ssgDList.cxx; it adds a large chunk 
of code to implement an _ssgMatrixStack class and I've got no clue what 
it's for -- any takers?

As Martin observed, the patch for netSocket.cxx was already in plib for 
quite a while.

Counter to popular belief, FreeBSD 5.3 does not fix the pthread issue. 
I've narrowed it down a bit. I've installed a plain-jane build of cvs 
plib with --prefix=/usr/local/cvs-plib . When I build ttt3d with

   #!/bin/sh
   prefix=/usr/local/cvs-plib
   env LDFLAGS="-L$prefix/lib" \
       CPPFLAGS="-I$prefix/include" \
 	./configure --prefix=$prefix --with-GL=/usr/X11R6
   gmake

the resulting binary dies with
   FATAL: ssgInit called without a valid OpenGL context.

When I configure ttt3d with
   #!/bin/sh
   prefix=/usr/local/cvs-plib
   env LDFLAGS="-pthread -L$prefix/lib" \
       CPPFLAGS="-pthread -I$prefix/include" \
 	./configure --prefix=$prefix --with-GL=/usr/X11R6
   gmake

it runs just fine.

The good news is that (a) the FreeBSD port's patch to take out the check 
is not needed, (b) we probably have an answer to people who claim it is, 
and (c) that a default build of plib works fine if the app is linked 
properly (I can only surmise that it's the linking with -lc_r that is 
implicit in compiling with -pthread that "fixes" it; I've still got no 
clue what actually _causes_ the problem).

Anyway, when all is said and done, I think we're golden. I'm pretty 
convinced that I didn't break anything, but I'll be watching my mailbox 
like a hawk during the release period.

Cheers,

 				-- Bert

-- 
Bert Driehuis -- dri...@pl... -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!

[Plib-devel] Making a PLIB release.

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

I think it's time we made another PLIB release.

There have been quite a few bug fixes and minor enhancements
since last time.

Unless anyone has any burning issues, I'll cut a release from
the current CVS tomorrow evening (that's Wednesday 11th Jan).

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: R: [Plib-devel] commandline conversion program

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

Bram Stolk wrote:

> Although it does add a dependency on glut, which can be
> avoided with the pbuffer code.

Well, you can do whatever GLUT does.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] commandline conversion program

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

br...@sa... wrote:
>>You need to understand how non-visible OpenGL rendering contexts
>>work.
> 
> 
> Ok, pbuffers it will be....

I've added the tool, pbuffer-based, in cvs plib/tools/src/ dir.
It compiles for all glx platforms. It runs on modern glx platforms.

    Bram

Re: R: [Plib-devel] commandline conversion program

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

Paolo Leoncini wrote:

> As an example just look at the loadmaker utility source code that I
> copied below:

Paolo,

Thanks for the sample code.
I might use this.

Although it does add a dependency on glut, which can be
avoided with the pbuffer code.
I found out what was causing the glXGetFBConfigs() failure:
I needed to install the nvidia specific glx-dev environment.
I had nvidia's GL and glx on my machine, but a non-nvidia
glx-dev package. In Debian, nvidia-glx-dev is in non-free.

Bram

R: [Plib-devel] commandline conversion program

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

> -----Messaggio originale-----
> Da: pli...@li... 
> [mailto:pli...@li...] Per conto di 
> br...@sa...
> Inviato: domenica 9 gennaio 2005 20.20
> A: pli...@li...
> Oggetto: Re: [Plib-devel] commandline conversion program
> 
> 
> 
> > You need to understand how non-visible OpenGL rendering 
> contexts work.
> 
> Ok, pbuffers it will be....

No need to go to pbuffers for a windowless Ogl context.
In GLUT one can glutCreateWindow(), so having the Ogl context, yet the
window will not been show until the first redraw, that one coudn't ever
do.
As an example just look at the loadmaker utility source code that I
copied below:

/*
LODMaker - a simple command-line utility that takes in a set of 3d model

files as arguments (with accompanying distances).  It outputs a .ssg
file 
containing a tree with a ssgRangeSelector and the model ssgEntities.

"Why would such a util be useful?" you ask.  It's useful because it
allows 
PLIB users to add level-of-detail models to their scenes *without any
changes 
to their code*.  

Instead of loading an ordinary model file, the author just uses the .ssg

file.  Bam, instant lod-enabled scene. 

Author:   Andrew Sampson (ads4260 AT rit.edu, dinosaur AT epix.net)
Web site: http://citybuilder.sf.net , http://kludge3d.sf.net

Date:     July, 2003

This program is released under the GNU GPL.  For more details on what
this 
implies, see http://www.gnu.org

*/


#include <GL/glut.h>
#include <stdio.h>
#include <stdlib.h>
#include <plib/ssg.h>

#define LOD_DIST_MIN 0.0
#define LOD_DIST_MAX 10000.0
#define LOD_DIST_INFINITY 1000000.0

#define MAX_LODS 6


void usage( int argc, char **argv ) {
	printf( "Usage: %s outputfile modelname distance [modelname
distance] ...\n", argv[0] );
	printf( "\twhere modelname is the name of a model to load, and
\n" );
	printf( "\tdistance is the distance beyond which the model
should not be shown\n" );
	printf( "\tThe resulting SSG file will be stored in
outputfile.\n" );
	printf( "\tUp to %i model-distance pairs may be listed.\n",
MAX_LODS );
	printf( "\tModel files will be searched for in ./models, and \n"
			"\ttexture files will be searched for in
./images\n" );
	
}


void initWindow ( int w, int h )
{
  int fake_argc = 1 ;
  char *fake_argv[3] ;

  fake_argv[0] = "lodmaker";
  fake_argv[1] = "LODmaker - ignore this window";
  fake_argv[2] = NULL ;

  glutInitWindowPosition ( 0, 0 ) ;
  glutInitWindowSize     ( w, h ) ;
  glutInit               ( &fake_argc, fake_argv ) ;
  glutInitDisplayMode    ( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH ) ;
  glutCreateWindow       ( fake_argv[1] ) ;
}


int main( int argc, char **argv ) {
	
	ssgEntity *models[MAX_LODS];
	int numLods = 0;
	int i;
	float lodDist;
	float lodDists[MAX_LODS+1];
	ssgLoaderOptions *loader_opts = new ssgLoaderOptions();
	
	if( argc < 4 || argc > (MAX_LODS*2) + 2 ) {
		usage( argc, argv );
		exit( 0 );
	}
	
	initWindow ( 64, 64 );
	ssgInit();
	ssgModelPath   ( "models" ) ;
	ssgTexturePath ( "images" ) ;
	
	lodDists[0] = 0.0;

	/* load files */
	for( i = 2; i < argc; i+=2 ) {
		models[numLods] = ssgLoad( argv[i], NULL );
		
		if( models[numLods] == NULL ) {
			printf( "Bad file; barfed on file %s\n", argv[i]
);
			exit( 1 );
		}

		lodDist = atof(argv[i+1]);	//strtof( argv[i+1],
NULL );
		if( !(lodDist > LOD_DIST_MIN && lodDist < LOD_DIST_MAX )
) {
			printf( "lod dist must be between %f and %f\n",
					LOD_DIST_MIN, LOD_DIST_MAX );
			exit( 1 );
		}
		lodDists[numLods+1] = lodDist;

		numLods++;
	}
	
	if( numLods > MAX_LODS ) {
		printf( "whup... that shouldn't happen\n" );
		exit( 1 );
	}
	
	/* set up scene graph and range selector */
	ssgRoot *root = new ssgRoot();
	ssgRangeSelector *rangeSel = new ssgRangeSelector();
	
	root->addKid( rangeSel );
	
	for( i = 0; i < numLods; i++ ) {
		rangeSel->addKid( models[i] );
	}
	
	// since numLods+1 is specified, nothing beyond the last range
will be drawn
	rangeSel->setRanges( lodDists, numLods+1 );
	
	if( ssgSaveSSG( argv[1], root ) ) {
		printf( "combined model successfully written to file
'%s'\n", argv[1] );
	} else {
		printf( "failed to write combined model to file '%s'\n",
argv[1] );
	}
	
	ssgDelete( root );

	return 0;
}

Greetings -

Paolo