Skip to main content

News

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

241
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.
242
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.
243
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:
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.

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

245
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
246
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.
247
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: https://www.dropbox.com/sh/9rug8p7bjll4e8l/AAAbiYncMBRbYd8k7Wps5CpHa?dl=0

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.
248
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
249
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.
250
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.
251
Engine Development / Re: miniSphere 4.8.3
https://github.com/fatcerberus/minisphere/issues/153

I've spent some time staring at JS engines recently, looking at compatibility, performance, and usability.

In addition to Spidermonkey (SM) and V8 I've also looked at Apple's Javascriptcore (JSC_ and I've taken a quick look at Microsoft's Chakracore (CC).

As far as I can see none of them run TypeScript natively (suggestion from your issue log above) that is unless I'm missing something the TypeScript benchmark some of them show is the speed of compiling typescript with the javascript typescript compiler.

Performance
Different ones are better for different things. V8 seems to get the best results out of javascript that's written for readability not speed, whilst javascriptcore gets the worst results from such code. Spidermonkey comes out in the middle. flipping to code that has been written for speed and uses optimisation tricks javascriptcore jumps to the lead, outperforming V8 and spidermonkey by significant margins in some cases. Microsoft's ChakraCore seems to generally get the worst results on most benchmarks though there are a few outlying positives. I note that even bad results on the benchmarks = 10 * faster than miniSphere's current performance; the good results on the benchmarks are 70 * faster or more.

I note that from the tests I did it looks like far more effort has gone into optimising V8 and JSC performance than CC and SM, presumably as JSC is now used in a lot of IOS games and V* is used in node.js and probably android apps.

Compatibility with ES6
They're all pretty good JSC gets 99%, SM and v8 both get 97% and CC gets 96. http://kangax.github.io/compat-table/es6/

Garbage Collection
CC: uses parallel processing to have garbage collection always happening rather than pausing for it
V8: incremental garbage collection but stops code execution when doing it
SM: no idea what it does - only documentation on GC in SM I can find says at the top that it (the documentation) is out of date and wrong
JSC: uses parallel processing to avoid stopping main thread for GC


APIs:
JSC and CC both appear to have pure C apis available. (JSC also has an objective C api but it's a wrapper around the C api and can be safely ignored).
V8 and Spidermonkey both have C++ apis as the only option.

Documentation:
V8: good documentation
CC: good documentation
SM: mixed documentation - wiki with loads of out of date content, though the key information for how to use it is there
JSC: mixed documentation - lots of focus on the objective C wrapper api rather than C, also most articles assume that any developer using it is targeting IOS

Licenses:
V8: BSD
CC: MIT
SM: MPL2
JSC: LGPL
All of these seem ok to me as long as the source is kept separate from the miniSphere source.

Conclusion
Considering the potential to avoid needing a C wrapper around C++ I think that CC or JSC would be nicer options than V8 or SM, then based on benchmark performance I think that JSC just wins.

Anyway comparing these was a nice bit of fun, now I need to finish my collision detection...
252
If you're doing a 3D projection then the Z coordinate affects how close or far away the vertex is from the screen, extending from zero (the camera "lens") to negative-infinity.  Anything outside of the Z clipping distances (defined by the near and far parameters of project3D) won't be rendered.  That's why there's a Z translation just before the projection in my example.

Note: Anything with positive Z will be clipped by definition because it lies "behind" the camera.

In any case, good that you got it working at least.  3D is hard. :P
I still can't draw shapes with z-values but I can transform the screen which works sufficiently well.
253
Sphere General / Re: Sphere v2 API discussion
What is the purpose of using radians over degrees?
They make a lot of mathematics simpler - without them you end up having to multiple by pi/180 all over the place if doing any funky trigonometry or geometry.

They actually make a lot more sense than degrees it's just everyone is used to degrees.

As one simple example, draw two radii in a circle, measure the angle between them in radians and multiply by the length of one of them and you get the length of the arc between them (i.e. the distance around the circle's circumference between the two radii).
254
4. An equivalent of FF6 style Mode 7 works with no slow down (thanks to Fat Cerberus)

I guess that means you figured out the projection matrices. :)
In the end I copied and pasted your screen transformation code and edited a few numbers; I was fiddling around with z coordinates which actually appear to be irrelevant unless I'm missing something, the working version I'm using has all the z coordinates set to 0.

In other news, tile based collisions all work now. Polygon based collisions is the next target, then an RMP loader.
255
Well some progress made:
1. I can move around the map with the camera following me - (though I can't manage to make it always stay centred if I zoom in and out too much)

2. Collisions with map scenery work

3. Collisions with other sprites on the map did work earlier they're not working now and I'm not sure why, I will fix this...

4. An equivalent of FF6 style Mode 7 works with no slow down (thanks to Fat Cerberus)