Problems with SDK 3.4

Tagged: 

This topic contains 6 replies, has 2 voices, and was last updated by  chris 2 years, 9 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #31927

    lucera
    Member

    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?

    #39320

    chris
    Moderator

    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);
    }

    #39321

    lucera
    Member

    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!

    #39322

    chris
    Moderator

    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.

    #39323

    lucera
    Member

    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!

    #39324

    lucera
    Member

    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!

    #39325

    chris
    Moderator

    Hi Lucera

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

Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.