I’m currently porting a 3D engine from iPhone to win32.
The engine is blowing up on the first glDrawElements call and I am having difficulties troubleshooting what is going wrong, can you tell me if I forgot to check something ?
- Checked indices array: no indice is pointing outside the interleaved vertices array.
- Checked length of indices array: it matches the length passed to glDrawElements.
- Client State is enabled for position, normal, texture Coordinate and set via glVertexPointer, glNormalPointer, glTexCoordPointer.
- Client State for GL_COLOR_ARRAY is disabled.
- Texture is enabled and a valide texture ID is binded.
- Tried to run a glGetError, no error found.
If I disabled rendition of the 3D models and only render with orthogonal projection, 2D sprites are rendered fine (via glDrawElements), so I think the GL context and the window are properly created.
The error message:
Unhandled exception at 0x024bfd08 in dEngine.exe: 0xC0000005: Access violation reading location 0x00006580.
StackTrace:
024bfd08()
nvoglnt.dll!69bc101a()
–
nvoglnt.dll!69bc2074()
nvoglnt.dll!69bc23bc()
nvoglnt.dll!6960f9f1()
libgles_cl.dll!004b1345()
libgles_cl.dll!004b5253()
dEngine.exe!RenderEntityF
It seems the Imagination drivers is passing to Nvidia drivers and it’s blowing up while in Nvidia drivers. I’m running on a GeFroece 8500 GT, latest Nvidia drivers (196.21).
Any idea how I can troubleshoot this issue ? I’m at lost 
!nicolasbol2010-03-15 23:36:01
Geez,
I was putting libgles_cm.lib, libgles_cl.lib and libEGL.lib in the linker’s Additional Dependencies.
I checked the SDK examples and only libgles_cm.lib was required, it fixed the crash.
Question 1: Any idea why including the 2 others was crashing the app ?
Question 2: Does libgles_cm.lib refers to libgles_cl.lib and libEGL.lib that’s why the DLLs are required ?
libgles_cl is a OGLES CommonLite profile, it should not be mixed with Common profile libraies which is libgles_cm.lib. So do not put al together in a linkers dependencies.Â
1. What SDK version you have been using? libEGL is independent from libgles_cm and libgles_cl so when it comes to loading some extensions (eglGetProcAdress) then it may be confused. We may look to that later. But for now on do not use them together when linking
2. libgles_cm.lib does not refer to libgles_cl.lib . libgles_cm.dll got a wrapper for libEGL.dll so that is why you need to link only to libgles_cm.Â
