I recently succeeded in porting CEGUI to asm.js via emscripten. This means that it can be used in games and applications that run in your browser without requiring any installations of plugins or external dependencies, as long as you use a recent version of i.e. Chrome / IE / Firefox / Safari / Opera which supports WebGL.

Also if you encounter problems please post here about them! Thank you.

~iceiceice~

Edit:

Also, note that this project entailed porting the CEGUI OpenGL3 renderer so that it works with OpenGLES2. So you might be interested in this project also if you want to use CEGUI in projects targetting phones and tablets.

Yeah it should be possible. I have not looked at the default branch, I don't know how much changed. But it was really pretty minor.

The main changes I had to make (iirc) were

- Vertex array objects are an extension in opengles2. I assume that it is present, since I guess it usually is, but probably should check for it somehow.- I didn't figure out about the compressed texture loading, I don't know if that is present, in my version I disabled it I think. Possibly it works? I don't know much about GLEW so I just commented out all that stuff...- WebGL has some restrictions about using non-power of two textures. When I first started I only got a black screen and a bunch of these messages in console:

Error: WebGL: A texture is going to be rendered as if it were black, as per the OpenGL ES 2.0.24 spec section 3.8.2, because it is a 2D texture, with a minification filter not requiring a mipmap, with its width or height not a power of two, and with a wrap mode different from CLAMP_TO_EDGE.

I put calls to this function at times when textures were being created, and that seemed to fix it.

- I had to comment out the "blit_to_memory" function in Texture.cpp, which returns texture memory from opengl to the cpu, because that doesn't exist really in opengles2 as far as I know. There might be some work around? http://stackoverflow.com/questions/3981 ... mbedded-pl

It seems that this feature is not really needed by cegui, at least as far as I can tell. So I'm not sure if it's worth it to try to implement a workaround?

I don't think I had to change anything else really. Does default branch use any fancy blending / clamp modes incompatible with the above?

As far as I see, this is a non-essential feature. It "can" be useful at times but since it is not crucial I would say feel free to leave it unimplemented in the way done in GLES renderer.

It is a shame that VAOs (vertex array objects) are not available in OpenGL ES 2.X, and only became core in 3.X. I wasn't aware of this. It is possible to just work with vbo's but this requires more calls and subsequently more state changes. Probably it would be best to work with vbo#s rather than the extension, but raising an exception when the extension is not available would be a sufficient solution for your current implementation

"Probably it would be best to work with vbo#s rather than the extension, but raising an exception when the extension is not available would be a sufficient solution for your current implementation"

Yeah that's what I was thinking also. It might not be infeasable make a VBO-only code path but I don't feel compelled to right now. VAOs are really nice and will probably be supported on most devices looking into the future.

VAOs are definitely the way to go. Also soon there will be Vulkan and all of this will likely become redundant and can be done in a single Renderer for all platforms. So I agree with what you said, the only issue is how to find out if the extension is available. Afaik GLEW has a function for this. But didn you say you commented out all glew code?

Yeah I think I didn't actually need to do that. When I started I really had no idea if this would work so if i saw stuff I was unsure about I tended to comment it out so that I would find the "real problems" faster. But I think emscripten does have glew headers?

I'm tempted to do something like, make GLEW an optional dependency at compile time, and if it isn't there, then disable compressed textures and also assume that you have VAO extension (since we have no fallback if you don't?)

For the VAO thing, the only purpose of glew would be to give a nicer error message when we can't run on some machine, so I'm reluctant to add a mandatory dependency just for that.

FWIW, I looked into how available this extension (OES_vertex_array_object) is in WebGL. It looks that it was "promoted to core" in WebGL 2.0, so I think that means that any WebGL 2.0 capable browser has it?

So one thing to note (I have learned much about emscripten since making this project) is that the version that is linked above, is compiled *without* support for C++ exceptions. In emscripten you must manually enable support for these. In many games, they are simply never used, and it is apparently somewhat difficult for them to simulate exceptions in javascript in a satisfactorily performant way. This means that whenever CEGUI throws an exception in that page that you see, the program is terminated. (Because it does not generate any catch blocks.)

I could turn on the flag to support exceptions, I don't think it would go much slower. That would probably be a more faithful representation of the samples browser.

The other reason I didn't update, I am planning to try to get it to work using lib epoxy, like was demonstrated in an awesome recent patch by YaronCT. (And slated to be a part of CEGUI 0.8.5) However I'm not completely certain if emscripten has been used successfuly with lib epoxy, and digging into that could take me some time. With glew, emscripten seems to provide some built in support, and I don't see the equivalent for epoxy -- it's possible though that epoxy doesn't actually need such support. I will get around to investigating it thoroughly