A break from the sparse voxel octree stuff…
This is probably the first significant thing I’ve done with Basic4GL in years.
I built a basic virtual machine run-time, into which you feed the compiled Basic4GL program, and compiled it on Android NDK. I had to add some symbolic information about which Basic4GL runtime functions it calls and a basic “link” step to wire them up to the corresponding runtime functions that the Android VM implements. The idea is that the Android VM runtime doesn’t need to implement all the Basic4GL functions to start with. In this test it only implements “print” and “printr”, but it’s enough to prove that the VM executes the code correctly, and gives something to work with while the rest of the functions are built up.
Eventually I want to build it up close to the feature set of Basic4GL, so you could write an debug something in Basic4GL until you’re happy with it, and then deploy it to Android. And there’s no reason why the same approach couldn’t work for iOS and desktop web browser (via asmjs and emscripten) too.
I’m not quite sure about the OpenGL functions though. Basic4GL supports OpenGL 1.1 – known as “legacy OpenGL” these days. In theory that should map to OpenGL ES 1.1, but how closely I’m not sure. And if I want to run the same code in asmjs using WebGL I’d have to use the emscripten legacy OpenGL emulation. Again I’m not sure how closely that would work. Ideally I’d like an identical experience across PC, Android, iOS and web browser, which would require some common subset of functionality between OpenGL 1.1, OpenGL ES 1.1 and WebGL (with fixed pipeline emulation). But I don’t know whether such a common subset exists and is large enough to be useful.
I still think this would be useful, even without OpenGL 1.1 commands.
It’s also nice to be doing something with Basic4GL again. I felt I’d pushed it as far as it could incrementally, without doing a serious redesign and rewrite (which I just don’t have time for these days). So it’s nice to have a new avenue to pursue.