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

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

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