the Fiddler's picture

The Open Toolkit library 0.9.6

This release introduces:

  1. Automatic OpenGL error checking
  2. Generics for improved type-safety in the OpenGL bindings
  3. Bug fixes related to OpenGL 3.0 contexts on Linux
  4. Improved documentation in OpenTK.Graphics
  5. A new EFX example ("EFX: Reverb").

This release contains potentially breaking changes. Please read the release notes and known issues before upgrading.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
objarni's picture

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.

the Fiddler's picture

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.

objarni's picture

Yeah but what does automatic error checking mean..?

Is there an error log? An exception? A messagebox? Something else?

the Fiddler's picture

The error checking code is equivalent to Debug.Assert(GL.GetError() == ErrorCode.NoError). Debug.Assert logs an error to the trace log and optionally displays a MessageBox for GUI applications.

Edit: I am going to add all this to the manual, no worries. This feature is intended to provide additional debugging information without you having to litter your code with calls to GetError().

objarni's picture

I think the feature is great!

Kamujin's picture

Automatic error handling sounds like a useful improvement.

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.

Inertia's picture

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?

the Fiddler's picture

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 :/)

pokemoen's picture

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)

Currently it generates lines like:

Debug.WriteLine(String.Format("Bitmap({0}, {1}, {2}, {3}, {4}, {5}, {6})", width, height, xorig, yorig, xmove, ymove, bitmap));
the Fiddler's picture

I'm not sure I understand what you mean by Byte* bitmap[_ptr] (array of byte pointers?) If it's a plain old pointer, just:

new IntPtr(bitmap).ToString()

;)