A quick OpenGL note for plugin authors: if your plugin uses OpenGL to draw (e.g. for a plugin in an airplane that draws a custom glass display) you should:
- In debug mode: always check the OpenGL error state (using glGetError) at the end of each draw callback that you handle. X-Plane will not leave OpenGL errors around, so any error is yours. (To verify that it’s not another plugin, just add a glGetError at the beginning of the callback.)
- In release mode: never check the OpenGL error state, as it can slow down the driver.
An OpenGL error often implies that an OpenGL command did not complete as expected (because a param is bad, etc.) and this can mean that you are not cleaning up OpenGL state for X-Plane!
(And of course you should always use XPLMSetErrorCallback in debug mode to catch plugin errors. Set a break point in your callback to see exactly where the error occurred.)
Good advise. Unfortunately you can’t backtrace a gl error more easily than “bisecting” your code with glGetError until you find the line where you induced it. We once had to chase one of those infamous error “1282” in code we hadn’t written and apparently no one had read in the last 5 years.
Fortunately, bisection always converges, despite it is slow 🙂
There are only two true debug methods: divide and conquer and printf. 🙂