gDEBugger new version is out. We would like your feedback

Hi All

gDEBugger version 1.2 has been released. This new version adds an interactive texture viewer, an improved HTML log file and a lot of other changes.
Please download it from www.gremedy.com and give us your comment.

We are currently releasing a new version of gDEBugger every ~ 1.5 month. We have a lot of new features and enhancements in mind, but we would like to hear your inputs on:

a. Which features would like us to improve / change?
b. Which features should be added?
c. What are the annoying things?
d. Are there bugs / usability problems that disable you from using gDEBugger?
e. Any good words :slight_smile:

I encourage you to use this page and give us your feedback.

We will do our best to make gDEBugger as useful and productive as we can.

The gDEBugger team
www.gremedy.com

It is not working very much for me right now.

The gui shows nothing but logging to file works though.

There seems to be a small problem with the images link though. Looks like mozilla does not like the ..
file:///C:/Documents%20and%20Settings/Eric/Local%20Settings/Temp/Engine-Thursday_27_January_2005-20_21_55/.\CContext2-Texture2-LOD0-2D.tif

By the way, the image beside the texture call is an awesome feature. I have been sloppy and so I can see my random binding pattern ! :slight_smile:

I would like to be able to pick a directory for the logs. I don’t like to dig very deep in my directory structure.

Little less important, but I think grayscale textures should stay grayscale instead of putting the color in the red channel. Simply put the color value in all color channel would do the trick.

To :Gorg
I assume you have tried http://glintercept.nutty.org ?

I also could not get the image view to display any images.

It would probably be a good idea to allow people to save the log in text as well as html as it makes it easier when running diff programs on different runs.

Perhaps making the deirectory where the logs are save to a bit more obvious (perhaps as part of the wizard?)

I might sugges the default image save format be other than .tif, as the browsers I tried did not seem to like it much. (broken image)

Hi Gorg,

Originally posted by Gorg:
[b]It is not working very much for me right now.

The gui shows nothing but logging to file works though. [/b]
The views display the information only when the process is suspended (F6).

If the process is suspended and you still face the same problem, please let us know the following:

  1. Does it happen with all views or just with some of them?
  2. Do you have the same problem with the “Graphic Remedy’s teapot example”?
  3. Do you have a sample program reproducing the problem, which you can send us for debugging?


There seems to be a small problem with the images link though. Looks like mozilla does not like the ..
file:///C:/Documents%20and%20Settings/Eric/Local%20Settings/Temp/Engine-Thursday_27_January_2005-20_21_55/.\CContext2-Texture2-LOD0-2D.tif

It is not a mozilla '.' specific problem. There is a problem to display Tiff files inside the browser. The default file format was defined as tiff (I changed the default when testing the application and forgot to change it back). You can change the file format in the options dialog. The version that is currently on the web server is fixed.

[b]
By the way, the image beside the texture call is an awesome feature. I have been sloppy and so I can see my random binding pattern ! :slight_smile:

I would like to be able to pick a directory for the logs. I don’t like to dig very deep in my directory structure.
[/b]
You can set the directory for the logs in the Debug Settings Dialog (CTRL-D). We will add it into the wizard in the next version.


Little less important, but I think grayscale textures should stay grayscale instead of putting the color in the red channel. Simply put the color value in all color channel would do the trick.

We will check this out.

The gDEBugger Team

Originally posted by sqrt[-1]:
[b]

I also could not get the image view to display any images.

It would probably be a good idea to allow people to save the log in text as well as html as it makes it easier when running diff programs on different runs.

Perhaps making the directory where the logs are save to a bit more obvious (perhaps as part of the wizard?)

I might suggest the default image save format be other than .tif, as the browsers I tried did not seem to like it much. (broken image)[/b]

  1. What have you got in the Texture Viewer when the textures could not be displayed?
  2. Our html logging is very light html. It is basically text file with
    instead of /n and link to the images where needed.
  3. The default logs directory is the TEMP directory of the computer. As mentioned, we will add it into the wizard.
  4. Fixed. The tif format was intended for 3D textures, GPGPU and cross platform use.

Regards,
The gDEBugger team

  • i get a crash trying to look at my system specs
  • also crash when changing to “front interactive”
    (and it says i could view whats being rendered step by step, dont know where this is suppost to show up?)

im wondering if you could make a special programmers library so programmers can put in say some code:

gdebugComment(“some random comment”);

and you can break at these points also, this would allow users to set set points so they when a new frame is occuring, or if they want to analyse functions more indepth.

some profiling settings would be nifty 2. ie. how long a gl call takes.

Windows 2000, Xp ???

What about other OSes ? Are there even plan to be supported ?

Here were my feedbacks.

Hi supagu

[b]

  • I get a crash trying to look at my system specs
  • Also crash when changing to “front interactive”
    (and it says i could view whats being rendered step by step, dont know where this is suppost to show up?)

[/b]

These problems are new to us. Can we get a demo of your application for testing?
If this is not possible, can we send you a test version of gDEBugger?

[b]
im wondering if you could make a special programmers library so programmers can put in say some code:
gdebugComment(“some random comment”);

[/b]

This mechanism was proposed to us by few users. We think its a good mechanism. We will implement it in one of our coming versions.

[b]
Some profiling settings would be nifty 2. ie. how long a gl call takes.

[/b]

A lot of profiling abilities will get into the next gDEBugger version. All you have to do is wait for ~1 month :slight_smile:

The gDEBugger team
www.gremedy.com

Hi jide

Windows 2000, Xp ???
What about other OSes ? Are there even plan to be supported ?

gDEBugger infrastructure and GUI were written in a cross platform approach and are using cross platform components.
Since gDEBugger is a new product, we would first like to make it more robust and mature on Windows and then start porting it to other platforms.
The next platform will probably be Linux.

The gDEBugger team
http://www.gremedy.com

I did not realise that you had to pause the app to get textures to display. Once I did this, they all showed up. (you may mention this in the docs, but perhaps having a “waiting for app to pause” or something in the texture dialog if it is brought up while the app is running?)

Hi All

Thanks to this discussion item posts and emails we got from a lot of users we built a new gDEBugger version that contains a lot of bug fixes and adds support to a GREMEDY_string_marker extension.

This version can be downloaded from:
http://www.gremedy.com/download.php

String markers are text messages that can be embedded in the OpenGL calls history log of your application. This is done by using the GL_GREMEDY_string_marker OpenGL extension. String markers help you make the OpenGL calls history log more readable: you can mark any logical operation / section executed by your application with a string marker.

Examples:
glStringMarkerGREMEDY(17, “Setting up lights”);
glStringMarkerGREMEDY(20, “Drawing object no 10”);

Notice that the use of the OpenGL extensions mechanism enables you to add, permanently, the string markers code into your source code. This code will be activated only when you run your application with gDEBugger.

Below is the detailed version content. As far as we know, we addressed and fixed all the issues that were raised in this discussion item posts.

Added:

  • GREMEDY_string_marker extension support.
  • String markers are displayed in the OpenGL functions calls History View.
  • String markers are displayed in the HTML calls history log file.
  • String marker toolbar that allows quick navigation between the string markers logged by the OpenGL calls history log.

Changed:

  • The GRTeaPot.exe example application now embeds string markers.

Fixed bugs:

  • glTexSubImage3DEXT calls were not executed by gDEBugger.
  • When calling glDeleteTextures with texture name = 0 or a not existing texture name, the debugged process crash.
  • Calling glTexImage3DEXT or glTexImage3D generated a GL_INVALID_VALUE OpenGL error.
  • Textures that have a single or double component internal format (GL_LUMINANCE, GL_LUMINANCE_ALPHA, etc) are now displayed as gray-scale images.
  • Alpha textures (GL_ALPHA, GL_ALPHA4, etc) are now displayed as gray-scale images.
  • The HTML log file texture image files reference used backslashes instead of slash.
  • 1D texture images are now stretched to enable easier viewing of their content (Textures viewer).
  • The “New workspace” wizard now displays the “Log files directory”.
  • The “New workspace” wizard “Swap Buffers” frame terminator was changed to “on” by default.
  • gDEBugger didn’t display an error when the “Log files directory” was empty and the user started debugging using the “Step” command.
  • The “Texture Viewer” textures list is populated faster.
  • glTexParameter calls that changed the texture border (GL_TEXTURE_BORDER_COLOR) were not logged correctly.
  • The “Texture Viewer” and “Source Code Viewer” are now opened on top of other windows.
  • The “Texture Viewer” “Depth slider” range was not cleared when switching from a 3D texture viewing to a 2D texture viewing.
  • The “Texture Viewer” image view style was changed when viewing 3D textures.
  • The “Properties View” and “Texture Viewer” now displays aid messages like: “The Views information is displayed only when the debugged process has been suspended”.

As always, comments, bug reports and suggestions are welcomed.

The gDEBugger team
www.gremedy.com

Being able to view the back/alpha/stencil/depth/aux etc buffers would be a very useful feature.

Being able to view the back/alpha/stencil/depth/aux etc buffers would be a very useful feature.

Hi arekkusu

Thanks for your input. A “Buffer Viewer” is definitely in our plans. We also plan it to show pbuffers and frame buffer objects.
Until this view is implemented, you can view the content of the back buffer by using the “Interactive Mode Toolbar”. This toolbar lets you force OpenGL to draw into the front color buffer, add slow motion delay and even force the flush of the graphic pipeline after each executed OpenGL command.

The gDEBugger team
www.gremedy.com

Another problem is incomplete enumeration listing in the HTML log:

glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, 34160.00)
glTexImage2D(GL_TEXTURE_2D, 0, 32856, …
glClear(0x4000)

These constants should be replaced with their symbolic enumeration names.

Just what bugs do you envisage gdebugger being used to solve? In all honesty, I can’t think of a single time in the past where this would have been useful.

arekkusu wrote:

[b]Another problem is incomplete enumeration listing in the HTML log:

glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, 34160.00)
glTexImage2D(GL_TEXTURE_2D, 0, 32856, …
glClear(0x4000)

These constants should be replaced with their symbolic enumeration names.[/b][/QUOTE]

Hi arekkusu

Thanks for the bug report. We will fix it for our next release.
Meanwhile - you can see the right values in the Texture viewer (It is already implemented there).

The gDEBugger team
www.gremedy.com

When finding bugs in drivers it can be usefull. I send an output to nvidia with glcommands that really should work but didn’t.

but how would this help you in those circumstances? You know the commands you issued, you know the results you expect. gdebugger simply tells you the commands you issued, nothing more.
I’m not criticising for the sake of it, I just need someone to give me a scenario where gdebugger saves the day.
glintercept has its runtime shader editor, freeze&fly…and it’s free.

I suggest you to make it not as expensive as it is now. I think that a $100-$200 price frame will boost your sales.

I was just thinking of a scenario, where you might not be able to debug your code as it might be too complex with state changes etc.

The method to get the linear commands issued to the GPU can help you in pinpoint some bugs as you might “compile” and understand what is happening.

I don’t use gdebugger but i have a system where all commands are patched and can be reported into a logg, and this helps me when i debug large scenarios in Gizmo3D wher the scene graph traversal can not be debugged with single steps…