From: Steven White <stevenw@li...> - 2008-11-08 18:46:07
Mike C. Fletcher wrote:
> Steven White wrote:
>> After dinner I was able to sit down with some help and remove several
>> questionable lines of code that had slowly found there way in to the
>> code as I was stripping down the application during debugging to find
>> the error. Unifying the type to GL.GLuint seems to have fixed the
>> system crash problem, but the VBO will still does not post to the
>> display. By removing the index buffer and only using the index data
>> during the glDrawArrays call I was able to get what looked like a
>> bow tie artifact on the screen on my friends fedora 5 machine, but
>> both of my personal machines render only the clear color.
> I've attached a version that (with current BZR head of PyOpenGL)
> renders two squares. You can comment out the second call to
> glDrawElements if you want to run it on an older PyOpenGL. I'm just
> using the OpenGL.arrays.vbo.VBO implementation, I know, lazy, but oh
> well. If you want you can just trace through and see what OpenGL
> calls are running with the VBO bind/unbind calls. This version will
> work with either core or ARB versions of vertex buffer objects.
> BTW, if you could just attach runnable files when sending a support
> request it would help me. Having to strip off the line numbers uses
> up time that could be spent on development.
>> I have stripped my application to an exit command and a single
>> polygon render and attached copied it at the bottom of this message.
>> I am hopping in the morning someone with more experience in pyOpenGL
>> can inform me on what may be causing the issue. As a side note I am
>> having a rather hard time debugging the application because non of my
>> profilers seem to be able to intercept the opengl calls. Does anyone
>> have a solution for the OpenGL side of an pyOpenGL application like
>> you would in C.
> You can use the built-in pdb module to debug Python code. Just do:
> import pdb; pdb.set_trace()
> before the call you want to trace into and you can step down to the
> call that's going into the GL. Since that call is normally to the
> system GL directly it's somewhat difficult to trace it below that (you
> can go into ctypes, but that's seldom useful), since ctypes has
> stabilized I haven't had to go below that level.
Thanks for the help. I wasn't sure if the mailing list would allow
attachments, I will make sure to do so in the future
Steven A White