Erik Hofman writes: > Curtis L. Olson wrote: > > Erik, > > > > Using glGet() is considered a no-no in real time applications. That > > stalls out the pipeline and forces all pending operations to flush > > before the card can return with the correct answer. We might be able > > to get away with it in limited quantities, but this can *quickly* turn > > into a performance killer (probably varies signifantly from platform > > to platform.) > > > > Please consider an alternative approach! > > The only thing I can think of is not using glFogf() until this issue is > resolved. Anybody else have a suggestion?
I haven't looked into this issue very closely. I have an nvidia card and wasn't seeing anything odd, but perhaps I wasn't looking closely enough. My gut feeling is that it is less likely that we have found a bug in nvidia's opengl drivers and much more likely we are doing something slightly odd, or misunderstanding the nuances of the opengl calls we are using. ssg's lazy state evaulation mechanism is set up precisely so that we can minimize state changes by note reseting things that are already set correctly *and* avoid doing glGet()'s because the lazy state evaluator knows the current state of all the items it tracks. However, ssg only tracks a limited set of parameters which is why glPush and glPopAttrib() come in handy because they allow you to save, change, and then restore a particular item without actually querying it's original value. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
