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.

@Fat Cerberus: what was your plan with Oozaru?

It seems to me that a web implementation and a desktop implementation should be different rather than one being a direct port of the other.

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.

Yes, this is exactly what Oozaru is meant to be.  I've just be preoccupied with miniSphere since I'm trying to finalize the v2 API before I write an entire second implementation of it.

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.

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.

1.x was where it all started and I loved it for a while - Sphere 1.1 (at the time) is what I learnt to programme with.
But the v2 API is great too, I'm not intending to do anything around v1 anymore (as long as Fat Cerberus keeps fixing the bugs I find in v2 stuff )

The only reason I'd go with 1.x compatibility is because it's simpler, and because miniSphere still supports it. And there are old games that require it and I don't want to break those.

The way the Sphere v1 API is set up is actually not very browser-friendly at all.  There is no concept of an event loop in Sphere 1.x so games necessarily do this:

Code: (javascript) [Select]

while (true) {
    /* update stuff */

    /* render stuff */

    FlipScreen();
}

And of course MapEngine() itself is blocking.  Do anything like that on a webpage, and you lock up the browser/get your script forcibly terminated for your troubles.  To my knowledge there's no function like miniSphere's Sphere.run() that you can call in a browser to pump the event loop, you need to let your script return naturally.

Ah, damn. If only Oracle hadn't run Java applets into the ground and then ditched them :/

I'm starting to seriously work on porting miniSphere to Android. After a lot of frustration, I'm finally starting to get Allegro to work. I already got duktape to work a while ago, since that was obviously pretty easy.

https://joelme.twilightparadox.com/s/tlh9TFLdNPHvwZ6

Re. ChakraCore, has it been officially decided that miniSphere will use that?

It's not technically set in stone yet, but it's looking like the best option.  V8 and SpiderMonkey are both non-starters because they have C++ APIs which rely heavily on C++ block scoping and RAII to manage the scope of objects.  A good chunk of miniSphere's code would have to be rewritten to accommodate and I really don't want to compromise the nice C purity the project has now.  Plus I hate C++ with a burning passion

JavaScriptCore is still on the table, but the LGPL license makes it less than ideal.  It's a secondary option if for some reason Chakra doesn't work out.

Sounds good. I just want to not have to worry about rewriting that part of the android port. Allegro isn't fully figured out yet, but I've got graphics mostly down, shaders and advanced stuff aside, and I'm starting to work on porting libmng as well, since that looks simple enough.

I was thinking about it, and unfortunately, a lot of Sphere games will have to be majorly written, or they may be impossible to port because of the inherent input limitations in mobile devices.
I don't know how I'm going to do it right now, but when I get it fully working, I'm goiNg to figure out how to cleanly merge this into the mainline codebase.

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 - games using ES6 or even written in typescript could be compiled using CC and typescript into ES5 single file JS for duktape execution in "smaller" environments.

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).

That said assuming such a model was established I was hoping to later add code to make JSC a 3rd option, partly because I want to compare how sphere runs with JSC vs CC and partly because JSC is included in IOS - it would make an IOS port very easy.

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).

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.

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).

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.

To avoid spending forever abstracting duktape maybe just wrap most of its calls in "#ifdef"s?

EDIT: also I saw your question on the CC github, were you looking for this: https://github.com/Microsoft/ChakraCore/wiki/JsGetOwnPropertySymbols

No, that function doesn't do what I need, that just tells me which symbol properties are set for an object, like Object.keys() but for symbols.  What I wanted was the value of the built-in Symbol.iterator so I can use it as a property key during API registration.

Worse comes to worst I can just do:

Code: [Select]

iter_symbol = js_value_new_eval("Symbol.iterator");

But that's kind of awkward (eval is evil) and I was looking for a cleaner method.

Sorry I don't quite follow, and to be honest I'm only guessing at answers, my experience with CC = 2-3 hours reading about it and that's it. I was just trying to be helpful.

I've done some searches through the source each JS object seems to be given an Iterator internally, JsGetProperty may allow you C level access to it, though yeah, I'm guessing.