How to use ANGLE library on old machines

Build.xml doesn’t need to be modified. Why do we need to define a macro that is already defined by SDL_config.h?

The crash was easy to fix. Lime was failing to initialize OpenGL bindings because it always uses wglGetProcAddress instead of SDL_GL_GetProcAddress.

HelloWorld example launched, but nothing renders on the screen…

Shaders from HerokuShaders and SimpleImage won’t compile on ANGLE. It seems difficult to get these things work.

I tested again with lasted SDL in https://github.com/spurious/SDL-mirror.
This time HelloWorld and HerokuShaders worked, but without ANGLE.

1 Like

This was because WGL was enabled in config file…
I disabled WGL again, and saw that egl failed to create OpenGL context.

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.

2 Likes

Looks like someone got it working. I wasn’t able to get my shaders working tho, but good to see some progress. Please submit a pull request or something, I can’t wait to see this in future lime build. :stuck_out_tongue:

Heeeeey, neat!!!

Ping @singmajesty @mrcdk

Cool, good job vroad! :smile:

So @vroad – there’s a lot of posts here in your detective work. What’s a minimal set of steps to enable ANGLE?

Ideally, I’d like something that can enable support for ANGLE, but perhaps not force it. Something that would not require a clean rebuild of the sources

However, there’s enough nonsense with certain Windows-supported GPUs (not really Windows’ fault) that I think that rolling out with ANGLE support by default could be ideal, although I’m concerned about always requiring it (like if you wanted a statically linked binary with no extra DLLs)

@vroad super duper excellent job! :smiley: I think I have driver issues with next, because I’m using an old Intel card, but can’t know for sure because even empty apps crash without giving any info.
How much troble would be to upload a compiled example using ANGLE to test if that works?

Never thougth we would have a possible solution so fast =)

Uploaded.
Shaders from HerokuShaders worked on ANGLE with a little modification.

precision highp float;

https://github.com/vroad/lime/tree/enable-angle

HerokuShaders example working on ANGLE:

SDL currently tries to use ANGLE instead if no ES2 extension is found, but could we make this the other way around? (Use WGL instead if no ANGLE dlls are found)

1 Like

Hey there!

I just checked out your lime branch. Since that references your fork of SDL is anything else necessary to test your solution?

Anyways, with just your “enable-angle” lime branch I did this. (In the stock openfl Bunnymark demo folder)

lime rebuild windows
lime test windows

Got crash on start, and this:

Could not create OpenGL context: No OpenGL context has been made current.

My system data in case it’s relevant:

SystemData
{
  OS : Windows 7 SP1
  RAM: 8387064 KB (8 GB)
  CPU: Intel(R) Core(TM)2 Duo CPU     E7400  @ 2.80GHz
  GPU: ATI Radeon HD 4800 Series, driver v. 8.970.100.1100
}

Getting an error with the HerokuShader example

Here’s mine.

Sorry I forgot to include ndll module. I updated HerokuShaders example in Dropbox
Please execute the example from HerokuShaders.bat, not from REPL.
Id you want to run your lime app on ANGLE, make sure to put 3 ANGLE binaries in binary dir.


That’s what “REPL” in the error means…

1 Like

Thank you!!! It runs perfect, well as good as it can. There are some small artifacts, but they are less than in the Dv2 version. In Dv2 some of the examples were just one big artifact, like in the fire example, the result was just an orange screen. I think the frame rate is a little better now but can’t tell because Dv2 is running in neko.
Amazing work, congratulation! it would be awesome if we could build using ANGLE in a simple way, like just adding a set in the project.xml

I think I made enough changes in Lime in order to build lime rebuild windows -clean -DLIME_SDL_ANGLE to enable support, but the trick is having matching DLLs for EGL, D3DCompiler and ANGLE in order to make it work.

I could try updating to a newer dev version of SDL soon, in order to support newer ANGLE binaries, but I figured that I just need the right copies. Perhaps someone could try this with the same binaries used in @vroad’s example?

Great work, BTW, this has been a hard topic to dissect (not a lot of information online) to know exactly what steps to enable it, and I don’t have a machine that lacks the GLES extension, so hard to test :slight_smile:

Works for me!!!

Only glitches I noticed, in the bat file:

>iojs ApplicationMain.js
INFO: WARNING: Ignoring SDL_GL_SetSwapInterval call due to ANGLE bug
INFO: WARNING: Ignoring SDL_GL_SetSwapInterval call due to ANGLE bug

And then the app itself runs great, but there’s a bit of vertical tearing here and there, I wonder if the above bug is interfering with VSYNC timing?

But that’s small potatoes. This is great! I’m going to try to get this set up with a regular lime C++ project now to see if it fixes my OpenGL issues there.