Comment by scrame | Hacker News Reader

Comment by scrame | Hacker News Reader

So, I understand that asm.js is a strict subset of JS that's made to run very efficiently. I understand emscripten can transpile C to asm.js, so C programs to run in a browser.

I guess what I don't understand is how the higher-level bindings work. Something like the neo-geo emulators running in asm.js can read controllers and output graphics. How much custom code is required going from system C to browser JS. Is it closer to a 'gimme' if it targets GL and can just use WebGL? Is there something like sdl.js? And if it has those external library dependencies, does the whole dependency tree have to be compiled to asm.js?

More specifically, if the lua VM can be put into the browser, and interpret lua code, then how much custom code would it take to make Love2D work?

Edit: Just re-reading this question I realized it'd most likely be like a static build, so it would pull in the dependency source, and then most likely something that would use the io/display stuff API, but with a browser back-end. I've dug around a couple times trying to find a basic overview of that, but to not much avail. I'd love any references though.

Emscripten[1] comes with SDL support (cf its test suite [2]). Not sure how complete it is.

[1] http://kripken.github.io/emscripten-site/

[2] https://github.com/kripken/emscripten/blob/master/tests/hell...

The original SDL support was a JavaScript implementation of just enough of 1.x to get things compiling.

SDL2 cross-compiles to JavaScript properly and should be used by most things now.

so emscripten provides the sdl binding? I was assuming it'd cover libc, but does that mean it's part of the ecosystem or the compiler?

I feel like I'm just asking dumb toolchain questions because I'm missing something fundamental about targeting an executable build to the browser.

I think this is what you are missing.

https://kripken.github.io/emscripten-site/docs/porting/conne...

Emscripten also allows access to WebGL, which is pretty neat. I'm writing (and selling, you should check out https://info-beamer.com/pi) a software to make it easy to build animated information screens. I'm also embedding Lua to make everything scriptable. As a proof of concept I cross-compiled the existing open source software (https://github.com/dividuum/info-beamer) to JS with emscripten two years ago. Here's the demo site: https://dividuum.de/experiments/info-beamer-js/. What you see is a C program with an embedded Lua VM running very simple Lua code (https://github.com/dividuum/info-beamer/blob/master/samples/...) to transform a loaded PNG image through a GLSL in a WebGL context. It's pretty amazing that these things are possible. I'm also pretty sure a lot has improved in emscripten since then. Maybe I should give that another try...

There are several approaches in emscripten to talk to the JS/HTML5 side from the C/C++ side:

1) wrappers for popular native APIs and frameworks to simplify porting existing code: apart from the 'expected' C and C++ runtime wrappers, emscripten also offers wrappers for GL, GLES 1..3, EGL, GLFW, GLU, GLUT, GLEW, SDL and OpenAL, these generally translate (and sometimes emulate) the behaviour of the native APIs to the underlying HTML5 APIs (e.g. GL to WebGL, SDL Audio and OpenAL to WebAudio, etc...)

2) there are also smaller emscripten-specific APIs that are essentially minimal shims around HTML5 APIs, for instance to initialize a WebGL context, one could either use the EGL or SDL wrappers which add some code bloat and don't directly map to WebGL initialization attributes, or one can use the emscripten_webgl_*() functions which map directly to the WebGL context initialization process, there are also similar small shims for input, XMLHttpRequest, WebWorkers and others, the advantage of these direct HTML5 shims is that they introduce less code bloat, but they don't exist anywhere outside the emscripten platform

3) emscripten also provides a number of different ways to easily write your own shims to call from C/C++ into JS, and the other way around, even with marshalling complex C++ data types (see: https://kripken.github.io/emscripten-site/docs/porting/conne...)

I really like that emscripten is much more than just a compiler toolchain with C/C++ runtime, there has been a tremendous amount of work to make it as simple as possible to port existing code over without or just minimal changes!

Thank you! That clears it up. I wasn't getting that it had the whole run-time with it, and that it was so extensive.

I have naïver questions:

taking this port of GNUnet[1] to Javascript through emscripten, where does the GNUnet code ends and where does JS starts? What functions are exported by the GNUnet code? In this case, Clojurescript is used, but I suppose I could reuse the "ported C" part and write my own pure-Javascript app on top of it, right? How difficult is that?

[1]: https://github.com/amatus/gnunet-web

> .. how much custom code would it take to make Love2D work?

Someone is working on it:

http://tannerrogalsky.com/mrrescue/

https://github.com/TannerRogalsky/love.js

Basically emscripten provides a set of libraries that emulate C libraries in Javascript. For example you can use the standard Berkeley socket API, but it actually translates TCP and UDP into SCTP (which can support TCP-like and UDP-like modes) via WebRTC's DataChannel.

Similarly, emscripten provides a standard C OpenGL API, but it actually translates those calls to WebGL Javascript calls.

Reply on news.ycombinator.com