Home » Discussion forums » OpenTK » Support
iliak's picture

glslDevil

Posted Thursday, 3 June, 2010 - 19:11 by iliak in

Does glslDevil work with OpenTK ? Everytime I try, here's the result :

wglCreateContext(85010B10)
wglMakeCurrent(85010B10, 00010000)
wglMakeCurrent(00000000, 00000000)
wglDeleteContext(00010000)
wglCreateContext(85010B10)
wglChoosePixelFormatARB(85010B10, 040C7A10, 00000000, 1, 040C7AAC, 040C7ABC)
wglGetPixelFormatAttribivARB(85010B10, 8, 0, 18, 040C7968, 040C79BC)
wglDeleteContext(00020000)
wglCreateContext(95011142)
wglChoosePixelFormatARB(95011142, 040D15C4, 00000000, 1, 040D1660, 040D1670)
wglGetPixelFormatAttribivARB(95011142, 10, 0, 18, 040D151C, 040D1570)
wglDeleteContext(00030000)
wglCreateContext(49011081)
wglMakeCurrent(49011081, 00040000)
wglGetCurrentContext()
wglGetCurrentDC()
wglGetExtensionsStringARB(49011081)
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
wglGetCurrentContext()
[....]
‹ loading .HDR and .EXR images Stutter, jitter and then, not?! ›

Comments

Comment viewing options

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

Re: glslDevil

Posted Thursday, 3 June, 2010 - 22:41 by the Fiddler

This log doesn't look normal but I don't think this is caused by OpenTK.

Are you using a debug version of OpenTK.dll? If so, try with a release version.

retro_alt's picture

Re: glslDevil

Posted Thursday, 1 July, 2010 - 16:54 by retro_alt

*bump*

I am having the same issue. It seems that it is only able to trace the wgl* calls and nothing else. I tried the release version and no difference.

Does OpenTK hook into the GL function calls differently than a normal GL program? I ran the program (mine, not glsldevil) through the dependency walker and it seems to use the system32\OpenGL32.DLL file directly, instead of using its own copy; could this be part of the problem?

the Fiddler's picture

Re: glslDevil

Posted Thursday, 1 July, 2010 - 19:09 by the Fiddler

Ah, of course, OpenTK calls LoadLibrary on opengl32.dll. On the other hand, windows should search order in the application directory first (see Dynamic-Link Library Search Order), so I don't know what this means.

Can glslDevil debug 64bit applications? (Maybe you are running as AnyCPU on 64bit windows?)

retro_alt's picture

Re: glslDevil

Posted Thursday, 1 July, 2010 - 20:06 by retro_alt

True, there is no problem with the OpenGL32.DLL loading.

This is definitely 32-bit Windows and it was built using the x86 profile instead of AnyCPU.

It seems peculiar that the wgl* calls all work perfectly but that none of the gl* calls are showing.

retro_alt's picture

glslDevil AND gDEBugger

Posted Friday, 2 July, 2010 - 16:47 by retro_alt

I have it working. The two conditions for glsldevil and gdebugger working with OpenTK are these:
1. No long (or possibly deep) pathnames.
2. GL code must all be running on the main thread. I originally had a form kick off a new thread (and window) to run the OpenGL stuff, but this makes it not work.
3. In glsldevil try letting it run (F8) until the window shows, and _then_ let it start analyzing. it.

Hope someone else finds this useful