Skip to main content

News

Topic: miniSphere 5.0.1 (Read 214709 times) previous topic - next topic

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
miniSphere 5.0.1
miniSphere is a complete rewrite of Chad Austin's original Sphere game engine, developed from the ground up in C.  It uses Allegro for graphics and sound and JavaScript support is provided by ChakraCore (Duktape was used prior to miniSphere 5.0).  The engine boasts near-100% parity with the Sphere 1.5 API and most existing games will run with no modifications.  But make no mistake: this is a Sphere v2 engine, and includes many features not found in the engine it replaces.  These features include Galileo, a scene graph system 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; and a CommonJS module system based on the one implemented in Node.js.  Best of all, old and new API functions can be mixed within the same codebase, making migration to Sphere v2 very easy.

Thanks to Chakra, the same JavaScript engine used in Microsoft Edge, miniSphere natively supports 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.

Still not convinced?  What if I told you that miniSphere is the first (and so far, only) implementation of Sphere to include support for single-step debugging?  Thanks to Chakra's powerful built-in debugging support, 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.  It's an invaluable tool for any serious game developer.  Some might say it's miniSphere's killer feature!

miniSphere 5.0.1 - November 2, 2017 - Release Notes - GitHub Repo
Includes miniSphere, SpheRun, Cell compiler, and SSj command-line debugger.
Windows release also includes Sphere Studio (.NET 4.5+ required).


Sphere v2 API Documentation
  • Last Edit: November 02, 2017, 01:43:41 am by Fat Cerberus
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere
Reply #1
That's odd, I just got an email that Flying Jester replied to the topic, but there's nothing here...
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
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.
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere
Reply #5
How would I do surfaces in script?  That definitely seems like something that should be native.
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

Re: minisphere
Reply #6
It would be simple, just an object that has a UInt32Array, a width, and a height :)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
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.
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
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.
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
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.
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
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.
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
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?
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: minisphere
Reply #14

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. :)