Emscripten and OpenGL versions

[Michael IV]

I am desktop OpenGL developer and I wonder what's the best way for me to port or write OpenGL so that it will be best compatible with WebGL .I read in Emscripten FAQ that using SDK included ES2 API is the besr choice.But I also see some of the examples use regular OpenGL .For me ,in terms of portability and usability would be best to write a normal OpenGL ,using GLEW headers.Will it be fine as long as I use only ES2 compatible API methods?

[Jukka Jylänki]

In terms of features, pretty much WebGL is a subset of GLES2, which is a subset of modern desktop GL. Sticking to the lowest common denomination and basically writing "GLES2 without client-side rendering" gives you a good sane common ground that works across all platforms. This means not using any of the old desktop GL features such as fixed function rendering, glBegin, glVertexPointer/glColorPointer etc. Also note that the extension registryes are different for each GL, GLES and WebGL, although generally matchable. If you also want to target desktop core GL3, that's also possible, but one inconvenience there is that you need to maintain (or translate one to other - that's what I do) two sets of GLSL shader syntax. If you are working on a renderer codebase from scratch, it is best to avoid the FULL_ES2 and LEGACY_GL_EMULATION settings, which gives the best path.

Jukka

On Mar 8, 2014 4:42 PM, "Michael IV" <explo...@gmail.com> wrote:

I am desktop OpenGL developer and I wonder what's the best way for me to port or write OpenGL so that it will be best compatible with WebGL .I read in Emscripten FAQ that using SDK included ES2 API is the besr choice.But I also see some of the examples use regular OpenGL .For me ,in terms of portability and usability would be best to write a normal OpenGL ,using GLEW headers.Will it be fine as long as I use only ES2 compatible API methods?

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael IV]

Ok,so let me see if I get you right.I can basically use GLEW with GL 3.0 - GL 3.2 core profile and it will be translated ok (except of GLSL compat issues) to WebGL?Also,in terms of context creation,I see I can use GLFW or GLUT ? 

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/ZMC4l8ppDq8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Michael Ivanov

Independent Pixel Commander 
onlygraphix.com
Tel:+972 54 4962254

[Michael IV]

Btw,I see tests folder has a lot of demos with fixed pipeline stuff which compile but don't work.Why those demos are there?

[Jukka Jylänki]

Yeah, if you use GL 3 core on desktop, you'll be fairly good to go. The shader syntax translation issue is a bit annoying, e.g. in core GL3 the GLSL syntax uses the keywords in and out, whereas GLES2/WebGL still uses the old keywords attribute and varying. There are a few other syntax renames like this. What I do is I author my shaders in the old GLES2 syntax, and then when building for desktop, just use naive string replaces at startup time to convert the shaders so they pass in core GL3. Also, using VAOs is not required in GLES2 and WebGL, but it is mandatory in GL3.

But these are GLES2 vs desktop GL differences, and not Emscripten-specific differences. See the WebGL specification for WebGL vs GLES2 differences. The most notable one is the lack of client side rendering, which engines wouldn't want to use anyways.

[Michael IV]

"Client side lack..."  - good !  I just tried to use GLFW3 for context setup ,the emscripten compiled but nothing show up.Is it correct to assume it is not yet supported in the SDK?GLFW is useful as it can also create ES context.

[Michael IV]

For example  tried with the old GLFW (2.7) the following:

//========================================================================

// This is a small test application for GLFW.

// The program opens a window (640x480), and renders a spinning colored

// triangle (it is controlled with both the GLFW timer and the mouse). It

// also calculates the rendering speed (FPS), which is displayed in the

// window title bar.

//========================================================================

#include <stdio.h>

#include <stdlib.h>

#include <GL/glfw.h>

#include <emscripten/emscripten.h>

//========================================================================

// main()

//========================================================================

int main( void )

{

    int     width, height, running, x;

    double  t;

    // Initialise GLFW

    if( !glfwInit() )

    {

        fprintf( stderr, "Failed to initialize GLFW\n" );

        exit( EXIT_FAILURE );

    }

    // Open OpenGL window

    if( !glfwOpenWindow( 640, 480, 0,0,0,0, 0,0, GLFW_WINDOW ) )

    {

        fprintf( stderr, "Failed to open GLFW window\n" );

        glfwTerminate();

        exit( EXIT_FAILURE );

    }

    glfwSetWindowTitle( "Spinning Triangle" );

  

    // Enable vertical sync (on cards that support it)

    glfwSwapInterval( 1 );

    // Main loop

    running = GL_TRUE;

    while( running )

    {

        // Get time and mouse position

        t = glfwGetTime();

        glfwGetMousePos( &x, NULL );

        // Get window size (may be different than the requested size)

        glfwGetWindowSize( &width, &height );

        height = height > 0 ? height : 1;

        // Set viewport

        glViewport( 0, 0, width, height );

        // Clear color buffer

        glClearColor( 1.0f, 0.0f, 0.0f, 0.0f );

        glClear( GL_COLOR_BUFFER_BIT );

      

        // Swap buffers

        glfwSwapBuffers();

        // Check if the ESC key was pressed or the window was closed

        running = !glfwGetKey( GLFW_KEY_ESC ) &&

                  glfwGetWindowParam( GLFW_OPENED );

    }

    // Close OpenGL window and terminate GLFW

    glfwTerminate();

    exit( EXIT_SUCCESS );

}

THe generated HTML shows only Emscripten GUI with "Running..." notification.

[Jukka Jylänki]

Check the browser console for any errors. I'm not sure how complete the GLEW/GLFW support in Emscripten is, there may be some work to do for some use cases.

One thing I note in your demo is that it hosts its own blocking main loop. That is not allowed in JavaScript, as JS scripts cannot run infinitely without ever yielding control back to the browser. You will need to use emscripten_set_main_loop() to register a callback function that runs one tick of your event loop, and return from main() afterwards, so that the browser main loop can kick in. This is one of the things that require careful architecting between native and web - in general no blocking synchronous operations are possible, but everything "OS-level" (file io, network requests, sleeping/waiting) must be asynchronous. Try refactoring the code sample so that it utilizes emscripten_set_main_loop() and avoids a blocking loop.

[Michael IV]

OK, gonna try it as it really looks like the app  is being suspended in an infinite loop.

[Mark Callow]

On 2014/03/09 0:53, Jukka Jylänki wrote:

There are a few other syntax renames like this. What I do is I author my shaders in the old GLES2 syntax, and then when building for desktop, just use naive string replaces at startup time to convert the shaders so they pass in core GL3. Also, using VAOs is not required in GLES2 and WebGL, but it is mandatory in GL3.

If the desktop GL you are running on supports one of the ARB_ES[23]_compatibility extensions, which is quite common, you can use #version 100 (GLSL ES 1.00) shaders. Just make sure the first line is "#version 100".

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.