Re: [Plib-users] Fwd: Re: flightgear problem

[pieter b. <xa...@gm...>]

greetings,

First of all, thanks for such a lengthy response.. It's all quite clear to me 
now.. So in a nutshell, the problem I am experiencing is due to a bug in that 
version of mesa.. I can't really comprehend how such an important call can 
get bugged, but anyway.. Due to that bug, the context doesn't "seem" ready to 
flightgear (using plib).. 

I don't think the fact of the 2.96 compiler has anything to do with all 
this.. All packages I installed are compiled by this compiler!

Fact is that XFree gl-parts and Mesa drivers must me "optimized" or 
something, in order to get direct rendering to work, and that's the main 
problem I'm facing now.. However, I will overcome (or perhaps do a hack (I 
won't distribute..:) )

thanks again!
-xas-

On Saturday 25 August 2001 03:05, you wrote:
> pieter bonne wrote:
> > behold, a problem propably related to plib..
> > in addition: FlightGear _does_ work when I downgrade mesa, but I lose 3d
> > acceleration by doing this.. is there a problem with plib and mesa?
>
> You shouldn't lose 3D accelleration when you downgrade Mesa - that just
> means that you didn't install the downgraded version correctly.
>
> I explained at some length what this problem is about last night - the
> conclusion:
>
>   * This is a Mesa problem - not a PLIB problem.
>     You have shown that by the fact that a downgraded
>     Mesa works OK with FGFS/PLIB.
>
> > : >> FATAL: ssgInit called without a valid OpenGL context. <<
> >
> > This is really a plib problem that affects FlightGear.  Plib always
> > checks for a valid GL context before it begins rendering, and it's
> > obviously failing.  We haven't quite figured out what's causing this.
>
> PLIB is absolutely entitled to check that the OpenGL rendering context
> is valid before starting rendering.
>
> > : I run mandrake8, heavily customized. kernel 2.4.8enterprise (mandrake
> > : package update), bleeding edge version of XFree4.1 and Mesa-3.4.2-3 &
> > : plib-1.4.2-1 (else I wouldn't have been able to compile I believe? ;)..
>
> Mandrake 8 and RedHat 7.xx are both based on the same crappy C/C++ compiler
> version. It wouldn't at all suprise me if that ended up being the problem
> that's showing up in Mesa.  I've not heard a single problem report from
> users of other distro's.
>
> > : One interresting sidenote is that Quake3, Rune, Heretic (1 and 2),
> > : gltron and other opengl accelerated programs (like xmms visualisations
> > : ie) all work with this configuration!! Could you help me out here?
>
> Those probably don't check for a valid context - they just go ahead and
> render anyway.
>
> > All reports we've had before now where specific to RedHat, but you are
> > using Mandrake...interesting.
>
> Mandrake have always taken the RedHat distribution as their starting point.
>
> In a sense, Mandrake 8 is just RedHat 7 with some minor variations.
>
> >  All I can tell you is that some folks
> > have had success downgrading Mesa.  I think one person had a conflict
> > between the xfree4 mesa libs and the "official" mesa libs.  i haven't
> > experienced this problem, myself.
>
> You do have to be VERY careful about removing the old OpenGL libs and
> headers - having both on the disk at the same time is disasterous.
>
> > The easiest way to test this is to use a plib example (from the
> > sources).  Once the plib examples work, FlightGear will work.  I will
> > try to add a FAQ entry for this (even though I don't know the solution
> > to the problem).
>
> Good plan.
>
> > You may also want to join the plib-users@ list to get some help with
> > plib internals.  I'm baffled at why Quake3 and Rune will work, but plib
> > apps won't.  :-/
>
> I'll paste in my reply from last night since you evidently missed it:
>
> Steve Baker wrote:
> > Cameron Moore wrote:
> > > Why do non-plib apps like Quake3, Rune, and gltron work while plib ones
> > > do not?  I mean, how can these non-plibs apps render without a valid
> > > context?  If they can't, how are they getting a valid context when plib
> > > isn't?  Or if it's possible to render without a valid context, why do
> > > we care if one exists (playing devil's advocate)?
> >
> > In OpenGL you are NOT ALLOWED TO MAKE ANY OPENGL CALLS WITHOUT A VALID
> > RENDERING CONTEXT.
> >
> > It's a rule - and that's that.
> >
> > Now, IIRC, in one broken Mesa version, the query function that checks
> > whether there is a valid OpenGL context or not is BROKEN...it says
> > "no valid context" even when there is one.  That's a bug in that version
> > of Mesa - and it needs to be fixed.
> >
> > So, if your application doesn't CHECK for a valid context - but happens
> > to have one anyway, it'll work just fine - even on the broken version of
> > Mesa.  However, if such an application were ever to fail to get a valid
> > context, it would crash mysteriously and without a good error message.
> >
> > HOWEVER, there is another class of "bugs" in OpenGL implementations that
> > you have to watch for.  Some of them tolerate you making *some* OpenGL
> > calls
> > before the rendering context has been created.  That's not exactly a bug
> > because correctly working OpenGL applications don't do that - and broken
> > OpenGL applications are just broken anyway.
> >
> > So, in the light of all that, you might ask why PLIB goes and checks that
> > the rendering context is valid.  Well, before we added that, people would
> > do all sorts of illegal things like loading texture maps before they'd
> > opened up an OpenGL window (a rendering context).  In particular they'd
> > try to call ssgInit() before they had a valid rendering context.  That
> > was a VERY BAD THING because the 'permissive' OpenGL implementations
> > would allow this and those programs would seem to work perfectly on the
> > authors computer - and then crash mysteriously on other people's machines
> > because they had OpenGL implementations that couldn't tolerate the error.
> >
> > This made life VERY difficult.  You'd write a program at home, test it
> > to death on your machine, post it to the internet and get stacks of
> > complaints from people who would claim that it crashed without an error
> > message.
> >
> > So, as a service to mankind, ssgInit (and puInit and IIRC, fntInit) all
> > check that there is a valid rendering context - and if there isn't
> > they'll complain and refuse to continue.  That means that even if your
> > OpenGL implementation is a 'tolerant' one, you'll find the error in your
> > program and fix it so that other people will be able to run it too.
> >
> > I think that's "A Good Thing" - and since we've added it, the number of
> > mysterious crashes inside PLIB on startup have been reduced *GREATLY*
> > because people now get a good error message instead.
> >
> > Now, along comes an OpenGL implementation with a bug in it...what should
> > I do?
> >
> > My decision:   Tell people to FIX THE BUG!!
> >
> > I'm not about to remove a valuable bug-tracer that's proved useful
> > (especially to PrettyPoly which has a very hard time with keeping the
> > startup sequence right and maintaining a valid OpenGL rendering context
> > at all times).
> >
> > CONCLUSION:
> >
> > PLIB is not in error here...it works very well on other versions of Mesa
> > and on non-Mesa OpenGL implementations.
> >
> > So - I make no apologies - please bitch and whine to the Mesa team (only
> > be gentle with Brian Paul - he's not getting paid to maintain Mesa
> > anymore
> >
> > :-(  ...so we have to be nice to him if we want to get things fixed! :-)
> >
> > FOOTNOTE:
> >
> > If you are *desperate*, look for 'glXGetCurrentContext' in
> > src/ssg/ssg.cxx, src/fnt/fntTXF.cxx and src/pui/pu.cxx and make the
> > necessary *HACK* - but please don't distribute that hack to all and
> > sundry because it'll make our lives hell again.  If it were me, I'd go to
> > an earlier or later version of Mesa - who knows what else is broken as a
> > consequence of this?
>
> ----------------------------- Steve Baker -------------------------------
> HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
> HomePage : http://web2.airmail.net/sjbaker1
> Projects : http://plib.sf.net       http://tuxaqfh.sf.net
>            http://prettypoly.sf.net http://tuxkart.sf.net
>            http://freeglut.sf.net   http://toobular.sf.net
>
>
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/lists/listinfo/plib-users