How to use ANGLE library on old machines

Haxe
#21

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:

#22

Heeeeey, neat!!!

Ping @singmajesty @mrcdk

#23

Cool, good job vroad! :smile:

#24

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

#25

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)

#26

@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 =)

#27

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
#28

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
}
#29

Getting an error with the HerokuShader example

#30

Here’s mine.

#31

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
#32

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

Windows Phone development
#33

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:

#34

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.

#35

It worked on current dev version. ANGLE DLLs are from Chrome 42.0.2311.135. My machine has that GLES extension too, but SDL simply cannot use it if you disable WGL in SDL_config.h.
So I could test this on my machine.

I looked into your commits and noticed that SDLRenderer.cpp is not modified, but SDL_VIDEO_RENDER_OGL is not enabled in NATIVE_TOOLKIT_SDL_ANGLE configuration. Then it will not work…

SDL_CreateRenderer may create renderer implemented on Direct3D, If you haven’t disabled Direct3D renderer in SDL_config.h.
For projects like lime, which directly deals with OpenGL API, I think it would make more sense to create OpenGL context directly with SDL_GL_CreateContext, and returns handle to Haxe side.
In that way, we could support multiple OpenGL contexts by creating contexts without window, but this is another issue.

https://wiki.libsdl.org/SDL_GL_CreateContext

#36

Readme of SDL says that SDL_GL_SetSwapInterval has bug.
On machine, I didn’t notice tearing without vsync, since desktop composition is always enabled on Windows8.1.
https://hg.libsdl.org/SDL/file/4bab88dd387e/docs/README-windows.md

Actually I tried enabling SDL_GL_SetSwapInterval. On my machine HerokuShaders example still works, but fps dropped to around 30fps on Intel GPU, as I reported here…

Maybe we should use DwmFlush in window mode. If desktop composition is disabled, or get disabled while app is running for some reason, then give up using vsync.

#37

To be clear, the 3 ANGLE binaries are these ones?

  • d3dcompiler_47.dll
  • libegl.dll
  • libglesv2.dll

UPDATE:

@singmajesty, using your latest instructions these are the results I get with bunnymark.

  1. Recompile lime using lime build windows -clean -DLIME_SDL_ANGLE
  2. Create bunnymark sample, compile using lime build windows
  3. Go to binary folder and copy in the 3 dll’s listed above
  4. Run the application.

Results:

Could not create SDL renderer: Couldn’t find matching render driver.
Shader.hx:141:
Shader.hx:141:
Shader.hx:141:
Shader.hx:141:
Shader.hx:141:
Shader.hx:141:
Shader.hx:141:
Shader.hx:141:
Shader.hx:141:
Shader.hx:141:

And a window with no visual output (not a black screen even, just shows what was behind the window originally in a glitchy, this-programs-visuals-don’t-work kinda way). Doesn’t crash, but doesn’t do anything until I close it.

So maybe we need to make the tweaks Vroad noted?

#38

Do you think I need to tweak the native toolkit ANGLE configuration more, or is there something else that should be done in order to handle ANGLE, without dropping the SDL renderer?

Since I only use SDL renderer to create our context, I understand, it might make more sense (long-term) to create the context directly. However, I do like that the renderer can create a new context for us automatically, and I believe there are somewhat different implementations of the renderer based on the target platform, all of this is good for us to limit the amount liability we have

#39

Okay, in Slack chat Josh suggested I make these edits to the ANGLE block in lime\project\lib\sdl\include\configs\windows\SDL_config.h:

#else

/* Enable OpenGL support (ES2/ANGLE) */
#ifndef SDL_VIDEO_OPENGL
#define SDL_VIDEO_OPENGL    1
#endif
#ifndef SDL_VIDEO_OPENGL_WGL
#define SDL_VIDEO_OPENGL_WGL    0
#endif
#ifndef SDL_VIDEO_RENDER_OGL
#define SDL_VIDEO_RENDER_OGL    0
#endif
#ifndef SDL_VIDEO_RENDER_OGL_ES2
#define SDL_VIDEO_RENDER_OGL_ES2    1
#endif
#ifndef SDL_VIDEO_OPENGL_ES2
#define SDL_VIDEO_OPENGL_ES2    1
#endif
#ifndef SDL_VIDEO_OPENGL_EGL
#define SDL_VIDEO_OPENGL_EGL    1
#endif

#endif

Did that.

  1. Ran lime rebuild windows -clean -DLIME_SDL_ANGLE
  2. Ran lime test windows
  3. (I had already copied the dll’s to the binary folder)
  4. Get these results:

ANGLE WORKS!!!

Previously when using Next, the background would NOT render properly. I’d get bunnies, pirate, and text, but no fancy 3D grass background. I also get the same SDL_GL_SeInterval notification so I know it really is ANGLE that is running.

#40

Doing some quick Bunnymark benchmarks gets about the same results for me, with OpenGL being slightly faster than ANGLE. I re-ran the tests with the background disabled and got about the same results. OpenGL slightly ahead, no clear winner as there seems to be some random perturbation in the benchmark results between runs. Not an exhaustive benchmark, could be smart to run a fancier test.