I am working on a framework that uses GL to render special effects with frame buffer objects. But on old machines where drivers are buggy, the application will crash. I have heard that the Chrome browser is using ANGLE for OpenGL compatibility with old hardware by rendering using DirectX. In this thread Application crashes on Intel GMA 3150 I have also heard that it is possible to include ANGLE in OpenFL project.
I would like to know the steps to include ANGLE and to enable it. I am also wondering if it is possible to detect when the hardware OpenGL version is low, and manually switch to OpenGL ES mode instead of hard coding it before running the application.
If we can sort it out for SDL2, that gives us support in Lime 2, which can then be used with the newer OpenFL code, or with the new -Dhybrid system I made, which uses Lime 2 underneath OpenFL legacy
We might consider enabling it for all Windows builds. This would help with older system support, as well as better support on some graphics cards (which otherwise do support GL2 features). The difficulty is that SDL2 will enable a GLES context on newer cards that support it without going through ANGLE. I have one of those cards, so I might not be able to test if ANGLE is working
Subscribe to the topic.
Maybe even better option would be setting like -Dangle (and more simple for implement), which will just make builds with ANGLE renderer only.
Since ANGLE is a library for old hardware compatibility, I suspect using it on newer hardware will causes unnecessary limitations. Also since SDL2 will choose ANGLE only when a GL ES context is not supported, there is no way and no reason to force the usage.
I just realized that even my laptop (with the Intel GPU) has support for the OpenGL ES 2 context, so it does not use ANGLE. However, I think I got it to use the ES context properly.
If you would not mind, try editing “lime/project/Build.xml”, at around line 139 (in the if=“LIME_SDL” section) add this define:
I believe this causes SDL2 to create an OpenGL ES context. If your GPU does not support WGL_EXT_create_context_es2_profile then it should look for ANGLE.
If it succeeds (and you do not have the extension) then it should not run, probably, perhaps with an error about not finding those additional DLL files. Then you could try copying those files into the same directory as the executable. If all goes well, we’ll know this is working and can include those DLL files in the Windows project template by default
Roger that. What are the steps for testing on lime legacy? There is only if=“LEGACY_SDL1” and if=“LEGACY_SDL2” sections in legacy build.xml, and apparently legacy does not have project/src/backend folder.
Alrighty, here’s some changes I made, recording them here for now as I’m not good at working with git submodules. This was in standard/next, for the record:
lime\project\src\backend\sdl\SDLWindow.cpp:
Line 24, inserted:
I think the key is for us to find the correct version of ANGLE that matches what SDL expects, or there’s a possibility that ANGLE just is not happy about something in how the rendering is done. Perhaps we could try the SimpleOpenGLView or something like that, which might demand less (or even better, the Lime HelloWorld sample)
Another possibility is updating to a newer source version of SDL, which I believe was updated to work with newer versions of ANGLE, which may work better
SDL’s testgles2 works even with ANGLE so there should be something wrong in Lime… But I’m not sure what we are missing. Should we create OpenGL context without using SDL’s Renderer?
It finally worked! I should have compiled lime with “-DDYNAMIC_OGL” to dynamically load basic OpenGL functions like glClear from libGLESv2.dll.
If you disable WGL in SDL_config.h, SDL does not look for WGL_EXT_create_context_es2_profile extension since it cannot create WGL context without that. So you can always use ANGLE if you want.
