Julian Foad wrote: > In my experience, debugging FG (single-stepping, run-to-here, etc.) is > almost impossible under GDB and I believe the OpenGL "I'm in charge of > the main loop" philosophy is the main cause.
I've successfully and productively run fgfs under gdb just fine. I'm not sure there's anything particularly strange about the GLUT main loop; it's actually pretty standard C. There's deep voodoo inside of the glXSwapBuffers() call, but that's not part of the event loop (nor has it caused any trouble for me that I couldn't blame on driver bugs). I *have* had difficulties getting GDB to recognize symbol names, however. Starting it up and trying to set a breakpoint for YASim::init() doesn't work, but YASim.cxx:123 (that is, the line number in the file) works just fine, so I never bothered trying to track this down. My suspicions, though, point to gcc/gdb being a little off on their name mangling conventions and/or my use of namespaces getting in the way. I've never had trouble with the OpenGL-ness of the thing, anyway. Are there particular symptoms you're seeing? > Could we abuse OpenGL by making the idle function always request > OpenGL to terminate its loop? Strictly, you're talking about GLUT, not the OpenGL libraries. And unfortunately, no. The GLUT licence doesn't allow redistribution of modified versions. There's a FreeGLUT clone that is supposed to work, I think Norman mentioned a while back that he'd run FlightGear under this. Frankly, if we really want to move away from GLUT, for whatever reason, I'd suggest SDL instead. Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
