Skip to main content


  • The forums have now switched to ElkArte, an SMF fork which is more modern and maintained better!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rhuan

Engine Development / Re: miniSphere 4.8.4
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)
If you're striving for full Sphere v1 compatibility, you actually want to run map/entity scripts with `EvaluateScript()`, making them into functions (they get their own scope) or using `eval()` (uses scope of caller in ES5+) will change the behavior.

The difference if you're curious is that Sphere 1.x runs all scripts as top-level program code, the same way browsers handle multiple scripts.

This, incidentally, is the reason I made SetUpdateScript() etc. be able to accept a function instead of a string, since it let's you access local variables in your update/render/person scripts that way.
i'm trying to avoid using any of the v1 api, I want all of this stuff to work if you build sphere without vanilla.c

I'm not looking to emulate v1 the idea of the compatability shim I'm thinking of is to make it do enough so that anyone with a v1 project who wants to switch to v2 can use their existing maps without going through editing them all; their main script files will obviously need some updates.
Albrook from Kefka's Revenge might be a good test map too. Lots of layers and scripts everywhere.
Map and entity scripts are scaring me slightly, roughly I'm planning on using the function constructor to parse them and I can set up execution conditions easily enough my concern is I'd like to make v1 maps work which means I need to implement a shim over the top of all the v1 map/entity related functions AND provide that shim to all the map and entity scripts, I can do it but I haven't worked out an efficient way to do it yet (if you've read my code you'll know what I think of inefficiencies...)

I also need a mechanism for passing other functions and variables to those scripts as by default in v2 they'll be run with no access to anything global.
A scaling filter could be good. A lot of emulators use them for nice upscaling. Something more modern like EPX/Scale2×/AdvMAME2× might be good here.
Hmm... New planned feature for MEngine and SEngine :)
Please could someone suggest some really massive/complicated .rmp files I can test with?

Whilst I'm aiming at supporting Tiled maps as well as .rmp ones I want to support .rmp fully so would be good to have some horrible test cases.
Just skimming real quick, I came across this bit of ugly Sphere v1 code:
Trust you to spot that... :P I like being able to write to the directory I'm working in so I can have less open... That's just some temporary code for testing speeds of the different key functions though it won't remain in anything final.

Also main.js isn't really part of the project it's just a playground for trying it out, there isn't any v1 code in MEngine, SEngine or CEngine.
Sphere General / Re: Sphere v2 API discussion
Thanks for the heads up, I'll fix the bug in 4.8.4.

As for the branches and backrefs, I removed them because they were difficult to document adequately.  So I just tried to make it work similarly to a C struct because that's easy to understand and explain.  If there's enough demand I could bring the feature back, though. ;)

I admit I was nice being able to load an entire .rmp file with one call...
I've just learnt how the history feature works on github. :P

I'm going to add the branches/backrefs code to my own script for now, it's too good not to use.
Engine Development / Re: miniSphere 4.8.3
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:

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:

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.

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:
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.
Sphere General / Re: Sphere v2 API discussion
A few questions on dataReader.js (I thought I'd use it for loading .rmp files rather than re-inventing the wheel again)

1. I think it's meant to have:
const from = require('from');
at the top, the latest version doesn't have this but it uses from in the _checkStructDescriptor function.

2. Did you remove the ability to have multi-tier objects/arrays? I was looking back around page 74 of the miniSphere development topic and you'd been using a somewhat complex object with branches and self references in it to read an .rmp file, I assumed that this was with an early version of dataReader.js but I can't see any facility for processing of self references or branches in the latest version, am I missing something? If the facility is gone/not returning that's fine I'll write my own just don't want to do it if it's already there somewhere.

On a more personal note: In the process of doing these scaling tests, having to bring all of the spritesets back to the ones from the original LoZ, the project is feeling less and less original. Sure, the map is different but I'm starting to feel as if the other elements that I've had planned out won't mesh well together because Zelda is 16x16, Final Fantasy is 32x32 or 32x48 (depending on the sptite used) and those are just two among some other inconsistences that are developing.
There could be a different way to deal with the inconsistencies rather than ditching the sprites you had.

One possible answer would be to use SNES Zelda graphics rather than NES have you thought of that?

(Though considering how much mapping you've done this may be a bit late - it may be possible to use a script or some other quick method to swap the tiles you've used for different tiles whilst keeping the same layout if you can find tiles to swap on a 1 for 1 basis for each existing tile.)

Another idea would be to scale the maps and apply a filter to them something like super eagle or super 2xsai etc these filters scale and smooth graphics so they don't look so obviously scaled
Engine Development / Re: miniSphere 4.8.3
Could you simulate this error handling by doing the following

1. within the function that wants to generate an error the JsCreateError(message, out_error) function
2. an early return (to send sphere back into the JS)
3. wrap all JS execution commands in an error catching function that displays the message

PS I've built ChakraCore on MacOs and started doing some speed/functionality tests - it's close to parity with V8 and JSC for performance which is very nice to see, it seems to have a slightly higher threshold for triggering it's optimising JIT than JSC has which means you have to get to higher levels of recursion before its top speeds come out but those top speeds are pretty crazy.
Not finished yet (obviously) but I think these are really starting to take shape.

I'd be interested what people think of the code style and features etc, files are on dropbox so people can take a quick look:

3 system scripts + 2 shader files needed for them to function + main.js shows using them - this isn't a full demo yet as they're not finished (so I haven't included the resources (map and sprites) that the main.js script is looking for.

Quick note on licensing etc. When finished I will release these under the 3 clause BSD license in line with miniSphere - for now I've posted them for comment but ask they are not used in any public projects as they're incomplete.
Engine Development / Re: miniSphere 4.8.3
CC on the whole does look very nice my only concerns with it were that:
a) it's a bit new and less thoroughly tested than the alternatives
b) it's unlikely to be the fastest (though they're working on that)
c) I couldn't benchmark it myself without building some as microsoft edge can't run on a mac
d) Any new low level features are added to windows first and take time to be ported to other platforms
Engine Development / Re: miniSphere 4.8.3
I've had a quick read and it seems relatively simple to work with, I look forward to seeing how you get on, I'd love to have my sprite update code and collision code run with a JIT - performance is ok under duktape but it's a struggle to keep a steady 60 FPS whilst handling 100+ entities now I've added collisions.

I'd still also like to try a JSC version of sphere at some point, maybe when you're done with CC I'll see if I can swap it to JSC in a test build; from reading both APIs they seem functionally quite similar - same sorts of calls to make just different names for them, tbh I don't know which will actually be better - CC has far less test results available for it as it's so much newer and the only browser that uses it is windows only.

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.

General state of the different engines: V8, JSC and CC have all been undergoing rapid development over the last year for different reasons with much effort spent optimising each and even replacing core elements of their architecture (e.g. JSC got a whole new GC system in January, CC only got non-windows support a year ago and non-windows JIT support in October)
SM on the other hand seems to be slowly dying unless I'm missing something.
Sphere General / Re: Sphere v2 API discussion
Debating whether I should add a SphereFS prefix for temp files or not.  The prefix would be %/ and to maintain sandboxing purity, would be guaranteed by the engine to have nothing in it on startup.  Anything written into %/ would be deleted on shutdown.

The main thing that's stopping me is that I'm not sure how useful the ability to write temp files would be in practice, particularly for game development.  Any insights for me to help me decide?
The time I've wanted to make temp files has been to enable storing images or sound files alongside other data as sphere could only load these as individual files and couldn't convert bytearrays into images/sound the only way to unpack a document containing such things was to read the binary data for each image/sound then write it out to an individual file and load it.