Here's the deal -- I'm projecting NTSC video frames (my textures) onto a 'screen' that I've placed under the HUD b/c I'd really like to use the synthetic scenery as a backdrop for live flight video (UAV groundstation). It works... except for this texture "conflict" thing I keep getting hit with.

My textures (video frames) are actually being loaded and displayed by FlightGear just fine (I can send pics!)... which leads me to believe the attributes are Ok. I'll glPush the attributes specifically to see if it helps, though. I'm also following the rules (glGenTextures, etc) to keep from conflicting with everyone else.

I'm using the C-172 w/ 2D panel and my class calls are all made from within hud.cxx. I'm calling my Init() method (allocates the system memory region for the frame grabber) when the HUD is turned on via the masterswitch ("h"). I'm calling my Render() method (gets/displays a scaled subimage of the grabbed frame) from within drawHud(). Is this within the "main thread" that Curtis is talking about? Should I be doing this stuff elsewhere?

If I let the sim come up and then enable the HUD ("h"), my video happily appears. The segfault I'm seeing only occurs (according to gdb traces) when FlightGear begins to load/allocate other textures. This appears to occur when I either (1) leave the immediate area, or (2) attempt to minimize the panel ("s") AFTER I activate my video. If I minimize the panel (thus getting all of the texture init stuff out of the way) and THEN activate my video ("h"), I can switch back and forth between the 2D panel and mini panel all day with my video active..

Another question -- can I use plib to manage what I'm doing if my texture data is already in memory instead of in a file? I poked at the classes in ssg but all I found were load() methods that used filenames. I can write a class... but if it's already there I'd rather avoid the extra work.

D

-------
Curtis L. Olson wrote:

D Wysong wrote:

I'm religiously preserving the OpenGL state around everything
that I'm doing (glPushAttrib() and glPopAttrib() with
GL_ALL_ATTRIB_BITS). Is there something more bulletproof?



Hmmm, I seem to recall that there are some issues with glPush/PopAttrib(). I don't think they handle *every* possible state change, just the more common ones. You need to carefully read the opengl manual to make sure that the things you are changing are indeed covered with glPush/PopAttrib(). Also, I think we've found occaisional bugs where glPush/PopAttrib() doesn't always work as advertised. If your modified app is crashing, I suspect that either you will eventually find a state management problem, you are trying to do opengl calls outside of the main render thread, or you have a bug and are doing something (or a sequence of somethings) that opengl thinks is illegal or can't deal with.


Glad to know that FlightGear uses non-plib textures, too. Can
you point me to a place in the source code where this occurs?



The opening splash screen does this, as does the 2d instrument panels. Cloud textures might also be loaded outside of plib.


Curt.



_______________________________________________
Flightgear-users mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to