Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8505722 times) previous topic - next topic
0 Members and 14 Guests are viewing this topic.

Re: miniSphere 4.8.3

Reply #1905 –
Something interesting about CC is that any JsValueRefs stored as local variables on the stack are apparently protected from garbage collection without needing to explicitly root them nor call JsRelease().  I'm not really sure how that works: Does the GC actually examine the native C/C++stack frames looking for refs?

Although I guess you'd need to have a system like that if you're doing GC off-thread.  Otherwise the object might get collected before you had a chance to root it.

Re: miniSphere 4.8.3

Reply #1906 –
Quote from: Fat Cerberus – on
So far I've written a bunch of functions to abstract around the JS engine and fit in with the style of the rest of the codebase:
https://github.com/fatcerberus/minisphere/blob/chakra-js/src/shared/ecmunch.c

I've done some testing with it and I can successfully set object properties, create functions, eval code and get the result back, etc.  I haven't figured out how to get it to load a module yet, though.
Hmm I said the documentation was good... But it's not all in place, for some reason setting up modules is documented in ChakraCore.h but not in the wiki.
For executing a module looks like you need:
JsInitializeModuleRecord
JsParseModuleSource
and
JsModuleEvaluation

As far as I can tell these are all ES6 style, not commonJS though I haven't gone into the detail to check that.

I assume commonJS may need to be added similar to other engines.

Quote from: Fat Cerberus – on
Something interesting about CC is that any JsValueRefs stored as local variables on the stack are apparently protected from garbage collection without needing to explicitly root them nor call JsRelease().  I'm not really sure how that works: Does the GC actually examine the native C/C++stack frames looking for refs?

Although I guess you'd need to have a system like that if you're doing GC off-thread.  Otherwise the object might get collected before you had a chance to root it.

A quick look gave me the following:
Quote
A Chakra runtime will automatically track JsRef references as long as they are stored in local variables or in parameters (i.e. on the stack). Storing a JsRef somewhere other than on the stack requires calling JsAddRef and JsRelease to manage the lifetime of the object, otherwise the garbage collector may free the object while it is still in use.

Re: miniSphere 4.8.3

Reply #1907 –
Maybe the module functions are experimental/not released yet?  I'll check into that later.

Re: miniSphere 4.8.3

Reply #1908 –
Quote from: Rhuan – on
A couple of notes on my points above:
V8 documentation: a lot of content on their wiki has been written this year, so it may have been a lot worse before.

It was non-existent before. A big part of when I switched to SM for TurboSphere was that V8 was largely undocumented, and what was there was unusable. The API changed wildly every couple months (compared with SM's, which is quite stable in comparison), and there was no documentation at all, except three pages of outdated descriptions of APIs that no longer existed, and two examples that were not updated since before I began the project.

Regarding API stability, unless things have drastically changed in the last couple months since I updated some Turbo code to SM 52, SM is still way, way more stable than V8.

I also caution against using V8 for anything relating to graphics or files, since its GC is very unreliable. SM's was much more stable, always releasing memory in a timely manner. This made V8 basically unusable for Galileo or any FS work.

Re: miniSphere 4.8.4

Reply #1909 –
miniSphere 4.8.4 is out now with several bug fixes and improvements.  No new APIs this time.

Re: miniSphere 4.8.4

Reply #1910 –
Just going to say how awesome it is every time I get to see this. ;D

Re: miniSphere 4.8.4

Reply #1911 –
I got ChakraCore up and running! :D

I set up the following test:
Code: (C) [Select]
static js_value_t*
js_chakraTest(js_value_t* this, int num_args, js_value_t* args[], bool is_ctor)
{
    printf("Something stupid happened and then you got eaten by a %s!\n",
        js_value_as_string(args[0]));
    return NULL;
}

js_value_t* function = js_value_new_function("chakraTest", js_chakraTest, 0);
js_value_set(js_global_object(), "chakraTest", function);
js_value_unref(function);
js_value_unref(js_value_new_eval(lstr_new("chakraTest('pig');")));

Output:
Code: [Select]
Something stupid happened and then you got eaten by a pig!

The js_value_unref()s are an unfortunate side effect of the abstraction--I'm not longer passing around the JsRefs directly, so I need to manage the object lifetime manually. :(

Re: miniSphere 4.8.4

Reply #1912 –
Quote from: Fat Cerberus link=msg=9964
The js_value_unref()s are an unfortunate side effect of the abstraction--I'm not longer passing around the JsRefs directly, so I need to manage the object lifetime manually. :(
Hmm, will that cause a problem with garbage collection? I can see it getting annoying at least, anyway you could add at least some of them to the abstraction layer?

I assumed you'd have got a function callback set up sooner I guess you focussed on the abstraction layer first?

Good work nonetheless.

(I wrote an equivalent test for jsc on Saturday but without any abstraction, which meant it was much quicker to do but ultimately much less useful I suppose)

Re: miniSphere 4.8.4

Reply #1913 –
Quote from: Rhuan – on
Quote from: Fat Cerberus link=msg=9964
The js_value_unref()s are an unfortunate side effect of the abstraction--I'm not longer passing around the JsRefs directly, so I need to manage the object lifetime manually. :(
Hmm, will that cause a problem with garbage collection? I can see it getting annoying at least, anyway you could add at least some of them to the abstraction layer?

I assumed you'd have got a function callback set up sooner I guess you focussed on the abstraction layer first?

Good work nonetheless.

(I wrote an equivalent test for jsc on Saturday but without any abstraction)

Regarding the abstraction layer: I wanted to get it out of the way first, to avoid making the same mistake I made with Duktape where there was no abstraction to begin with and implementing the extra layer now would be prohibitively time-consuming relative to the benefits.  It's bad enough I'm going to have to refactor everything in pegasus.c and vanilla.c (and probably some stuff in map_engine.c too).  The v1 and v2 APIs taken together account for about 500-600 functions, methods and properties, the only saving grace is going to be that those are mostly all stubs with the actual work done deeper in the engine.

Writing an abstraction layer first has actually become my M.O. of late.  It makes it easier for me writing the higher-level code because I tend to change low-level details around a lot during early development of big features.  If I can minimize having to constantly rewrite outside call sites in the process, it speeds things along in the long run.

Garbage collection shouldn't be negatively impacted as long as I don't forget to free values.  In practice I don't see needing to create that many JS objects in C code in normal operation, so it shouldn't be too annoying.  I could probably do some of the work in the abstraction layer, e.g. by calling `js_value_unref()` after setting a property (since it's unlikely the value is still needed on the native side after that).

Re: miniSphere 4.8.4

Reply #1914 –
Another advantage to writing the abstraction first: It allowed me to quickly get familiar with a large swath of the API, rather than only a single focused portion of it as would have been the case if I just tried to set up a callback right away.

Re: miniSphere 4.8.4

Reply #1915 –
Quote from: Fat Cerberus – on
Regarding the abstraction layer: I wanted to get it out of the way first, to avoid making the same mistake I made with Duktape where there was no abstraction to begin with and implementing the extra layer now would be prohibitively time-consuming relative to the benefits.  It's bad enough I'm going to have to refactor everything in pegasus.c and vanilla.c (and probably some stuff in map_engine.c too).  The v1 and v2 APIs taken together account for about 500-600 functions, methods and properties, the only saving grace is going to be that those are mostly all stubs with the actual work done deeper in the engine.
I could help with the refactoring if you'd like, once you've got the basic framework set up and done a few functions I'm sure I'd be able to match the style and basic methodology. Let me know if you want to split it.

Re: miniSphere 4.8.4

Reply #1916 –
Oh boy, another library that I'll have to get working when/if I ever get around to getting more done on Android/emscripten support :P
Really though, getting the Javascript library (whatever that is/will be) is the least of my worriest. I've yet to get Allegro to work in either emscripten or Android Studio.

Re: miniSphere 4.8.4

Reply #1917 –
If you ever get miniSphere to work on Android, let me know!  Allegro is supposed to support it but I couldn't figure out their build systems.

Re: miniSphere 4.8.4

Reply #1918 –
ChakraCore on Android would be a project... BUT: https://github.com/Microsoft/ChakraCore/issues/3179 some people apparently made an unofficial port of chakracore (and node.js running on top of chakra) to ios so it can almost certainly be done to android.

I don't think emscripten would be the way to do it though, CC is big.

(Regarding the node.js comment - there's a shim written by microsoft to translate the chakracore run time into the V8 runtime so people can link node.js to chakracore + the shim instead of V8)

Quote from: Fat Cerberus – on
If you ever get miniSphere to work on Android, let me know!  Allegro is supposed to support it but I couldn't figure out their build systems.
I couldn't get Allegro's MacOs build systems working well so i wrote my own xcodeproject/makefile for it in the end when I was getting minisphere to compile. I daren't think what their android system is like.

Re: miniSphere 4.8.4

Reply #1919 –
Will do. And looking around, it looks like without making some serious changes and compromises, getting Sphere on the web would be almost impossible. It would take significantly less effort to port a sphere game to HTML5.

Come to think of it though, porting the 1.x (for starters) API might not be such a bad idea. Porting the threading stuff could be a bit difficult, and game developers might have to deal with cross-browser compatibility, but it would still likely be easier than porting all of miniSphere to JavaScript.

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