plib-users

Re: [Plib-users] patch for building on OSX

[Reed H. <re...@ze...>]

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


I was also thinking, perhaps to make it easier on applications, to 
define some macros to do the
conditional includes (or to include little files that do the conditional 
includes, actually, since I
don't think it's possible to put the multi-line pp instructions in a 
define...)-- one for GL, one for
GLUT, and one for "OS" stuff (windows.h, unistd.h).

What do you think?

- --

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjxB6HkACgkQ43zrjhPEi7/1CACfQZPAZdclaQM3sm9FG9cOVMWJ
IrUAoIwr443mgqLANvw+5dF6tyifp+73
=wS3U
-----END PGP SIGNATURE-----

Re: [Plib-users] problem... glut fonts maybe?

[Sebastian U. <ud...@ha...>]

On Sun, 13 Jan 2002, _l...@li... (Lo'oRiS il Kabukimono) wrote:
> Date: Sun, 13 Jan 2002 17:44:38 +0100
> To: ud...@ha...
> From: _l...@li... (Lo'oRiS il Kabukimono)
> CC: plib <pli...@li...>
> Subject: Re: [Plib-users] problem... glut fonts maybe?

[...]

> but i have RH, not MDK, so maybe they are not the correct packages...

But why did you install MDK packages on RH anyway ?

You should have searched better instead of messing up your system with
wrong packages ...

The Red Hat "Mesa" package does contain the GLUT library !


- Sebastian

Re: [Plib-users] problem... glut fonts maybe?

[Sebastian U. <ud...@ha...>]

On Sun, 13 Jan 2002, _l...@li... (Lo'oRiS il Kabukimono) wrote:
> Date: Sun, 13 Jan 2002 17:44:38 +0100
> To: ud...@ha...
> From: _l...@li... (Lo'oRiS il Kabukimono)
> CC: plib <pli...@li...>
> Subject: Re: [Plib-users] problem... glut fonts maybe?
> 
> > I guess the GLUT library is missing on your system.
> 
> [looris@lano]$ rpm -qa|igrep glut
> libMesaglut3-4.0-2mdk
> libMesaglut3-devel-4.0-2mdk

It might be helpful if you could redirect all warning messages to a file
and upload it somewhere (I guess it will be *way* too big to be sent to
this list).

The library might reside in /usr/X11R6/lib which is considered to be wrong.
In this case, make some symlinks or do, although this is inellegant:

CC='gcc -I/usr/X11R6/include -L/usr/X11R6/lib' CXX='g++
-I/usr/X11R6/include -L/usr/X11R6/lib' ./configure

An other option could be that the library is broken in some way (for
example, accidently stripped).

However, please do not make things worser by installing GLUT from a source
tarball on a RPM-based system ! Usually, people end up with two GLUT
installations where one is not known to the package manager.

Afterwards, applications might compile since at least *one* GLUT library is
at the right place, however, it's the worsest way to solve the problem.


- Sebastian

Re: [Plib-users] problem... glut fonts maybe?

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

Lo'oRiS il Kabukimono wrote:
> 
> > I guess the GLUT library is missing on your system.
> 
> [looris@lano]$ rpm -qa|igrep glut
> libMesaglut3-4.0-2mdk
> libMesaglut3-devel-4.0-2mdk
> 
> but i have RH, not MDK, so maybe they are not the correct packages...

I'm betting that RH have put them into the /usr/X11 hierarchy instead
of /usr/include/GL and /usr/lib as the spec says.  If so, make some
symlinks from the 'right' place to wherever RH dumped them.

> please tell me where to download them, i've searched but i don't
> think i've found the correct sites...

www.opengl.org  or  www.mesa3d.org

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] problem... glut fonts maybe?

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

Lo'oRiS il Kabukimono wrote:
> 
> i have a problem trying to compile games that require plib: both tuxkart and "a quest for herring" fails at compile time with lot of errors like this:
> 
> /Flattone/LP/download/installnow/plib-1.4.2/src/pui/puFont.cxx:135: undefined reference to `glutBitmapHelvetica18'

It looks like you don't have GLUT installed (or perhaps it's installed in the
wrong place).

You should have /usr/include/GL/glut.h  and /usr/lib/libglut.a or .so

Those *might* have been erroneously placed into /usr/local or /usr/X11 by
some dumb distro builder - or you might simply not have them installed.

You can get GLUT from www.opengl.org - or use the copy that's distributed
with Mesa (www.mesa3d.org)

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] problem... glut fonts maybe?

[Lo'oRiS il K. <_l...@li...>]

> I guess the GLUT library is missing on your system.

[looris@lano]$ rpm -qa|igrep glut
libMesaglut3-4.0-2mdk
libMesaglut3-devel-4.0-2mdk

but i have RH, not MDK, so maybe they are not the correct packages...

please tell me where to download them, i've searched but i don't think i'=
ve found the correct sites...

--=20

"Life? What life? Life is for wussies, computers are for real men."
                                        Andy

_.-:/=B0^^=B0\:-._.-:/=B0^^=B0\:-._          __.         ____
 - Lo'oRiS il Kabukimono -          / /|       /^___ \
Real Name: Lorenzo Petrone         / / /      / /L_/ /
e-mail: _l...@li...          / / /      /  ___-=B0/
irc.azzurra.org #lano            / /_/__    /  /|__-=B0
digilander.iol.it/lano666       /______/|  /__/ /
^=B0\:-.__.-:/=B0^=B0\:-.__.-:/=B0^     |______|/  |__L/

Re: [Plib-users] ssgAux

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

Reed Hedges wrote:

> >> What is the status of ssgAux?
> >
> > Status?  How do you mean?
> 
> I was just confused a bit by the documentation, not sure whether it was
> still in progress...  I'll look at pretty poly...

Ah - yes - there is currently *zero* documentation for ssgAux.  That's
*not* a good thing!  I don't think looking at PrettyPoly will help you
very much...but who knows?

> >   * I'm currently adding a Particle System to it.  I don't think
> >     it'll ever be considered "finished".
> 
> hehe, sounds like a fun thing though. is it available in cvs?

Yes.  (I mean't that ssgAux will ever be considered 'finished'.  The
particle system stuff should be done in a few days).

I'll try to find time to document ssgAux after I've finished with the
ssgaParticleSystem hacking.
 
----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] problem... glut fonts maybe?

[Sebastian U. <ud...@ha...>]

On Sun, 13 Jan 2002, _l...@li... (Lo'oRiS il Kabukimono) wrote:
> Date: Sun, 13 Jan 2002 16:58:23 +0100
> To: pli...@li...
> From: _l...@li... (Lo'oRiS il Kabukimono)
> Subject: [Plib-users] problem... glut fonts maybe?
> 
> i have a problem trying to compile games that require plib: both tuxkart 
> and "a quest for herring" fails at compile time with lot of errors like t
> his:
> 
> /Flattone/LP/download/installnow/plib-1.4.2/src/pui/puFont.cxx:135: undef
> ined reference to `glutBitmapHelvetica18'
> 
> sorry but i have no idea of what is wrong, and i didn't find any FAQ, so 
> i ask for your help...

I guess the GLUT library is missing on your system.


- Sebastian

Re: [Plib-users] ssgAux

[Reed H. <re...@ze...>]

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


On Sunday, January 13, 2002, at 10:36 AM, Steve Baker wrote:

> Reed Hedges wrote:
>
>> What is the status of ssgAux?
>
> Status?  How do you mean?

I was just confused a bit by the documentation, not sure whether it was 
still
in progress...  I'll look at pretty poly...


>   * I'm currently adding a Particle System to it.  I don't think
>     it'll ever be considered "finished".

hehe, sounds like a fun thing though. is it available in cvs?

reed

- --

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjxBs9sACgkQ43zrjhPEi789ZQCfbujS7+aNvoiKZxZksPrHK2Jl
wNgAnAl27bUT9wzGMwFaFSGHxS+1/X1r
=Z1zU
-----END PGP SIGNATURE-----

Re: [Plib-users] patch for building on OSX

[Reed H. <re...@ze...>]

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


On Sunday, January 13, 2002, at 09:27 AM, Sebastian Ude wrote:

> The glIsValidContext () issue. Since AGL seems to be broken on MacOS X,
> your solution was always to return "true".
>
> However, can't we simply do glXGetCurrentContext () ? Does MacOS X 
> provide
> "glx.h" ?

No GLX.  There is an Objective-C interface to Open GL which works (I 
assume) which
has a getCurrentContext method.

The MacOSX compiler does allow you to embed Obj-C code in C++, but   I 
haven't got that
working yet,  maybe sometime soon.

> The "int" vs. "GLint" issue. It's still somewhat illogical to me why you
> had to change types only at a few places.

Macs are quite illogical sometimes!


reed

- --

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjxBszMACgkQ43zrjhPEi79/kACggqcu/hSGrF0cMcSMznRQmWTY
YhUAoLZzFFdCuJDLP604aV6028CWZ/UO
=BhHK
-----END PGP SIGNATURE-----

[Plib-users] problem... glut fonts maybe?

[Lo'oRiS il K. <_l...@li...>]

i have a problem trying to compile games that require plib: both tuxkart =
and "a quest for herring" fails at compile time with lot of errors like t=
his:

/Flattone/LP/download/installnow/plib-1.4.2/src/pui/puFont.cxx:135: undef=
ined reference to `glutBitmapHelvetica18'

sorry but i have no idea of what is wrong, and i didn't find any FAQ, so =
i ask for your help...

--=20

"When the world is in darkness, four warriors will come..."
                                        Final Fantasy I

_.-:/=B0^^=B0\:-._.-:/=B0^^=B0\:-._          __.         ____
 - Lo'oRiS il Kabukimono -          / /|       /^___ \
Real Name: Lorenzo Petrone         / / /      / /L_/ /
e-mail: _l...@li...          / / /      /  ___-=B0/
irc.azzurra.org #lano            / /_/__    /  /|__-=B0
digilander.iol.it/lano666       /______/|  /__/ /
^=B0\:-.__.-:/=B0^=B0\:-.__.-:/=B0^     |______|/  |__L/

Re: [Plib-users] ssgAux

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

Reed Hedges wrote:

> What is the status of ssgAux?

Status?  How do you mean?

  * It compiles.

  * It has no known bugs.

  * It is required by a number of packages (eg PrettyPoly)
    so it's definitely here to stay.

  * I'm currently adding a Particle System to it.  I don't think
    it'll ever be considered "finished".

  * It is intended to contain things that could be considered
    'optional' and which could be written in terms of existing
    SSG calls if the application programmer doesn't want to use
    ssgAux calls.  Consider it analogous to the GLU library for
    OpenGL.

What exactly do you need to know?

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] patch for building on OSX

[Sebastian U. <ud...@ha...>]

On Sat, 12 Jan 2002, re...@ze... (Reed Hedges) wrote:
> Date: Sat, 12 Jan 2002 23:50:19 -0500
> To: pli...@li...
> From: re...@ze... (Reed Hedges)
> Subject: Re: [Plib-users] patch for building on OSX

[...]
 
> This patch is now posted at:
> 
> 	http://zerohour.net/~reed/sw/plib

Many thanks for your efforts.

I had a look over the patch and I think it's okay. I suggest that we commit
it to CVS if Steve has no objections. However, there are a few things we
have to discuss about before we can do that:


1.)

The glIsValidContext () issue. Since AGL seems to be broken on MacOS X,
your solution was always to return "true".

However, can't we simply do glXGetCurrentContext () ? Does MacOS X provide
"glx.h" ?


2.)

The "int" vs. "GLint" issue. It's still somewhat illogical to me why you
had to change types only at a few places.


- Sebastian

[Plib-users] ssgAux

[Reed H. <re...@ze...>]

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


What is the status of ssgAux?


- --

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjxBEkwACgkQ43zrjhPEi7/mfgCdEooqBOQG2kIntcQ+iB1HJCIL
TfUAn1ujSVRrkDGRRMZe7qI96vBFzEhd
=MY4I
-----END PGP SIGNATURE-----

Re: [Plib-users] patch for building on OSX

[Reed H. <re...@ze...>]

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


This patch is now posted at:

	http://zerohour.net/~reed/sw/plib


On Monday, December 31, 2001, at 01:45 PM, Reed Hedges wrote:

>
> Attached is a patch for building on OSX, against a CVS checkout from 
> yesterday... I hope it still works. Let me know
> if it doesn't & i'll remake it for a new co.  (it can be applied from 
> the root plib CVS directory with -p1)
>
> I did not work on js, sl or net at all [maybe put a note about that in 
> README.mac?], but AFAIK all of sg, ul,
> ssg and ssgAux work, and most of fnt and pui -- there is one segfault 
> in FilePicker that I need to track down.
>

- --

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjxBEhEACgkQ43zrjhPEi784EwCeLrjMXn4fel7vcEK9S4LmIGx8
uHIAoLgeHU2b2HFhPT16zzQi6vevd+K0
=9bT3
-----END PGP SIGNATURE-----

Re: [Plib-users] invalid OpenGL context problem

[Stephen J B. <sj...@li...>]

On Tue, 8 Jan 2002, Roy Wood wrote:

> My only concern (not necessarily knowing what I'm talking about, of
> course) is that just sleeping might not be enough-- that we might have to
> call some OpenGL/glut routines to actually get things going.

Yes - but that's what we have to avoid doing.

The problem that this function is designed to avoid is the *extremely*
common one where some application programmer accidentally calls either
an SSG or an OpenGL call *before* they set up the rendering context.

When they do that, you get mysterious problems that only show up on
some OpenGL implementations and under some OS's.

The idea here was to call this function in ssgInit() and in a couple
of other 'likely' places to check that there is a valid OpenGL rendering
context before we start making OpenGL calls.  That way, you get a
high quality error message on *all* machines - not just the ones that
(justifiably) fail for such broken applications.

However, if our function itself makes OpenGL calls before ascertaining
that there is a valid rendering context then it will be likely to
crash instead of producing the error message - which defeats the
entire purpose of it's existance!

> Also, I believe that the user code usually registers all the glut
> callbacks before calling puInit(), so is it possible that our callbacks
> might get called before PLIB has actually been initialized?

That's exactly the kind of thing we are trying to prevent.

> If so, then
> when the callbacks call PLIB code, we're hosed.  Then again, all this
> occurs before we enter into glutMainLoop(), so that's likely not a
> concern, is it?

In a well-written application - no.

The most common problem is C++ programmers who have OpenGL calls in
constructor functions.  You might imagine a class object representing
a monster in a game who's constructor function loads the SSG model
for the monster - and in the process creates an ssgTexture - which
in turn calls glTexImage2D or something.   Now, with that class
wrapped up neatly and forgotten about, the programmer innocently
writes:

 static Monster the_monster_under_the_bed ;

...and wonders why his program crashes (typically deep inside
OpenGL where it's impossible to diagnose) - but only on certain
graphics cards and under certain OS's.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://www.sjbaker.org

Re: [Plib-users] invalid OpenGL context problem

[Roy W. <ro...@ce...>]

>Well, if your earlier diagnosis is right (I believe you said that
>glXGetCurrentContext() was returning NULL because the X server
>had not yet actually created the window into which the context
>would be rendered)...then waiting for a second or two might well
>be enough to kludge around the race condition.
>
>I was thinking of something like:
>
>  for ( int i = 0 ; i < MAX_REDHAT_KLUDGE_DELAY ; i++ )
>  {
>    if ( glXGetCurrentContext() != NULL )
>      return TRUE ;
>    else
>    {
>      fprintf ( stderr, "Crappy RedHat 
>distro...mumble,grumble,complain...\n");
>      sleep ( 1 ) ;
>    }
>  }


Okay then, I'll give it a try tonight.

My only concern (not necessarily knowing what I'm talking about, of 
course) is that just sleeping might not be enough-- that we might have to 
call some OpenGL/glut routines to actually get things going.


Also, I believe that the user code usually registers all the glut 
callbacks before calling puInit(), so is it possible that our callbacks 
might get called before PLIB has actually been initialized?  If so, then 
when the callbacks call PLIB code, we're hosed.  Then again, all this 
occurs before we enter into glutMainLoop(), so that's likely not a 
concern, is it?


-Roy

Re: [Plib-users] invalid OpenGL context problem

[Stephen J B. <sj...@li...>]

Roy Wood said:

> Be a bit more specific about what you mean by waiting though-- do you
> mean that within glIsValidContext(), if glXGetCurrentContext() returns
> NULL, we should literally sleep() for a second or two?  Or were you
> thinking of something subtler?

Well, if your earlier diagnosis is right (I believe you said that
glXGetCurrentContext() was returning NULL because the X server
had not yet actually created the window into which the context
would be rendered)...then waiting for a second or two might well
be enough to kludge around the race condition.

I was thinking of something like:

  for ( int i = 0 ; i < MAX_REDHAT_KLUDGE_DELAY ; i++ )
  {
    if ( glXGetCurrentContext() != NULL )
      return TRUE ;
    else
    {
      fprintf ( stderr, "Crappy RedHat distro...mumble,grumble,complain...\n");
      sleep ( 1 ) ;
    }
  }

  ...print error messages, etc...
  return FALSE ;

...with MAX_REDHAT_KLUDGE_DELAY set to something like 5 - or whatever
it takes to reliably fix the problem.

This won't cause any harm to existing programs and if it works around
the RedHat problem benignly, that's "A Good Thing".

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://www.sjbaker.org

Re: [Plib-users] invalid OpenGL context problem

[Roy W. <ro...@ce...>]

>So I wonder if we could work around the problem in PLIB by detecting
>a failure of glXGetCurrentContext, printing a warning message - then
>waiting a couple of seconds and trying again?
>
>Can someone who has this problem try that fix?

I got an updated version of Mesa from someone on the PLIB list that fixes 
the problem, but I'd be happy to revert to the old Mesa and try to patch 
PLIB.

Be a bit more specific about what you mean by waiting though-- do you 
mean that within glIsValidContext(), if glXGetCurrentContext() returns 
NULL, we should literally sleep() for a second or two?  Or were you 
thinking of something subtler?


-Roy

Re: [Plib-users] invalid OpenGL context problem

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

Roy Wood wrote:

> After some investigation, I've determined that the glut calls to set up
> the window are all completing correctly, but it seems as if there is a
> delay in the window creation such that puInit() is called before the
> window actually appears.  I tried delaying the call to puInit() and can
> actually see the window pop, but other calls to PLIB functions cause
> things to eventually crap out (I may be able to tweak it into working
> correctly, but it was getting late and I was tired).

So I wonder if we could work around the problem in PLIB by detecting
a failure of glXGetCurrentContext, printing a warning message - then
waiting a couple of seconds and trying again?

Can someone who has this problem try that fix?
 
> So, any of you folks ever run into anything like this before?  Any
> suggestions?

The problem has been noted in RedHat and Mandrake systems (and there
is something similar in Mac OSX - but I'm not sure it's the same cause).

You are the first person to nail down these interesting details that might
point the way to a work-around.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] invalid OpenGL context problem

[Roy W. <ro...@ce...>]

Ah-- got it.  Thanks.

-Roy



>Red Hat has a fix for this but it has not been officially released yet.
>
>I do not recall the exact link, I sent an email to redhat regarding this
>problem and they gave me updated Mesa packages.
>
>It seems the problem appeared during their attempt to make Mesa have
>hardware acceleration for X 3.3.6 and X 4.1 at the same time.
>
>Anyway, since I don't have the original link, I'll point you to the one
>they provided me:
>
>http://www.slothmud.org/~hayward/mesafix
>--
>Brian
>
>On Mon, 7 Jan 2002, Roy Wood wrote:
>
>>This is an odd problem that I'm hoping that someone can shed some light
>>on....
>>
>>I'm having trouble with PLIB on my machine (RedHat 7.2, exact specs
>>below, if that matters; and yes, all the underlying X/OpenGL stuff is
>>fine-- I checked).  The specific symptoms are that calls to functions
>>like puInit() are failing with a warning of "puInit() called with an
>>invalid OpenGL context."  This occurs even for simple examples in the
>>PLIB demo tarball.
>>
>>After some investigation, I've determined that the glut calls to set up
>>the window are all completing correctly, but it seems as if there is a
>>delay in the window creation such that puInit() is called before the
>>window actually appears.  I tried delaying the call to puInit() and can
>>actually see the window pop, but other calls to PLIB functions cause
>>things to eventually crap out (I may be able to tweak it into working
>>correctly, but it was getting late and I was tired).
>>
>>So, any of you folks ever run into anything like this before?  Any
>>suggestions?
>>
>>
>>-Roy
>>
>>
>>
>>p.s.  As promised, the system specs are RedHat 7.2, XFree86 4.1, Mesa
>>3.4.7, glut version that ships with Mesa 3.4.7 (sorry-- can't get at my
>>system right now to determine the glut version), all on an AMD K6-II 500
>>MHz box, FIC 503A motherboard (VIA chipset), Matrox G450 videocard.  I
>>have tested out glut and yes, it works just fine (the gears demo runs at
>>about 500 frames/sec), as does XFree86 and OpenGL in general.
>>
>>
>>_______________________________________________
>>plib-users mailing list
>>pli...@li...
>>https://lists.sourceforge.net/lists/listinfo/plib-users
>>
>
>-- 
>Brian Hayward
>
>
>_______________________________________________
>plib-users mailing list
>pli...@li...
>https://lists.sourceforge.net/lists/listinfo/plib-users

Re: [Plib-users] invalid OpenGL context problem

[<ha...@sl...>]

Red Hat has a fix for this but it has not been officially released yet.

I do not recall the exact link, I sent an email to redhat regarding this
problem and they gave me updated Mesa packages.

It seems the problem appeared during their attempt to make Mesa have
hardware acceleration for X 3.3.6 and X 4.1 at the same time.

Anyway, since I don't have the original link, I'll point you to the one
they provided me:

http://www.slothmud.org/~hayward/mesafix
--
Brian

On Mon, 7 Jan 2002, Roy Wood wrote:

>This is an odd problem that I'm hoping that someone can shed some light
>on....
>
>I'm having trouble with PLIB on my machine (RedHat 7.2, exact specs
>below, if that matters; and yes, all the underlying X/OpenGL stuff is
>fine-- I checked).  The specific symptoms are that calls to functions
>like puInit() are failing with a warning of "puInit() called with an
>invalid OpenGL context."  This occurs even for simple examples in the
>PLIB demo tarball.
>
>After some investigation, I've determined that the glut calls to set up
>the window are all completing correctly, but it seems as if there is a
>delay in the window creation such that puInit() is called before the
>window actually appears.  I tried delaying the call to puInit() and can
>actually see the window pop, but other calls to PLIB functions cause
>things to eventually crap out (I may be able to tweak it into working
>correctly, but it was getting late and I was tired).
>
>So, any of you folks ever run into anything like this before?  Any
>suggestions?
>
>
>-Roy
>
>
>
>p.s.  As promised, the system specs are RedHat 7.2, XFree86 4.1, Mesa
>3.4.7, glut version that ships with Mesa 3.4.7 (sorry-- can't get at my
>system right now to determine the glut version), all on an AMD K6-II 500
>MHz box, FIC 503A motherboard (VIA chipset), Matrox G450 videocard.  I
>have tested out glut and yes, it works just fine (the gears demo runs at
>about 500 frames/sec), as does XFree86 and OpenGL in general.
>
>
>_______________________________________________
>plib-users mailing list
>pli...@li...
>https://lists.sourceforge.net/lists/listinfo/plib-users
>

-- 
Brian Hayward

[Plib-users] invalid OpenGL context problem

[Roy W. <ro...@ce...>]

This is an odd problem that I'm hoping that someone can shed some light 
on....

I'm having trouble with PLIB on my machine (RedHat 7.2, exact specs 
below, if that matters; and yes, all the underlying X/OpenGL stuff is 
fine-- I checked).  The specific symptoms are that calls to functions 
like puInit() are failing with a warning of "puInit() called with an 
invalid OpenGL context."  This occurs even for simple examples in the 
PLIB demo tarball.

After some investigation, I've determined that the glut calls to set up 
the window are all completing correctly, but it seems as if there is a 
delay in the window creation such that puInit() is called before the 
window actually appears.  I tried delaying the call to puInit() and can 
actually see the window pop, but other calls to PLIB functions cause 
things to eventually crap out (I may be able to tweak it into working 
correctly, but it was getting late and I was tired).

So, any of you folks ever run into anything like this before?  Any 
suggestions?


-Roy



p.s.  As promised, the system specs are RedHat 7.2, XFree86 4.1, Mesa 
3.4.7, glut version that ships with Mesa 3.4.7 (sorry-- can't get at my 
system right now to determine the glut version), all on an AMD K6-II 500 
MHz box, FIC 503A motherboard (VIA chipset), Matrox G450 videocard.  I 
have tested out glut and yes, it works just fine (the gears demo runs at 
about 500 frames/sec), as does XFree86 and OpenGL in general.

Re: [Plib-users] accessing the camera-/modelview-matrix

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

Volker Poplawski wrote:

> well, these methods don't set the model-view-matrix directly, the transpose
> and negate the given matrix and exchange the y- and z-axis before applying to
> the cameraMatrix.

That's true - but necessary if we are going to stick with the two concepts
that:

1) SSG supports Z-is-up coordinate systems. (Sorry - that's how it is and
   it's not going to change)

2) You are positioning the camera in the world and not the world
   relative to the camera (which is what everyone expects when you
   position the camera).

If you want to do it your way, you'll have to define an ssgTransform
at the top of your scene graph and plug your matrix in there.  That way
it won't be inverted - but Z-is-up is still the rule.

> Right now i'm using ssgSetCamera( myMatrix ) but i'have to do the
> transposeAndNegate and exc. y-z on myMatrix first to have the operations
> later reverted by ssgSetCamera(), somewhat sub-optimal...

Well, you are probably only doing it once per frame - it should take
less than a millionth of a second to execute - so I wouldn't sweat it.

I don't see this as being worth the effort to add to the API something
that you are almost certainly going to be the only user of - and can easily
work around.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] accessing the camera-/modelview-matrix

[Volker P. <pop...@in...>]

On Sunday 06 January 2002 03:06, you wrote:
> Volker Poplawski wrote:
> > I'm playing around with plib/ssg in combination with Qt. I wonder why
> > there is no method to directly set the cameraMatrix in ssgContext.
>
> What's wrong with:
>
>    ssgContext::setCamera ( sgMat4 mat )
>
> ...or...
>
>    ssgSetCamera ( sgMat4 mat ) ;

well, these methods don't set the model-view-matrix directly, the transpose 
and negate the given matrix and exchange the y- and z-axis before applying to 
the cameraMatrix.
Right now i'm using ssgSetCamera( myMatrix ) but i'have to do the 
transposeAndNegate and exc. y-z on myMatrix first to have the operations 
later reverted by ssgSetCamera(), somewhat sub-optimal...

>
> (which operates on the current context for backwards compatibility)
>
> > Is this a missing feature or is there a smarter way to do it?
>
> I think maybe it's not documented.
>
> ----------------------------- Steve Baker -------------------------------
> Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
> URLs : http://www.sjbaker.org
>        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
>        http://prettypoly.sf.net http://freeglut.sf.net
>        http://toobular.sf.net   http://lodestone.sf.net