Originally posted by V-man:
[b]OK, strings would work for me, but I think there is no need to have a GL specification because it’s not a graphics feature.
All that is needed is a slightly modified gl header, maybe call it gl_debug.h, lib, and dll
[/b]
I’d rather have an extension that’s only supported by the debugger. This makes it much easier to debug an existing program and just generate the messages dynamically without having to recompile anything. And changing system headers is just a big no-no in my book. Everybody has extension handling scaffolding anyway, making it relatively easy to add something like this.
(ed): I don’t think this should ever become part of the official OpenGL spec, but an extension description just makes it easy to read and understand.
Originally posted by dirk: [QUOTE]I’d rather have an extension that’s only supported by the debugger. This makes it much easier to debug an existing program and just generate the messages dynamically without having to recompile anything. And changing system headers is just a big no-no in my book. Everybody has extension handling scaffolding anyway, making it relatively easy to add something like this.
You have to recompile a release version anyway, if that’s what you mean.
Then a new glext.h will be needed
Either way, it doesn’t change my part of the work .
noticed this though
Diagnostic: Unknown function glPointParameteri being logged.
Diagnostic: Unknown function glPointParameteriv being logged.
also i didnt notice any way i can get a final count of the number of each function called
i also log them myself in my program so i wanna see if the two figures match
edit - had a look at the spec, seems like the int versions of point parameters werent in the original arb version of point parameters but are now part of the base spec
Originally posted by V-man: You have to recompile a release version anyway, if that’s what you mean.
Hm, not sure I understand you here.
My point was that you can just compile this into your regular debug version (or even into your release version, if your extension handling is efficient) and just leave it in there. Only when you run using the debugger will it do anything.
If you use a different gl.h, you will have to recompile it when you want to run the debugger (as the normal drivers don’t have the glComment() call), and that can be pretty painful just for a quick check whether your GL calls are correct. And then you have to recompile it against the normal gl.h to run it using normal drivers again.
Using an extension makes the whole thing dynamic, so it will work with the regular drivers and the debugging drivers.
Originally posted by zed:
[b]excellant application!!
noticed this though
Diagnostic: Unknown function glPointParameteri being logged.
Diagnostic: Unknown function glPointParameteriv being logged.
also i didnt notice any way i can get a final count of the number of each function called
i also log them myself in my program so i wanna see if the two figures match
edit - had a look at the spec, seems like the int versions of point parameters werent in the original arb version of point parameters but are now part of the base spec[/b]
Update done for next version.
In the meantime you can just add the following lines to <install dir>\GLFunctions\GLCore\GLCore1_4_Include.h
Originally posted by V-man:
I would be using preprocessor directives, so I can choose not to compile the marker codes and other things.
I think you are thinking of something like
if extension supported
glMarker(…)
endif[/QB]
Ok, that’s what I thought. Which means you will have to compile a specific version that can only be run under the gldebugger. I’m trying to avoid that and have a version that can run using standard drivers or the debugger.
I’ve got some feedback from Yaki Tebeka (gdebugger) and have an updated version of my proposal here .
Not sure what you changed, but you might want to add support for unicode. I think glProgramString had a parameter for that, although it wasn’t put to use.
I have small problem with glIntersept 0.41 -
If I use glew to initialize extensions I receive few messages like this:
GLI | ExtensionFunction::AddFunction -Unable to log function glVertexAttrib2dNV exceeded 500 num of wrapper functions
...
GLI | ExtensionFunction::AddFunction -Unable to log function wglSwapIntervalEXT exceeded 500 num of wrapper functions
And wglSwapIntervalEXT call actually isn’t logged. Is there any way to increase this “num of wrapper functions”?
Yeah that is my fault. I thought 500 extenstion entry points would be enough for a long time (silly me) You can either recompile with more or wait for a minor 0.42 update. (in a few weeks)
@sqrt[-1]
I just made small plugin for GLI thats draws overlay graphs with number of glVertex calls, draw calls, num of transformed vertices and num rendered triangles. Something like NVPerfHUD.
There should be a lot of work to finish this plugin, and I don’t have enogh time . Maybe community can help!?
Something like NVPerfHUD.
Would you like to send you a code? You can include it in GLI 0.42 release?
Sure, send it though to my email.(you should find it in the readme)
I may not include it but I am curious how you coded it. (My main problem with someting like this is making it robust and handle all the weird states that can be enabled by an application)
Fixes:
dorbie: I added a lot of legacy function headers and updated some of the interfaces to accept the “old way” of doing things. (Half life origional should now run fine- I started learning with OGL 1.2 so I had no idea of these “old” ways.)
V-man: I added a “ping” plugin for people who have apps that do not regulary update. What this simply does is a windows refresh if a OpenGL swap buffers has not been called within a set amount of time. (This has to be enabled manually)
harsman and ATI users: The GLSL editor has been updated to work around some ATI bugs (Still does not work with sampler uniforms but you now have basic functionality)
zed : A function stats plugin has been added. When enabled, it will dump to the log on exit a listing of all the OpenGL function calls made and the counts.(sorted by count and by name)
OGL2.0 drivers with ASM shaders : I fixed a bug that was generating OpenGL errors when using ASM shaders with OGL2.0 drivers. (Ancient code bug from when I thought that OGL2.0 would roll the ASM shaders into core)
Bumped number of extension entry points from 500 to 2000 hopefully this will be enough for a long time.
Headers have been added for OGL2.0/FBO and others.
Things still waiting for the 0.5 release:
OGL2.0 core shader interface. Currently the shader editor/logger only works with the ARB GLSL interface.
Comment logging extension.
Linux port.
FBO/PBO/draw buffers support in advanced loggers : Image and frame buffer logging in the current version may be hit and miss if you use these extensions.
If you know of demos or apps that use OGL2.0 shader interface or FBO/PBO, send me a link as I need testing applications.
zed : A function stats plugin has been added. When enabled, it will dump to the log on exit a listing of all the OpenGL function calls made and the counts.(sorted by count and by name)
hah, sweet i was actually thinking about updating my logging stuff last night too include all the glsl stuff, this will be a nice benchmark to check if the gl figures match up (to see where ive forgotten something in my code).
another useful function is to actually log the average number of calls per frame, ie after all initiation. very handy for optimization, eg ive found the most common gl call i make is glTexCoordPointer
i noticed a couple of differences between glintercept and my logger,
i assume most are from glIntercept calling the various get commands internally
glGetIntegerv // im logging less
glGetFloatv // im logging less
glBlendFunc // im logging heaps more ?
glGetBooleanv // im logging less
glGetQueryiv // im not using (except when i setup the extension ptr) but gliLog reports glGetQueryiv … 1
glGetError // im logging less
glGetString // im logging less
I don’t think the logger has the ability to log the internal calls I make.
The only thing I can think of is perhap you are making these calls without a context? (The plugin will count calls made out-side of a context) Or perhaps these calls are occuring behind your back if you use a loading library to load extensions? (no idea what is happening with glBlendFunc however)
As an experiment, enable the text logger then search for that glGetQueryiv call in the output log…
Pardon me for being a bit arrogant and assuming a bug in your code - I get a lot of bug reports that are false.
(If possible, give me a link to your app and I’ll check it out)
sorry yes it was a bug in my code. i was going
create opengl bogus context
query various opengl info (hence all the glGet… stuff)
destroy it
zero my logger
create the real window
run app
ill look into whats happening with the glBlendFunc cause there really is a big difference between the two figures mines about 5x as large (all the other 70 or so glcalls telly exactly between the two call loggers)
Everybody has extension handling scaffolding anyway, making it relatively easy to add something like this.
. Maybe community can help!?
- I get a lot of bug reports that are false.