Skip to main content

News

Topic: neoSphere 5.9.2 (Read 522840 times) previous topic - next topic

0 Members and 20 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1.8
Reply #540
Check the documentation folder for minisphere-api.txt.  Most of the new stuff should be documented, it's the legacy functions I skimped out on (which you have the 1.5 doc for anyway).  I'm slowly filling those out too as I go along though.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.1.8
Reply #541
Okay, thanks a bunch. :)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1.8
Reply #542
minisphere 1.2 development is officially underway. ;D  The latest commits add the following APIs for Zone management:


  • AddZone() and RemoveZone()

  • GetZoneSteps() and SetZoneSteps()

  • SetZoneDimensions()

  • SetZoneScript()



Three of these (AddZone, RemoveZone and SetZoneDimensions) look like they were planned for Sphere at some point and experimentally implemented, but were never exposed to script.  AddZone in particular has the entire function commented out in the source. ???  So seeing that, I figured "Why not?" and implemented them.

SetZoneScript was inspired by this thread:
http://forums.spheredev.org/index.php/topic,1194.0.html

And Get/SetZoneSteps were just low-hanging fruit. :P
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2b1 (stable: 1.1.8)
Reply #543
The first minisphere 1.2 beta is available, go check it out!  This includes the new zone and trigger APIs mentioned above as well as CommonJS support. :)  Oh, and the API documentation has been fleshed out some more.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2b1 (stable: 1.1.8)
Reply #544
So out of curiosity, I ran the loop tests I discovered hidden in the Sphere-SFML test game source with all three current engines.  The results are attached as screenshots.

The cliffnotes version: Obviously SphereSFML won because Jurassic is awesome, however one thing shocked me: The huge divide between minisphere and Sphere 1.5.  I'll get to that in a minute, though.  Before I get started, my test rig is an AMD A10-6800K @ 4.1 GHz with 8GB RAM and running Windows 8.1 Pro x64.

As you can see in the screenshots, Sphere 1.5 averaged around 1300ms per test.  The only ones that were under 1000ms were the two that increment twice per iteration.  This pattern shows across all engines, though, so apparently the loop condition check is expensive?

SSFML 0.90: The best result by far was "For i++ in Step", which got 17.2ms(!).  Makes sense, that's the common case for a for loop, so Jurassic optimizes for it.  What's interesting, though, is that Jurassic falters when it hits the i += 1 tests.  If you're JITting, then i += 1 should compile to the same machine code as an increment, right?  But apparently it doesn't.  Weird.  Ignoring the outliers, SSFML averages ~50ms per test, and around 130ms if you include everything.  Very impressive.

Now we get to minisphere (1.2b1).  If this is any indication, Duktape is literally 3-4 times faster than SpiderMonkey 1.5.  I knew it was a highly optimized engine, but this still blew me away.  Here again, though, i += 1 is way slower than a postfix increment for no discernible reason.  It's only a 100ms difference though, so not really an outlier.  Average across all tests: ~385ms.

So the bottom line is, not only is minisphere leagues faster than Sphere 1.5, but it holds up well against a JITted engine as well.  And from what I hear, the Duktape dev is working on even more performance improvements, so that gap should narrow even further in the future.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.2b1 (stable: 1.1.8)
Reply #545
It's funny how an engine not necessarily built around speed still out-performs Sphere 1.5. I guess SpiderMonkey team really just focused on getting it to work, not even they focused on optimization.

Jurassic lacks static type JIT optimizations. If you are doing a for loop and it knows you are doing integer adds it should use increment. This was on the table of optimizations to be made but the author never got around to it. I thought the C# JIT would do optimizations for you if you can supply it the MSIL bytecode, but perhaps it comes down to what environment or context you give it and the author hadn't optimized for these cases.

That's raw speed for you though. I've since moved to a different test where I call into a function like CreateStringFromByteArray(), the performance varied greatly. When I ran that in a loop in SSFML it took 400ms to do what Sphere 1.5 did in 20ms. But I found out that there is a way to rewrite the way Jurassic notices the method bindings (rather than letting it guess the methods, you can tell it, which is much faster) and upon doing that to my code, I was able to get it down to 40ms. Sphere 1.6 did the test in 60ms so obviously things got even slower between bindings from 1.5 to 1.6. The for loop test was faster in 1.6, however, making the benchmark rather odd.

So I'd do a benchmark with raw JS (which is this) and JS->native calls like CreateColor() or CreateStringFromByteArray() and just see what they bring to the table. Because, Sphere code will make use of many Sphere API calls in loops and they all ought to run fast or otherwise I'd just do -*everything* in JS and only expose file and input I/O as well as a basic drawing API and have the map engine and everything else live in script to remove the native call overhead. I think for Jurassic this might be the fastest since everything's IL anyways. But it's just the optimizations that it'll lack.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2b1 (stable: 1.1.8)
Reply #546
Yeah, obviously I knew this benchmark was useless for real-world performance testing, I was just interested in raw performance of the JS engines.  I'll definitely try adding some API calls to the mix at some point though.

I do want to do a JS map engine at some point though, perhaps for minisphere 2.0.  I'll keep the built-in default one in the engine, but I want to try my hand at writing a more OO map system, which JS is far better suited to than C.  Things like SetDefaultPersonScript might be more difficult with objects, though...
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.2b1 (stable: 1.1.8)
Reply #547

So I'd do a benchmark with raw JS (which is this) and JS->native calls like CreateColor() or CreateStringFromByteArray() and just see what they bring to the table. Because, Sphere code will make use of many Sphere API calls in loops and they all ought to run fast or otherwise I'd just do -*everything* in JS and only expose file and input I/O as well as a basic drawing API and have the map engine and everything else live in script to remove the native call overhead. I think for Jurassic this might be the fastest since everything's IL anyways. But it's just the optimizations that it'll lack.


A huge advantage of newer SpiderMonkey is that it is quite capable of this, since it's the stance Mozilla takes with the web now. JavaScript for everything.


Yeah, obviously I knew this benchmark was useless for real-world performance testing, I was just interested in raw performance of the JS engines.  I'll definitely try adding some API calls to the mix at some point though.

I do want to do a JS map engine at some point though, perhaps for minisphere 2.0.  I'll keep the built-in default one in the engine, but I want to try my hand at writing a more OO map system, which JS is far better suited to than C.  Things like SetDefaultPersonScript might be more difficult with objects, though...


You could always check out how I did it. My map engine has fairly complete API coverage (mostly missing FollowPerson stuff), even if it isn't totally accurate, and it is fully object oriented.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2b1 (stable: 1.1.8)
Reply #548
Yeah, I'll probably take a more in-depth look at the Turbo engine at some point.  I would want an object-oriented API though as well though, not just under-the-hood.  For the most part the 1.5 interface is perfectly serviceable, but there are places where it's... awkward.  Things like Get/SetPersonX/Y and whatnot.

I do have to caution you that the person spooling you do pre-MapEngine() isn't 100% compatible with Sphere's behavior and is likely to catch you off guard at some point.  I know it did for me on multiple occasions during development.  Sphere--and minisphere--actually create a concrete person object (not just metadata) when you call CreatePerson(), and non-transient persons survive a MapEngine cycle.  This latter behavior is where the spooling will break down, I think.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2b1 (stable: 1.1.8)
Reply #549
Word of advice: When stubbing things out  during development, particularly lesser-used functions, make sure the stub can't be mistaken for correct functionality. :P This is what I did with font.clone(), and it literally JUST got fixed today.  The stub I wrote for it simply incref'd the original font and returned that.  Since fonts are rarely cloned and the behavior is fairly close to what it's supposed to do, I ended up forgetting about it.  The only, ONLY reason it got fixed was because I was writing the documentation for the Font object and happened to notice it while reviewing the code.

Other bugs fixed today as a result of the review: font.setCharacterImage() not updating the font metrics, font.wordWrapString() not handling whitespace properly and causing crashes under rare circumstances (namely, small wrap widths), and better handling of long stretches of characters with no whitespace.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2b1 (stable: 1.1.8)
Reply #550
New minisphere 1.2 feature: the Sphere object.  This is an alias for the JS global object and is similar to window in a browser, allowing you to create global variables from strict mode code as well as serving as an optional namespace for built-in APIs if you're so inclined:

Code: (javascript) [Select]
Sphere.isThisAwesome = true;

var key = Sphere.GetKey();

Sphere.FlipScreen();

// etc.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2
Reply #551
minisphere 1.2 is up.  I've decided to quit with the betas from here on out and just release.  minisphere has been on such a rapid release cycle anyway and I've been very good about fixing bugs, so there's really nothing to gain from pre-releases for this project.

Anyway, 1.2's flagship feature is CommonJS support.  This means require(); now works in minisphere if anyone is so inclined to use it. :)  I've also bumped the reported API version to 2.0.  It's not Pegasus, but between Galileo, CommonJS modules and the object constructors introduced in 1.1, I feel the engine identifying as lowly Sphere 1.5 is a bit disingenuous at this point. :P
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2
Reply #552
I just discovered a neat trick for determining the correct facing command for a corresponding movement:

Code: (javascript) [Select]
var faceCmd = moveCmd - COMMAND_MOVE_NORTH + COMMAND_FACE_NORTH;


Note that this only works in minisphere.  Sphere is missing the diagonal movement commands, so the values don't line up. :(


neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • FBnil
  • [*][*]
Re: minisphere 1.2
Reply #553
Congrats on the new release. I took it for a spin. Impressive.
Using Linux with wine. I had Full screen issues, due to the keyboard not binding to the screen, had to alt+tab out and in again.
Very much interested in seeing zones working. (saw a post in march that is was enabled... but 1.2 does not have it?)

About the speed with S1.5. It was build with JS1.4 (or was it JS1.5?). I succesfully tested JS1.6, 1.7 and 1.8rc1 through the years (before that fateful day my laptop blew up) and JS wise, they were faster, and also allowed new JS functions, but did nothing to the FPS of games (unless you were not using the mapengine, but most did), while using up much more RAM. A the moment, the API of JS changed so much (see the releasenotes from JS31) that lots of interface calls have to be rewritten. As Spidermonkey gets up to par with V8, I expect more from it now. But am discouraged, as I am not even getting zlib compiled without errors. (switched to MSVC++2010, God knows where my bought DVD is... never got to use it). Any way, the easiest way was ripping JS from old Firefox distro's. Some required also a NS4 dll, next to JS32.dll and some of those builds were slower.

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Releases/31

For now, I think spending time on testcases is much more fruitful. I can not even get zlib to compile at the moment...  (zlib\src\contrib\masmx86\inffas32.asm(649): error A2070: invalid instruction operands)... so that is... bad... of course, I got a new MSVC, and do not remember what I required to set up to get it all working again. If somebody can point me to a wiki that works...

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.2
Reply #554
Zones definitely work.  The Lithonite tech demo is included with the engine and should be fully functional.  Literally nearly the entirety of the 1.5 API is implemented, the only thing that generally stops a game from working is the stricter argument checking (Boolean arguments aren't automatically coerced, etc).

Check minisphere-api.txt in the documentation folder for full documentation, including all the new stuff. ;D

Not sure what all that was about SpiderMonkey and zlib though.  I'm guessing you're trying to build Sphere 1.x?  Wrong thread for that. :P
  • Last Edit: June 07, 2015, 10:09:30 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub