Emscripten port

[labsin]

I'll give it a try. I defined _IRR_LINUX_PLATFORM_ because emscripen has good support in mimicking Linux.
Emscripten prefers the webgl subset of gles (that's default). If you want to use the compatibility layer of gles do you can use all functions, you need to set FULL_ES2=1. This needs to be set in the final linking of the HTML/js https://kripken.github.io/emscripten-si ... -emulation
I didn't try it without.

What do you mean with the windows version? I really think emscripten emulates Linux when build on windows. (Haven't tried).

I don't think -lGLESv2 is needed. I just copied it. Emscripten ignores libs it didn't find. I think the gl parts are linked automatically if the lib has unresolved symbols pointing to them.

I'll try sending the result.

[CuteAlien]

Yeah, the question about the compatiblity layer was basically - does Irrlicht need this currently? Because emscripten docs recommended the other one.

Windows version means - when building it on Windows (also still failing there, the VS plugin for emscripten which would make everything super-trivial there unfortunately gives me an error). With VS or MinGW... still have to figure out one of those... but can do later. On Linux I can build by now (my result: http://michaelzeilfelder.de/pub/emscrip ... World.html) - but still fails to run any opengl commands (callstack shows error simply for the first gl command which is run).

[labsin]

On windows the same clang compiler is used to compile CPP to llvm ir (the clang from the emscripten sdk). And fastcomp is the llvm back end of emscripten to compile llvm ir to js/HTML.
VS (or MinGW) is used only to build fastcomp when you install emsdk from source and nothing more.
With the VS plugin it also uses clang and fastcomp. Try to build a CPP file with
#ifdef __unix__
#error "unix"
#endif
It should error. Emscripten should behave like Unix even on windows so far I know.

[CuteAlien]

Yes, the VS plugin is simply to use clang inside VS easier. Which sounded like the easiest solution to test it out (if it had worked). The problem with the other solution on Windows is that I have to create build-environment first. Basically - I have the emmake - but it still needs to call some 'make'. And I don't have that with the default environment coming with the sdk.
So I probably have to get it working inside mingw somehow - which then again means I have to first get the emmake environment working inside MinGW (not tried that one yet - I hope it just needs paths to emmake etc - the shell script coming with the sdk only seems to be for Linux I think). If the VS plugin had worked I wouldn't have needed that. And that creates the next problem then - once inside MinGW I'm not sure anymore if having the _IRR_LINUX_PLATFORM_ will work or not. Maybe will - maybe won't ... will have to see. If I continue to fail to get it working on Debian or inside VS - then that will be my next try to get a working solution I guess. Those 2 approaches just had sounded easier - so I tried them first (but spend over 10 hours on those by now, so likely giving up).

edit: And yeah - could be the _IRR_LINUX_PLATFORM_ can be moved back in the IrrCompileConfig header if it really works just like Linux. Will see - easy change. Hard problem is to get _anything_ working for me so far :-)

[labsin]

I ttied building the HEAD now. When I ran it in Firefox I opened up the developers console (the hotkeys don't work as the emscripten html page grabs all input, you can disable this somewhere tho). It complained about the display not set. The code I added in CEGLManager.cpp for this wasn't patched.
Second problem was that the main loop in the example was still build. emscripten_set_main_loop replaces a while loop in main (with the arguments to 0, it tries to run it at refresh rate)
patch: https://drive.google.com/open?id=0B1eui ... 09fTkVGbHM
html and js tar: https://drive.google.com/open?id=0B1eui ... jJ3LUx2RDg

[CuteAlien]

Thank you so much! Sorry, I really should have gone over patch once more - my fault. Or next time I won't apply it manually and try to figure out what it does afterwards. It works now and I find it incredible: http://www.irrgheist.com/emscripten/exa ... World.html

Minor note - adding CFLAGS to Makefile probably also makes sense. Thought I think it needs the other brackets so I used () instead of {} (really not sure without looking up right now if those also would have worked, but other brackets used for other options).

And I'll move the _IRR_LINUX_PLATFORM_ back to IrrCompileConfig - your explanation that this is really a unix make sense. Will see later when I work on getting Windows verson working again if there are any troubles (shouldn't be). I'll also check what happens with other drivers (console, software) - maybe those should be disabled as well (would make .js a little smaller).

edit: Updated link (my other server has some download limits...), kicked out some media files and release. Already a lot faster.

[labsin]

Yes, I'm not sure at all about the make file.
I had to set the Unicode directive, but it wasn't used when compiling the .d files. I think it has something to do with the .import thing. I have not a lot of experience with editing make files.

Your example also works in the android (chrome) browser.

[LunaRebirth]

Really looking forward to the progress on this.
Way out of my knowledge base at this point, otherwise I'd contribute testing.

[CuteAlien]

Got mouse working. But lots of clipping troubles with more complex example so far: http://www.irrgheist.com/emscripten/exa ... sting.html

[CuteAlien]

I'm currently working on a new driver for WebGL. That allows to run emscripten without the webgl simulation (without -s FULL_ES2=1). Basically idea is to do that simulation inside Irrlicht where we have much better information about buffers (otherwise it constantly binds/unbinds buffers which is really bad for performance). I checked in a first version today - which can already run the HelloWorld and the quake map (interestingly it fixed the clipping errors there). Will add some more stuff to it soon. Thought next job - figuring out why some textures are still black. And why Chrome gives so many warnings/errors (for example when drawing fonts).

edit: Link is updated: http://www.irrgheist.com/emscripten/exa ... sting.html
Note that the "freezing" is caused because the camera hasn't been adapted yet. When you use only keyboard (or move the mouse constantly and only inside the render area) then it should be rather smooth already.

edit2: Hmpf, after a while the clipping errors are back...

[labsin]

Good job.

[CuteAlien]

Phew, got the reason for one warning I'm constantly getting, but not sure about way around it. Warning is:
"RENDER WARNING: there is no texture bound to the unit 0". The problem is we are trying to access texture2D in shaders only when there is a texture set.

Like the following code (for 2d shaders)

cpp Code: Select all

 
precision mediump float;
 /* Uniforms */
 uniform int uTextureUsage;
uniform sampler2D uTextureUnit;
 
/* Varyings */
 varying vec2 vTextureCoord;
varying vec4 vVertexColor;
 
void main()
{
    vec4 Color = vVertexColor;
 
    if (bool(uTextureUsage))
        Color *= texture2D(uTextureUnit, vTextureCoord);
 
    gl_FragColor = Color;
}
 

This should only call texture2D when uTextureUsage is != 0. But... the browser gives me still warnings about an invalid texture unit used in texture2D even if uTextureUsage is 0! I tried ininitializing uTextureUsage to 0 earlier, I checked it it's never set to another value etc - doesn't help. If I call anything else instead of texture2D like setting color to red or so... doesn't happen - so that code is really not used. But I guess for WebGL it's already a problem if that is code which _might_ be used maybe?

Anyone got an idea? I mean I could do 2 different workaround. One would be setting a white texture as placeholder which is send whenever we have no other texture set (relatively easy, thought slightly ugly). Other workaround would be to switch to another shader whenever we have no texture (which would be nice as it's very effective, but needs rather a lot of changes to Irrlicht, so I don't really want to do that right now).

edit: Solved it by splitting the shader for 2d pixel rendering into texture/no_texture versions. For 3d materials the users can do that split in their application.

[CuteAlien]

Demo now working pretty smooth :-) Aside from particles I think most stuff works now (will probably just add a quick hack for those as I don't really need them myself for now).