Comment viewing options

I love the way my rant "please provide documentation for the object-parameter of ReadPixels" spurred a completely new, faster and easier-to-use way of OpenTK! You really must love documenting things. :)

BTW: how does the automatic GL error thing work? Cannot see any comment on that in the release notes.

For automatic error checking, simply use the debug version of OpenTK. This (probably) carries significant overhead, so don't forget to switch to the release version before, well, releasing your program.

I'll add a manual entry explaining how to switch between debug/release configurations automatically.

As I've tinkered with 3d graphics, I've come to believe that 3d graphics application tend to be more tolerant of continuing in the presence of errors.

In the classes that I've built around OpenGL functionality I've often checked for errors and thrown exception on failure. Since I am the primary / exclusive consumer of my projects, there has not been much pushback on this approach.

I think your decision to log errors tells me alot about your views on the matter, but I am curious if you could provide further detail on what guided your decision.

The OpenGL extension specs are full of remarks like 'failure of an operation may not lead to program termination, but the result is undefined' which tends to lead to weird results and can be time consuming to track down. Causing the debug build to break on any GL error saves developers time to c&p dozens of GetError calls to find the culprit, and it also works on platforms which GLIntercept doesn't support. :)

Regarding the Efx example: I recall to have ported all OpenAL examples from the SDK which did not rely on their .wav loader, and Efx was also tested and confirmed to work in the process (X-Ram is the still untested extension iirc). I don't recally why we didn't add the SDK examples, was it legal issues?

This is a feature that aims to aid debugging. It is not intended as a substitute for error handling in the application level - which should use exceptions.

It may look strange at first, but exceptions would be the wrong approach in this case. The user would be tempted to write exception handlers, even though he shouldn't (because no exceptions will be generated in release code, making his handlers 100% useless).

Additional error logging is intuitive. Additional exceptions that you have to avoid handling are not (congnitive dissonance).

Note that I am not setting a precedent here: Mono follows a similar approach in its System.Windows.Forms implementation (X11 errors are logged and execution continues happily). System.Drawing completely swallows some kinds of GDI+ errors.

Edit:

Inertia wrote:

Regarding the Efx example: I recall to have ported all OpenAL examples from the SDK which did not rely on their .wav loader, and Efx was also tested and confirmed to work in the process (X-Ram is the still untested extension iirc). I don't recally why we didn't add the SDK examples, was it legal issues?

No idea! I've completely forgotten these, let me track down the code and see what the matter was (this is what happens when you don't implement a bug tracker in time :/)

Regarding glGetError and GLIntercept, I just have been trying to emulate the glIntercept log behaviour, but it is not as trivial as I hoped. Right now I'm not sure how to print the values of paramaters like 'Byte* bitmap[_ptr]' as they can not be converted to object (for String.Format)