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

neoSphere 5.10.1

This is neoSphere, the current official implementation of Sphere and a complete rewrite of Chad Austin's original Sphere game engine, coded from the ground up in C.  It uses Allegro for cross-platform graphics and sound and JavaScript is powered by ChakraCore.  The engine boasts near-full parity with the Sphere 1.5 API and most Sphere 1.x games will run in neoSphere with no modifications.  But make no mistake: this is a Sphere v2 engine, and includes many, many features not found in the engine it replaces.  These include Galileo, a scene graph API pioneered by TurboSphere which enables more flexible rendering than the Sphere v1 primitive-drawing functions; the RNG class for ultimate control over random number generation; SphereFS, a standard protocol for specifying asset filenames within the sandboxed file system; and full native support for JavaScript module syntax (import/export) as defined in ES2015.  Best of all, old and new API functions can be mixed within the same codebase, making migration of existing codebases to Sphere v2 very easy.

neoSphere natively supports many modern JavaScript features such as template strings, arrow functions, destructuring assignment, even modules!  The engine also comes with an SCons-inspired programmable build engine, Cell, also JS-powered, which can be used to build assets on-the-fly.  neoSphere was also the first implementation of Sphere to include support for single-step debugging!  Thanks to ChakraCore’s powerful built-in debugger API, it does!  Using either Sphere Studio or the SSj command-line debugger (both included with the engine), you can set breakpoints, see console output, and step through your game's code line-by-line to find bugs, inspect variables and even run arbitrary JavaScript code.

neoSphere 5.10.1 - November 29, 2025 - Release Notes - GitHub Repo
Includes neoSphere, SpheRun, Cell compiler, and SSj command-line debugger.
by Where'd She Go?



Sphere v2 API Documentation
  • Sphere v2 Core API Reference - v5.10.1
  • Sphere Runtime API Reference - v5.10.1
  • Cellscript API Reference - v5.10.1

Re: minisphere

Reply #1 –
That's odd, I just got an email that Flying Jester replied to the topic, but there's nothing here...

Re: minisphere

Reply #2 –
I almost wrote a reply, but then I decided to investigate first.

SFML ;_;
I never tried to use it before, but it's a bit of a mess on OS X. I brought the engine up on OS X (mostly) using SCons and the prebuilt SFML libraries for OS X.

Re: minisphere

Reply #3 –
How up-to-date is the api.txt that comes with Sphere?  I'll need a reference in order to replicate the Sphere 1.x API.

Re: minisphere

Reply #4 –
Last I checked, it has a few functions that don't actually work in Sphere (surface.blitImage() jumps to mind). I haven't found anything it's missing yet

I've been using it (from my git repo) to fill out the TS map engine.

I'm curious where the line will be drawn between script and native. Are surfaces native or script?

Re: minisphere

Reply #5 –
How would I do surfaces in script?  That definitely seems like something that should be native.

Re: minisphere

Reply #7 –
Small issue with that: besides that that puts surface operations entirely in software, how would I implement methods like surface.drawText, not to mention all the primitives.  If I wanted a 1:1 mapping to Sphere 1.x I'd have to implement those all in JS as well, meaning I don't get the benefit of letting the hardware do it, as I could if I were to implement surfaces natively.

Re: minisphere

Reply #8 –
So I'm thinking maybe not surfaces, but a lot of things will be implemented scriptside in minisphere.  For example: Color objects.  Duktape's stack-based API is painful to use (I don't even remember Lua's being this bad...) and once constructors and prototypes get involved, it gets even more convoluted.  For simple objects like Color, there's no real benefit to creating them on the C side as in the end it's just a simple RGBA tuple.  JS can handle those very well on its own.

In the process I think I'm going to make tweaks to the structure of the API, clean things up a bit.  For example, BlendColors() and BlendColorsWeighted() both get folded into the Color object as a single method: color_obj.blendWith(color2, w1, w2).  Of course, to maintain compatibility with existing Sphere code, I'll be sure to expose some kind of legacy API, likely as an optional thing, similar to what Jester is planning to do with TurboSphere.

Re: minisphere

Reply #9 –
I've been doing that to a certain extent with the map engine, and with images now.

I think that colors are one of the better objects to do that with, actually. In V8 there was a pretty high overhead to making any native-defined object, especially since that usually meant some native-side allocation had to occur. Making colors is easy to do all over the place in a normal Sphere script without even thinking about it. Putting them fully in script would help alleviate that. Especially because there is no particular reason they need to be done in native.

I think it's a good technique. Have a powerful, concise core API that Sphere's API is implementable in, and also a script-side layer that fills out the rest of the Sphere API. Even with the map engine, which is all script anyway =P

Re: minisphere

Reply #10 –
I'm not too concerned about script-to-native overhead--the purpose of a stack-based API like the one in Duktape and Lua is that any objects created are allocated in-engine, rather than on the native side.  For example, this:

Code: (c) [Select]
duk_push_global_object(ctx);
duk_push_object(ctx);
duk_push_int(ctx, 812);
duk_put_prop_string(ctx, -2, "number");
duk_put_prop_string(ctx, -2, "myObj");
duk_pop(ctx);


...is quite literally equivalent to this:
Code: (c) [Select]
duk_eval_string_noresult(ctx, "myObj = {}; myObj.number = 812;");


As you can probably tell, the bigger concern here is the unmaintainable mess the C-side constructors will end up becoming (hint: see first code snippet).  A lot of that can be avoided simply by implementing stuff directly in JS to start with.

Re: minisphere

Reply #11 –
Hm, so I'm thinking I may try out Allegro after all.  SFML was definitely designed for use in C++ (mapping a C++ API directly to C = incredibly bad idea), and I'd really like to keep this in C to keep it as simple as possible.

Re: minisphere

Reply #12 –
I support this idea!

SFML is also not very friendly to OS X or other more alternative OS's (neither is CMake, which is primarily what stopped me from manhandling it).

Have you considered SDL2 (or SDL 1.2 if you want super-mega portability)? It's a very cleanly C library.

Re: minisphere

Reply #13 –
I hadn't thought about SDL.  I'll consider it, especially after seeing how much stuff allegro has with all those plugins.  How much portability would I be losing to go with SDL2 over 1.2?

Re: minisphere

Reply #14 –
Quote from: Lord English – on

How much portability would I be losing to go with SDL2 over 1.2?


The main difference between SDL2 and 1.2 is API changes, especially WRT window handling (which is one of the many things abstracted to their newer image/surface/frame/etc buffer handling API). Most of the extra libraries (especially sdl_audio) do keep their APIs but simply changed internally to be SDL2-compatible at that time.

Support-wise, whatever 1.2 runs on SDL2 still runs on, but SDL2 might recommend a more C++ approach to it.

Re Allegro - It won't hurt to see how far an Allegro-based Sphere-compatible engine can go. If you choose to do it, I'd very much consider promoting it as an official multi-platform alternative to current vanilla 1.5, alongside TurboSphere and SSFML. :)