Couldn't Sphere run on the web using an individual's browsers JS engine + an implementation of the API in HTML 5? Yes that would require almost a line 1 re-write of the engine but on the face of it I think that would result in better performance and a more sensible system than trying to port the existing codebase.
Oh, I didn't realize Oozaru existed, I was just about to start messing with my own implementation, though I was going to start with the 1.x API and work my way up.
while (true) { /* update stuff */ /* render stuff */ FlipScreen();}
Re. ChakraCore, has it been officially decided that miniSphere will use that?
I had in my mind the idea that ChakraCore could be selected as a compile time CC or duktape depending what you're building for. duktape gives you a smaller more portable build that uses less resources, whereas CC gives you ES6 and higher performance.Not sure if this is what Fat Cerberus is planning though (seems a shame to bin the work done implementing duktape, particularly as it is so much lighter and more portable).
Quote from: Rhuan on August 23, 2017, 12:33:15 pmI had in my mind the idea that ChakraCore could be selected as a compile time CC or duktape depending what you're building for. duktape gives you a smaller more portable build that uses less resources, whereas CC gives you ES6 and higher performance.Not sure if this is what Fat Cerberus is planning though (seems a shame to bin the work done implementing duktape, particularly as it is so much lighter and more portable).This is certainly possible, and is one of the unspoken goals of the JS abstraction layer. Abstracting Duktape will be more difficult than CC/JSC because it uses a stack model instead of direct references to values, but it can be done with clever use of Duktape's global stash and heap pointers. So we'll see where this goes.
iter_symbol = js_value_new_eval("Symbol.iterator");