I have just posted GLIntercept 1.0 to the website:
Note that GLIntercept was mainly designed as an OpenGL 1.0-2.1 debugger. So while basic function logging should work on all OpenGL versions, the more advanced features (image/frame buffer/shader editor) may or may not work in OpenGL 3.0+. (especially when using a core OpenGL profile)
I have mostly just added the logging for newer functions and fixed some minor bugs. (note you can add you own functions definitions to the text file parsed on startup - so you can log extensions as they come out)
Thanks to alfonse for his XML listing of extensions - made my job much easier.
If someone has an OpenGL 4.0 card, can they test the OpenGL samples pack 4.0+ examples?
I only expect basic logging to work with 4.0, but I want make sure errors are not generated. (yes, I should get myself an OpenGL 4.0+ card - but have been on consoles for the last few years - and now unemployed since THQ-OZ went down)
If you test with you application and find any obvious bugs, please let me know.
It seems that the installer is corrupt… at least I have an error when I launch it.
Humm, what is the error?
I just downloaded and checked both versions - they both seem fine.(32/64 bit versions)
What OS are you running?
A meaningful less error 216 at 76A6BBCC
I just downloading again to double(or at least triple) check but I still have the same error when I launch the installer…
I’ve just downloaded and installed the 32-bit version without trouble.
Many many thanks for this tool by the way, it’s been very valuable to me in the past.
It worked at home. I wonder if it had to do with administrator writes.
OK - I re-packed the installer with the latest version of inno Setup and re-uploaded the files.
Let me know if they now work at your work.
I did some quick tests with the OpenGL Samples.
I am not sure everything is perfect. Do you handle the differences between core and compatibility profiles?
Also I had an error store in glilog.txt “GL ERROR - Function glDrawElementsInstancedBaseVertexBaseInstance generated error GL_INVALID_ENUM” with ogl-420-image-load but I have no error without GLIntercept.
In the AMD ARB_debug_output, this error is “Using glIsEnabled in a core context with parameter <cap> and enum ‘0xde1’ which was removed from Core OpenGL (GL_INVALID_ENUM)”.
So you are testing on AMD?
It seems that I have missed removing a lot of glIsEnabled calls when using a core profile (in this case GL_TEXTURE_2D)
Seems that Nvidia does not generate errors for these cases?
Do basic logging (not image or shader dumping) work OK?
Oh I think I see what the issue is, a lot of the OpenGL 4.0 examples use glBindProgramPipeline, instead of a standard program binding, so the code is falling back to test for fixed function enables. (error on my part)
OK I have uploaded a new version (1.0.1) that should not have the glIsEnabled(GL_TEXTURE_2D) errors in core profile - strange that Nvidia drivers did not flag this as an error?
Still installer error at work…
Will try version 1.0.1 at home and let you know.
Otherwise, a zip file is good!
Works like charm on my side. What OS you’re on?
Compile from sources
Seven 32, see up
That’s another option but I guess if I have a problem, I am not the only one so I just report the bug.
Yes, I will do a zip file - the only reason for the installer is so that the paths in the sample config files are updated to the install location.
Might actually wait a little to see if any more bugs fall out - have already found a few other minor ones.
I haven’t done a full test yet but I will and let you know on time.
OK I have just uploaded a new version 1.0.2
This fixes some minor bug in the function parsing and adds the NV_path_rendering extension
The NV_path_rendering extension was actually a pain to support as it has the first OpenGL call to return a float value. (glGetPathLengthNV) I ended up having to do a manual logging of it.
I also included a manual install zip file for people that have trouble running the installers.