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

Re: miniSphere 5.1.0

Reply #2190 –
@Radnen If you feel like it, you could join the Discord chat while experimenting with the new API. Really helps to leave feedback on it especially when you find a bug, or you'll get a quick response on how something works. :)

Re: miniSphere 5.1.0

Reply #2191 –
Bad news I'm afraid regarding the miniSphere build for macOs. It appears that a new security feature of some kind in macOs High Sierra breaks it. (The error message you'll get is "can't find system font")

The build should still run fine on macOs Sierra though.

For anyone who's at the bleeding edge with macOs I'll try and find a way around this but not really sure what the answer is yet - it may have t have an installer or the answer may be that I just to put the system folder inside the app bundle - and change the path handling to expect this.

For now sphereRun is still usable, so if you're ok with having to launch everything from the command line it's all good... (I assume apple doesn't apply security to unix style applications in the same way they do to app bundles)

Re: miniSphere 5.1.1

Reply #2192 –
miniSphere 5.1.1 is up and fixes a bug where the engine could crash on startup if a game had any circular import dependencies.  The macOS build has been updated to the latest version as well.  Special thanks to @Rhuan for this release.

Re: miniSphere 5.1.1

Reply #2193 –
@Rhuan and I have been working on a great new debugging aid which is coming in miniSphere 5.2.  Historically, rejecting a promise in miniSphere would crash the specific promise chain it occurs in, but otherwise go unnoticed.  This can cause some very strange and difficult-to-understand behavior in heavily asynch code, especially in codebases where async functions are used heavily (like my own Spectacles project).  To illustrate the problem, take this code:

Code: (JavaScript) [Select]
async function pig()
{
    SSj.log("Oh no, I think I'm going to get eaten by the pig...");
    throw new Error("PIG!!!");
    SSj.log("The pig totally ate me, you guys!");
}

pig();
SSj.log("The pig is coming to eat EVERYTHING.");

This will hit all the SSj.log() calls except for the second one in pig(), and terminate normally.  That happens because pig(), being an unawaited async call, crashes at the throw without affecting the primary (i.e. synch) code path; the promise representing its return value is simply rejected sight unseen.

Broken promises are annoying and difficult to debug, but thanks to @Rhuan's hard work getting promise rejection tracking into ChakraCore, in miniSphere 5.2, the code above will be detected as a runtime error (by the event loop) and generate an error screen with a stack trace the same way an exception in synch code does.  This will make debugging async code much more pleasant.

Re: miniSphere 5.1.1

Reply #2194 –
Heads up: The next Windows release will be 64-bit only.  I've considered doing this a few times before, but kept backpedaling since I still wanted to support XP/Vista.  There are few factors that make going full 64-bit make more sense now:

  • ChakraCore minimum requirement is Windows 7 SP1.  Except for circa 2009 Atom-based netbooks with crappy integrated graphics (on which the OpenGL experience was awful), the vast majority of consumer PCs made around this time came with a 64-bit version of Windows 7 preinstalled.  At least this was my experience.
  • Hardware makers are slowly dropping driver support.  nVidia recently did so for their graphics drivers, for example: http://nvidia.custhelp.com/app/answers/detail/a_id/4604/~/end-of-nvidia-driver-support-for-32-bit-operating-systems
  • 32-bit Linux and macOS are already unsupported, as the ChakraCore build script only supports x64 builds.  This fact alone makes continuing to support 32-bit Windows feel like an anachronism.

So yes, long story short: miniSphere 5.2 5.1.2 and later will require a 64-bit operating system on all platforms.

edit: This change came earlier than expected and has been implemented starting with miniSphere 5.1.2.

Re: miniSphere 5.1.2

Reply #2195 –
miniSphere 5.1.2 improves exception handling for asynchronous code.  Unhandled rejected promises--and by extension, uncaught exceptions in async functions--will now trigger the error screen the same as a normal exception.  It also adds system-directory packaging: When packaging a game into an SPK, Cell will now include the system files to future-proof the package (do note that the packaged system files will be ignored unless the package is run with v5.1.2 or later).

These are somewhat large additions for a point release (and technically violate semantic versioning rules), but they are low-risk changes and I wanted to get these out sooner rather than later, particularly the async exception handling.

Note: In line with the post above, the Windows release of miniSphere 5.1.2 is 64-bit only.
 

Re: miniSphere 5.1.3

Reply #2197 –
5.1.3 is up to fix a couple annoying issues and add support for Promise#finally().  The error screen is also a bit more colorful now. :smile:

Re: miniSphere 5.1.3

Reply #2199 –
I’ve updated the link for the macOS build in the OP to 5.1.3.  All supported platforms are now up to date. :D

Re: miniSphere 5.1.3

Reply #2200 –
I’ve made some improvements under the hood that should make miniSphere 5.2 noticibly snappier than 5.1 in various scenarios.

Also some new features coming in the next release, stay tuned for more info. :D

Re: miniSphere 5.1.3

Reply #2201 –
Regarding the optimizations mentioned above, performance of API calls in particular has sped up a ton compared to the current release (5.1.3).  Before-and-after image attached.  This is a huge improvement and the effects are very noticeable in-game as well; everything is much snappier and CPU usage has been nearly cut in half across the board.

Re: miniSphere 5.2b1 (stable 5.1.3)

Reply #2202 –
The first beta of miniSphere 5.2 is here!  I don't normally do beta releases for minor versions, but this one turned out to be bigger than I anticipated...

Big new features showed off in the beta are:

  • Profiling with SpheRun: Run your game with spherun -p to have it profiled and see exactly how hard you're pushing the engine.  You can also use the new SSj.profile function to have the engine profile your own function calls so you can see where you're spending the most time.
  • Z.inflate and Z.deflate for general-purpose data compression.  Just pass an ArrayBuffer or typed array containing the data to be compressed!
  • Dispatch.onExit: Run some code on shutdown, after the event loop terminates.  This works even if the user manually closes the window!
  • Shape.drawImmediate: Draw a vectorized primitive on-the-fly without the need to create a VertexList and Shape first.  The prim module takes advantage of this now as well, vastly improving its performance.
  • Texture#upload and Texture#download which allow direct access to a texture's RGBA bitmap
  • Surface objects will now be accepted wherever a Texture is expected, no need to call .toTexture() first.  This allows render-to-texture effects, as well as pre-rendering, to be implemented very easily.

Re: miniSphere 5.2b1 (stable 5.1.3)

Reply #2203 –
Quote from: Fat Cerberus – on
  • Dispatch.onExit: Run some code on shutdown, after the event loop terminates.  This works even if the user manually closes the window!

I like this. This prevented me from writing a clean MMO in Sphere back in the day. I had to 'poll' every user to see if they were actually logged in or not every like 5 minutes. Good times, hahaha,
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

Re: miniSphere 5.2b1 (stable 5.1.3)

Reply #2204 –
It was actually somewhat tricky to implement that, as miniSphere is fully v1 compatible and Sphere 1.x didn't have an event loop.  So if you close the window while the game is in the middle of while (true) { FlipScreen(); }, the only way the engine can honor the exit request at that point is to forcibly bail out of JavaScript execution.  With ChakraCore that's done by calling a function to disable script execution, and doing so works well enough... the tricky part is that if you leave it disabled, you'll fall right through the event loop without getting a chance to run any exit handlers.  Figuring out where to put the safety net to stop that from happening without causing other unwanted side-effects was... fun. :stuck_out_tongue: