WebGL build instruction doesn't seem to work

[bbarker]

The instructions in the .html files don't seem to work. For example:

D:\projects\macrogl>sbt backendExamplesWebgl/fastOptJS
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
[info] Loading global plugins from C:\Users\Brandon\.sbt\0.13\plugins
[info] Loading project definition from D:\projects\macrogl\project\project
[info] Loading project definition from C:\Users\Brandon\.sbt\0.13\staging\44ec20cefe008edf2897\mecha\project
Publishing to Sonatype is disabled since the "SONATYPE_USER" and/or "SONATYPE_PASS" environment variables are not set.
Publishing to Sonatype is disabled since the "SONATYPE_USER" and/or "SONATYPE_PASS" environment variables are not set.
[info] Loading project definition from D:\projects\macrogl\project
[info] Set current project to macrogl (in build file:/D:/projects/macrogl/)
[error] Expected ID character
[error] Not a valid command: backendExamplesWebgl
[error] Expected project ID
[error] Expected configuration
[error] Expected ':' (if selecting a configuration)
[error] Expected key
[error] Not a valid key: backendExamplesWebgl
[error] backendExamplesWebgl/fastOptJS
[error]                     ^

[bbarker]

Looking in Build.scala, it isn't clear to me where /src/backend-examples would be compiled

[axel22]

While ScalaJS was working correctly (and most likely still does if you compile it), it was too much of a time committment for me to maintain it, so I dropped support for ScalaJS altogether a few months ago (i.e. I removed the ScalaJS-specific part of this project from the build definition). If you would like to fork and maintain the ScalaJS part, I am fully supportive, but I don't have enough time budget to do it myself.

[bbarker]

I think I understand the time issue ;).

Assuming I have the time, I could try - I wouldn't mind maintaining my own build server or config, but I wouldn't want a divergent fork if at all possible; would you still be happy to accept the ScalaJS-related changes? Honestly I'm primarily working on the JVM at the moment myself, I was just trying to get familiar with MacroGL.

Also, just curious, are you using MacroGL for anything else at the moment if you aren't using it to cross-compile to JS/JVM? Not trying to be snarky, but I thought that was its only (advertised) feature.

[axel22]

Makes sense - a divergent fork would be a pain. I am fine if you make changes in this repo too. If you would like to maintain it, feel free to make modifications to the .travis.yml as you see fit (I internally test separately from Travis).

The general idea is that there's an OpenGL abstraction layer that unifies WebGL and OpenGL into a single API. Then, this abstraction layer is used to implement MacroGL-specific primitives (e.g. some lightweight ARM that sets up the rendering pipeline using for-comprehensions, abstractions for declaring shader programs that take care of much of the plumbing, etc.). Stuff that WebGL does not support (e.g. compute shaders from OpenGL 4.3) are in the macroglex project.

Yes, I'm using MacroGL in a personal project for a 3d engine, but I only compile that project on the JVM. This is why I concluded that it takes too much time on my part to keep making sure that the cross compile to ScalaJS also works, and update each time a new version of Scala/ScalaJS comes out.

One other reason is that testing is a bit manual - my previous approach was to have a ScalaJS-built webpage with different kinds of examples, and inspect them after each push:

http://storm-enroute.com/macrogl/docs/0.4/
http://storm-enroute.com/builds/macrogl/latest/backend-examples-webgl/index-fastopt.html