CEGUI in your web browser (as javascript !)

[iceiceice]

Dear Forum,

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.

I have posted online a build of the samples framework from v0-8 branch here: http://cbeck88.github.io/cegui-emscripten/
You can also browse the whole project on github.

Enjoy!

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.

[Ident]

Really amazing work! I didn't think this was even possible.

Would it make sense to integrate the OpenGL ES2 changes into CEGUI codebase somehow?

[iceiceice]

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:

Code: Select all

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.

Code: Select all

void OpenGLTexture::set_standard_tex_params()
{
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
}


- For a while I had sort of botched up headers because of difficulties getting the VAO extension to be defined, although actually I figured it out now... going to fix on the repo...

Code: Select all

#include <GLES2/gl2.h>
#define GL_GLEXT_PROTOTYPES
#include <GLES2/gl2ext.h>


- 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?

[iceiceice]

ok, looking in v0-8 now, it looks like the current OpenGLES renderer also didn't implement the "blitToMemory" stuff:

Code: Select all

void OpenGLESTexture::grabTexture()
{
    CEGUI_THROW(RendererException("unimplemented!"));
}


[Ident]

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

[iceiceice]

This link suggests that many devices have the VAO extension available: http://stackoverflow.com/questions/3040 ... -opengl-es

"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.

[Ident]

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?

[iceiceice]

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.

[Ident]

Sounds good to me

[iceiceice]

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?

https://www.khronos.org/registry/webgl/ ... ay_object/

:hmm:

[Ident]

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?

Correct.

[agge92]

Bugs:
- CEGUIEditboxValidationDemo: Keyboard input doesn't work.
- CEGUIWidgetDemo:
- AlfiscoSkin:
- Editbox: Shift + Key doesn't work.
- ImageButton: There are no image rendered.(Invalidated(WindowEvent))
- MenuWindow: Doesn't render nothing.
- VerticalScrollBar: Doesn't render correctly and up and down scroll is too much sensitive, at the first scroll it goes down immediately.
- Generic:
- Image and ImageButton: Nothing is rendered.
- HUDDemo:
- PopupLabel: Don't work.
- OgreTray:
- ListHeader: Everything freeze/unresponsive.
- MultiColumnList: Everything freeze/unresponsive.
- PopupMenu: Nothing is rendered.
- ScrollablePane: Nothing is rendered.
- TabButton && TabButtonPane && TabContentPane && TabControl: Nothing is rendered.
- Tooltip: Nothing is rendered.
- TaharezLook:
- ComboDropList: Nothing is rendered.
- ImageButton: Nothing is rendered.
- InventoryItem: Nothing is rendered.
- ListHeader: Total freeze.
- MultiColumnList: Total freeze.
- PopupMenu: Nothing is rendered.
- ProgressBar: Malfunctioning rendering.
- ScrollablePane: Nothing is rendered.
- SliderThumb: Nothing is rendered.
- TabButton && TabButtonPane && TabContentPane && TabControl: Nothing or wrongly is rendered.
- Tooltip: Nothing is rendered.
- Tree: Nothing is rendered.
- Vanilla:
- ComboDropList: Nothing is rendered.
- Tooltip: Nothing is rendered.
- WindowsLook: Same as Vanilla +
- IconButton: Nothing is rendered.
- ItemListbox: Nothing is rendered.
- ListHeader: Total freeze.
- ListHeaderSegment: Nothing is rendered.
- ListboxItem: Nothing is rendered.
- MenuItem: Nothing is rendered.
- MultiColumnList: Total freeze.
- PopupMenu: Nothing is rendered.
- ScrollablePane: Nothing is rendered.
- Slider: Malfunctioning and wrongly rendered.
- SliderThumb: Nothing is rendered.
- SystemButton: Nothing is rendered.

[Smi]

Very nice port! The exception related to MultiColumnList is this:

CEGUI::InvalidRequestException in function 'virtual typename Helper::safe_method_return_type CEGUI::TypedProperty<std::__1::basic_string<char> >::getNative(const CEGUI::PropertyReceiver *) const [T = std::__1::basic_string<char>]' (/home/chris/cegui-emscripten/lib/cegui/include/CEGUI/TypedProperty.h:96) : Property CEGUI/MultiColumnList:ColumnHeader is not readable!

and ListHeader:

CEGUI::InvalidRequestException in function 'CEGUI::ListHeaderSegment &CEGUI::ListHeader::getSortSegment() const' (/home/chris/cegui-emscripten/lib/cegui/src/widgets/ListHeader.cpp:154) : Sort segment was invalid! (No segments are attached to the ListHeader?)

both followed by message of the form:

uncaught exception: 105704600 - Exception catching is disabled, this exception cannot be caught. Compile with -s DISABLE_EXCEPTION_CATCHING=0 or DISABLE_EXCEPTION_CATCHING=2 to catch.

In CEGUIEditboxValidationDemo, keyboard input works for me.

[iceiceice]

Hi guys,

Thanks for the feedback.

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

[Ident]

Cool, thanks for the update!