Thank you so much Floh that was super helpful. I was able to get the OpenGL and SDL to work together.
If you don't mind me asking, what library are you using to load images for OpenGL? Thanks again, Rick On Saturday, April 6, 2019 at 5:01:19 AM UTC-6, Floh wrote: > > I'm not too familiar with the internal details, so take it with a grain of > salt :) > > First, WASM has a function import table which maps Javascript function > names and a 'call signature' to a function index (a number, basically). > When compiling with debug info (-g), one can inspect this import table in > Firefox, the import entry for glClearColor looks like this for instance: > > (import "env" "_glClearColor" (func $_glClearColor (;61;) (param f64 f64 > f64 f64))) > > This basically says that there's a Javascript function which takes 4 > float64 arguments. There's a WASM 'call' instruction, for instance: > > get_local $var188 > f64.promote/f32 > get_local $var189 > f64.promote/f32 > get_local $var190 > f64.promote/f32 > get_local $var185 > f64.promote/f32 > call $_glClearColor > > This is basically a foreign-function-interface call which puts four > float64 values on the "argument stack" and calls the external _glClearColor > Javascript function. > > This WASM code is generated from the C code in here: > https://github.com/emscripten-core/emscripten/blob/incoming/system/lib/gl/webgl1.c > > ...now on the Javascript side, it's a bit more non-obvious, the > interesting bits are in here: > > > https://github.com/emscripten-core/emscripten/blob/incoming/src/library_webgl.js > > glClearColor is treated as a simple "pass-through function" because it > just has 4 floating point parameters, no GL object handles that need to be > mapped to Javascript objects. The 'forwarding code' for this seems to be > code-generated here: > > > https://github.com/emscripten-core/emscripten/blob/b9499bd139f720349844d0af5fd0394df1b78dd9/src/library_webgl.js#L3507-L3537 > > But again, debug mode to the rescue, the generated JS code can be > inspected in the browser by searching in the application's .js file: > > function _glClearColor(x0, x1, x2, x3) { GLctx['clearColor'](x0, x1, x2, > x3) } > > GLctx is the WebGL context, so that's the same as: > > function _glClearColor(x0, x1, x2, x3) { GLctx.clearColor(x0, x1, x2, x3); > } > > (I'm not sure why the function code isn't generated like this, but I guess > there's a reason). > > So basically: > > - for each GL call, a small JS proxy function exists which forwards the > call to the WebGL context object > - each Javascript proxy function is made available to WASM code through > the imports-table > - WASM code calls the JS proxy function though a 'foreign function > interface' implemented by the WASM runtime in the browser > > Cheers, > -Floh > > On Friday, 5 April 2019 22:47:32 UTC+2, Rick Battagline wrote: >> >> Thanks Floh, >> >> I've been looking through that code. I'm still trying to figure out how >> exactly the calls go back and forth. It kind of looks to me like there is >> an array of calls that somehow get triggered, but I'm not completely sure >> that's the way to work. How exactly do WebAssembly calls to OpenGL get >> translated into JavaScript WebGL calls? I'm still rather unclear on that. >> >> Thanks again, >> Rick >> >> On Wednesday, April 3, 2019 at 5:13:35 AM UTC-6, Floh wrote: >>> >>> It seems the GL wrapper implementation has changed a lot quite recently. >>> From my (external) pov it seems to work like this now: >>> >>> There's a C part here: >>> https://github.com/emscripten-core/emscripten/tree/incoming/system/lib/gl >>> >>> ...which looks like it's just a library of slim C proxy functions which >>> forward the GL calls to the Javascript side for different scenarios (e.g. >>> GL code running on the main thread or not). >>> >>> The actually interesting stuff happens in JS code here: >>> >>> >>> https://github.com/emscripten-core/emscripten/blob/incoming/src/library_webgl.js >>> >>> https://github.com/emscripten-core/emscripten/blob/incoming/src/library_webgl2.js >>> >>> https://github.com/emscripten-core/emscripten/blob/incoming/src/library_glemu.js >>> >>> This basically emulates GLES2, GLES3 or desktop GL on top of WebGL or >>> WebGL2 (at the very least this must map GL object handles which are >>> GLuint's in C code to Javascript objects, but there's a lot more stuff >>> going on which I haven't looked at in detail). >>> >>> A while ago all this was in a single library_gl.js source file, but I >>> think conceptually this did the same. >>> >>> I have no clue about the SDL vs GL problems you're seeing unfortunately, >>> my code uses the emscripten_webgl_*() functions for context setup. >>> >>> Cheers! >>> >>> On Tuesday, 2 April 2019 22:59:39 UTC+2, Rick Battagline wrote: >>>> >>>> Hi, >>>> >>>> I've been having some problems mixing SDL and OpenGL. Changing the >>>> shaders using calls to OpenGL seems to be creating problems with SDL. I'm >>>> trying to figure out how the Emscripten port of OpenGL works. Looking >>>> through some of the glue code it looks like there is some webgl code that >>>> I >>>> assume is being called from the WebAssembly. >>>> >>>> Does anyone know how the Emscripten implementation of OpenGL works? >>>> >>>> Where can I find the code for the OpenGL Emscripten implementation? >>>> >>>> Thanks >>>> >>> -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
