Problems with SDK 3.4

PowerVR Insider
1

Hi,



recently I updated from SDK 3.1 to SDK 3.4 and I have two problems with my tests using OpenGL ES 1 (Note that all works fine with SDK 3.1)

(I’m using Windows 8.1 with Visual Studio 2012).



The problems are:



1.- I can’t link a program if it uses functions in glext.h like glBlendEquationOES because in SDK 3.1 the link names related were:



Import _glBlendEquationOES@4 from libGLES_CM.dll

Import _glBlendEquationSeparateOES@8 from libGLES_CM.dll



and now the link names related are:



Import ?glBlendEquationEXT@@YGXI@Z from libGLES_CM.dll

Import ?glBlendEquationOES@@YGXI@Z from libGLES_CM.dll

Import ?glBlendEquationSeparateOES@@YGXII@Z from libGLES_CM.dll



As the names are differents we can’t link.





2.- The program crash if it links (when it doesn’t use any function in glext.h) (OpenGL ES 1 too)



If I put the old DLLs the program works correctly. It seems that the problem is something related when libGLES_CM.dll tries to use libEGL.dll.





All works fine with OpenGL ES 2+ (when using libGLESv2.dll and libEGL.dll).



Any clue?

2

Hi Lucera



I believe in SDK 3.1 we were incorrectly exporting those symbols allowing you to use the function prototypes in glext.h. The correct way to use these extensions is to instead check and load the functions at runtime using something like:



PFNGLBLENDEQUATIONOESPROC glBlendEquationOES = 0;



// check that the extension is available

if(strcmp((char*)(glGetString(GL_EXTENSIONS)), “GL_OES_blend_subtract”) == 0)

{

glBlendEquationOES = eglGetProcAddress(“glBlendEquationOES”);

}

else

{

// extension is not supported

}



…



if(glBlendEquationOES)

{

glBlendEquationOES(GL_FUNC_ADD);

}

3

Indeed, we are defining GL_GLEXT_PROTOTYPES before including GLES / glext.h.



Under Windows/MacOS X/linux we are using the glew library (http://glew.sourceforge.net/) precisely to not to have to do the load of every function. And to not to have to know which extensions you need to check to be able to use each function (it is a bit cumbersome).



In any case, this solves the first problem. What about the second problem? Program crash on load when libGLES_CM.dll tries to use libEGL.dll.



Thanks!

4

Are you able to reproduce this crash by running one of the examples provided in the SDK, or does it only occur in your program?



Does it crash during program initialization or inside an EGL function? GLES_CM exposes the EGL interface so on startup it will load EGL.dll and acquire pointers to the EGL functions, but it won’t try to use them until an EGL function is called by the application.

5

Ok, it was another incompatibility with SDK 3.1 / improvement respect to SDK 3.1.



In the old SDK seems that EGL_RENDERABLE_TYPE was not checked and the new SDK is more strict. I prefer it.



Thanks for your help!


6

Hi Chris,



I get another issue with SDK 3.4.



When I try to use glColor4ub the color is always black but all works ok using glColor4f.



Try it in your sample OGLESHelloAPI: OGLESHelloAPI_Windows.cpp line 468

change glColor4f(1.0f, 1.0f, 0.66, 1.0f); by glColor4ub(0xff, 0xff, 0xa8, 0xff);



Thanks!

7

Hi Lucera



Thanks for reporting that. I will file a bug report and get it fixed for the next release.