BlueMonkMN's picture


Some Vista users are reporting problems, and I'm not sure if it's related to OpenTK or my own code. So far I know one user has version 6.0.6000.16386 of opengl32.dll, and is reporting the following error:
Error Screenshot

My own version of opengl.dll (5.1.2600.2180) on Windows XP works fine (I assume that's the significant DLL here). Is there possibly a compatibility problem working with different versions of opengl32.dll? Or just an OS problem?

The game in question was the same one linked in my previous post:
And the OpenTK code is based off of version 1166 from SubVersion.

(Edit: Also, what in the world is this "@" prefix I see on some of the parameters. I can't find any documentation on that for C#.)


Comment viewing options

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

Yes. I'll put the debug version along the release one in the next package.

Inertia's picture

Taking a quick look at the project, in Display.cs DrawFrame() DrawPoint() there might be more problems with changing state inside a begin/end block. Only a subset of GL commands can be used between glBegin and glEnd. The commands are:
glMaterial, and

Regarding extensions always reporting negative, this is most likely happening because there's no current GL context. Not sure if this is related, but Nvidia drivers under Vista64 seems to be rather slow at application start compared to Ati's (torusknot test launches on my config in the blink of an eye, while on a 8600GTS it takes more than a second until the app starts drawing. Both systems dual core AMD, >4GB Ram). I'd recommend trying to add a GL.Finish() very early into your initialization, to make sure there's no GL code executed before GL is ready for it.

BlueMonkMN's picture

I don't think there's any way for anything other than GL.TexCoord2 and GL.Vertex2 to execute between the GL.Begin in DrawFrame and a GL.End. The DrawFrame function sets m_currentOp to DisplayOperation.DrawFrames and every other GL call (which are all confined to the Display object) that might be called checks the state before doing any work. If it's going to execute any call outside the set you listed, it performs GL.End first if it sees that the state is not DisplayOperation.None. Do you see something I don't as far as allowing the potential for other functions to get in there? Maybe I need to add some protection to the Resize event. In any case, I'm not getting errors reported any more, which should be a good sign that nothing else is getting in there any more, right?

the Fiddler's picture

Not getting errors is certainly a good sign.

One thing that might be good to check: do you set parameters/mipmap levels for all textures? If you forget some, things may not appear (or may appear depending on default values set by the drivers).

BlueMonkMN's picture

I've never done anything with mipmaps, so I don't know anything about that, and the only parameters I set were those I found in the sample code from Basically I'm trying to draw 2D sprites with OpenGL using the example set by this code:

There have been a few adjustments since I copied that code (use TextureRectangleArb instead of TextureRectangleNv for example), but that's where I started. Is there something I should check to see if the hardware supports TextureRectangleArb? (The article mentions using TextureRectangleNv or TextureRectangleExt but not TextureRectangleArb, which I believe you mentioned a while back.)

the Fiddler's picture

First, you should check whether GL.SupportsExtension("GL_ARB_texture_rectangle"); returns true. The you should check every function from this extension with GL.SupportsFunction();

The fact that everything returns false in your system is not very encouraging (I'll have to check this), but everything seems to work here...

Also, check the specs for the extension. Especially this part:

NPOTS textures are accessed by dimension-dependent (aka
non-normalized) texture coordinates. So instead of thinking of
the texture image lying in a [0..1]x[0..1] range, the NPOTS texture
image lies in a [0..w]x[0..h] range.

Are you using the correct texcoords? Also, do you set a (non-mipmapped) minification and a magnification filter with GL.TexParameter, for every texture? If you don't, the textures will appear white.

BlueMonkMN's picture

After I moved the code to a place where the control was fully initialized, GL.SupportsExtension was working fine and returns true for VERSION_1_5 and for GL_Arb_texture_rectangle. Of course my system is the one where it works. I posted the result so others could try it. The one person who has replied so far says that he still gets an access violation exception before anything else. He tried it on a friend's computer with Vista and it seemed to work fine there. He tried it in safe mode on his own computer and got a message that OpenGL 1.5 was required (one of the tests I recently added) instead of the access violation. The binary he's using now is at

Edit: I am using the correct texture coordinates for the Arb extension (which is why everything works fine in my environment, I assume). I'm not limiting the range to be 0-1 (that never occurred to me until I started researching alternatives to ARB, NV and EXT, but I much prefer ARB or its rough equivalents, NV and EXT).

I do have the following code when creating a texture, which I assume applied the minification and magnification filters.

GL.TexParameter(texTarget, TextureParameterName.TextureMinFilter, (int)TextureMinFilter.Linear);
GL.TexParameter(texTarget, TextureParameterName.TextureMagFilter, (int)TextureMagFilter.Linear);

This user also reports that he's using an ATI Radeon Xpress 1150, and updated the drivers to 8.3 just under a week ago

Should I post some OpenTK sample/test application to see how it runs in that environment? (Does the newer TVSGDK2 run any differently in yours?)

the Fiddler's picture

Ok, the app now fails on the machine with the integrated 865 chipset (no VERSION_1_5 support). I'll test on the other machine when I get home.

A debug version of Examples.exe (comes with OpenTK) could shed some light to the AccessViolation.

Edit: or you could try sending your app with a debug version of OpenTK to your tester.

Without the debug output it's difficult to see what's going wrong (which function fails? why? is a context created? is the pixel format supported? are monitors enumerated? resolutions?)

Inertia's picture
public void DrawPoint(System.Drawing.Point location)
      GL.Vertex2(location.X, location.Y);

Either you are changing state inside a begin/end block here, or you are calling GL.Vertex2() outside one.

The game starts without any complaint under Vista64/Radeon 3870 (catalyst 8.3) and shows the options Play or Quit. (Any keypress will show unhandled exceptions, but that wasn't the question asked I guess)

BlueMonkMN's picture

Good catch on DrawPoint. Fortunately (or unfortunately, depending on how you look at it), this particular application doesn't call DrawPoint. DrawPoint is there primarily for the implementation within the IDE where it draws a picture of a path showing where the sprites will travel. Pretty much the only functions called at runtime are DrawText and DrawFrame.

The person who was reporting access violation exceptions says that the OpenTK samples were also reporting Access Violation exceptions, but the Mono samples worked fine. Looks like it might be a .NET problem.

What unhandled exception occurs when pressing a key?