At one point Emscripten was the hottest thing in the JS world and I decided to try it. I started writing about the experience in this post but the procrastinator in me didn’t finish it. Fortunately, the content went into these slides and gave a talk about it in Feb earlier this year. The slides should cover most of the content here but feel free to read on if you have the time.
I talked about a struggle with Emscripten, on how the going wasn’t easy especially for someone who wasn’t familiar with C. Still various times the idea of using emscripten was incepted (eg. this twitter thread). Among the stuff that I wanted to try porting was GLSL Optimizer. I gave it my first shot and wasn’t successful with that. GLSLOptimizer was also written because HLSL2GLSLfork (for unity3d) generated GLSL code that could be optimized.
Emscripten probably wasn’t the most complex piece of software (besides it have probably been used successfully with millions lines of code) but why did I failed again and again? In retrospective there were a few reasons
1) these projects weren’t trivial
2) my Emscripten environment was probably messed up
3) I wasn’t familiar with C or C++ world (even though I’ve programmed in c and objc)
4) I wasn’t familiar with the build systems automake/make/cmake/premake, its ecosystems and workflows
These factors made it like learning to jump before crawling. So I’d put these on my backburner. Once in a while I try getting my hands dirty again, till I hit another brick-wall. Repeat.
One day I was reading some GLSL code online and I mistaken it as HLSL. Thinking about how to convert it to GLSL, I end up attempting emscripten-ization again. HLSL2GLSL project came to mind but this time found out a new hlsl-to-glsl project, which turns out to be a newer and simpler shader project.
This project uses premake, so I learn about it. I had progress building stuff, and despite some errors, I could fix. I realized that there were also forks of that project (eg. being used by the witness), and I tried those code too. I also figure that premake doesn’t have to be used. I could run a simple compilation command.
/usr/lib/emsdk_portable/emscripten/1.29.0/emcc src/*.cpp -o hello.html -s EXPORTED_FUNCTIONS=”[‘_parseHLSL’]” –bind -O3
There were other pitfalls and lessons learn’t along the way. Especially with how the JS and emscripten are bridged. There were different approaches: CCall could be used, or using marcos, eval and bindings but one have to be careful the datatypes gets converted correctly through the bridge too.
That gave me some experience and confidence boost, and I went on to make glsl-optimizer work. Glsl-optimizer has more code and slightly more complexted, but I follow the previous approach of rolling my own build scripts and and had it work too. See Demo and Code.
There’s one thing I haven’t manage to solve, that is getting data corruption issues using link-time optimizations, so it’d cool if anyone managed to fix that, that would bring down the generated JS even further.
And there’s has been recent update with these projects – Jaume (aka thespite) has attempted integrating GLSL optimizer in his really cool Chrome WebGL Shader Editor extension.
— Jaume Sanchez Elias (@thespite) June 26, 2015
One of the ideas still lingering in my mind would be porting a good sounding midi / wavetable synthesizer like fluidsynth to JS. Stay tuned!