Le 12/01/2014 18:01, Benjamin Thaut a écrit :
Am 12.01.2014 17:18, schrieb Xavier Bigand:
Le 12/01/2014 11:16, Benjamin Thaut a écrit :
Am 12.01.2014 00:47, schrieb Xavier Bigand:
I didn't know this menu settings, but activate Access Violation don't
change anything.
It seems that your crash happens inside the OpenGL part of the graphics
driver. It is caused by
DQuick\src\dquick\renderer3D\openGL\mesh.d line 125
I assume that you setup a few OpenGL parameters invalid and thus the
driver reads from a null pointer.
I found it by single stepping. I started the application, then set the
breakpoint like shown below and single steppt into the draw() method.
debug
{
if (mRebuildDebugMeshes)
updateDebugMesh(); // put breakpoint here
mDebugMesh.draw();
if ((implicitWidth != float.nan && implicitHeight != float.nan)
&& (implicitWidth != mSize.x && implicitHeight != mSize.y))
mDebugImplicitMesh.draw();
}
Have fun debugging ;-)
Kind Regards
Benjamin Thaut
Thank for your support and your time
I already tried to debug opengl with gdebugger is used to find those
kind of issues. But it doesn't seems working fine with D binaries.
I higly recommend using either glIntercept
(http://code.google.com/p/glintercept/) or glslDevil
(http://www.vis.uni-stuttgart.de/glsldevil/) to debug OpenGL applications.
If you have a nvidia card you could also use nvidia nsight to debug your
application:
https://developer.nvidia.com/nvidia-nsight-visual-studio-edition
My guess would be that either your vertex buffer or index buffer is no
longer valid, thus gets not bound, and as a result the graphics driver
reads from client memory at address null.
Kind Regards
Benjamin Thaut
I took a look to buffers manually just before the glDrawElements call,
and all values seems good. I also check if any glDeleteBuffers and
glDeleteShader,... was called before the glDrawElements.
I need find some more time to test with glIntercept or nvidia nsight
