Author Topic: miniSphere 4.5.10  (Read 118946 times)

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
miniSphere 4.5.10
« on: January 25, 2015, 11:21:21 am »
miniSphere is a reimplementation of Chad Austin's original Sphere game engine, written from the ground up in C.  It uses Allegro for graphics and sound and Duktape for JavaScript.  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.

miniSphere includes support for ECMAScript 2015 syntax and built-ins when used in combination with Cell, the official Sphere compiler.  With a properly-written Cellscript, Cell translates all your arrow functions, template strings and destructuring assignments into a form Duktape understands, thus allowing you to use fully modern JavaScript techniques in Sphere games.  Cell can even package your game into an SPK file automatically!

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 Duktape's powerful built-in debugging protocol, it does!  Using either Sphere Studio or the SSJ command-line debugger (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 4.5.10 - April 3, 2017 - Release Notes - GitHub Repo
Includes miniSphere, miniSphere Console, API documentation, Cell compiler, and SSJ.
Windows release also includes Sphere Studio IDE (.NET 4.5+ required).

Sphere v2 API Documentation
« Last Edit: April 03, 2017, 12:39:43 am by Fat Cerberus »
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: minisphere
« Reply #1 on: January 25, 2015, 07:26:51 pm »
That's odd, I just got an email that Flying Jester replied to the topic, but there's nothing here...
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Flying Jester

  • TurboSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 1149
    • View Profile
Re: minisphere
« Reply #2 on: January 25, 2015, 07:42:13 pm »
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.

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: minisphere
« Reply #3 on: January 26, 2015, 09:58:43 pm »
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 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Flying Jester

  • TurboSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 1149
    • View Profile
Re: minisphere
« Reply #4 on: January 26, 2015, 11:41:33 pm »
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?

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: minisphere
« Reply #5 on: January 27, 2015, 12:10:24 am »
How would I do surfaces in script?  That definitely seems like something that should be native.
miniSphere 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Flying Jester

  • TurboSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 1149
    • View Profile
Re: minisphere
« Reply #6 on: January 27, 2015, 03:40:02 am »
It would be simple, just an object that has a UInt32Array, a width, and a height :)

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: minisphere
« Reply #7 on: January 27, 2015, 12:43:36 pm »
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 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: minisphere
« Reply #8 on: January 28, 2015, 10:51:29 pm »
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 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Flying Jester

  • TurboSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 1149
    • View Profile
Re: minisphere
« Reply #9 on: January 29, 2015, 02:28:31 am »
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

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: minisphere
« Reply #10 on: January 29, 2015, 10:32:23 pm »
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
  1. duk_push_global_object(ctx);
  2. duk_push_object(ctx);
  3. duk_push_int(ctx, 812);
  4. duk_put_prop_string(ctx, -2, "number");
  5. duk_put_prop_string(ctx, -2, "myObj");
  6. duk_pop(ctx);

...is quite literally equivalent to this:
Code: C
  1. 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 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: minisphere
« Reply #11 on: January 30, 2015, 10:45:49 pm »
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 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline Flying Jester

  • TurboSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 1149
    • View Profile
Re: minisphere
« Reply #12 on: January 31, 2015, 12:35:33 am »
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.

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2129
  • *MUNCH*
    • View Profile
Re: minisphere
« Reply #13 on: January 31, 2015, 12:18:26 pm »
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 4.5.10 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline N E O

  • Senior Administrator
  • Administrator
  • Hero Poster
  • *****
  • Posts: 583
  • Making it happen!
    • View Profile
    • Apollolux Digital Designs
Re: minisphere
« Reply #14 on: January 31, 2015, 01:05:21 pm »
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. :)