I'm finalizing building the binaries for minisphere 3.0.0 to be released on the 28th.  If anyone has encountered any issues with the RC, now is the time to speak up. 

I've been using this version and have not ran into any serious issues. I think I got it to crash once, but I haven't been able to reproduce it... I'll run stress tests later in the week and get back to you.

minisphere 3.0 is finally out!   It's worth noting that this is minisphere's birthday - version 1.0, the first version to be almost fully compatible with Sphere 1.x, was released a year ago on this day, March 28.  Such a momentous occasion warrants a momentous release, and minisphere 3.0 delivers!  New in this release: The SSJ command-line debugger, TypeScript support, a fully documented miniRT, many, many undocumented bug fixes, and official support for Ubuntu Linux!

I decided at the last minute to bundle Sphere Studio in the (Windows) release after all.  And a note to users of 3.0rc6: Download 3.0.0.  As I suspected would happen, I had to make a few last-minute bug fixes before the release.

Anyway, go download minisphere 3.0.0 and have fun!  See the OP for a list of breaking changes.

edit: I forgot to mention, minisphere is also available on Ubuntu via PPA:

• https://launchpad.net/~fatcerberus/+archive/ubuntu/minisphere

To install minisphere from PPA, open Terminal and run the following commands:

• sudo add-apt-repository ppa:fatcerberus/minisphere


• sudo apt-get update


• sudo apt-get install minisphere

Just built 3.0 in Linux, and with few exceptions (like it segfaulting if you run it with a nonexistent folder as the game argument) it seems to be running perfectly.

If you use spherun instead of minisphere it will run windowed by default since that's used for debugging where fullscreen is generally undesirable.  This enables the debugger and other development features so there may be a slight performance hit, but it shouldn't be significant.  Do note however that spherun is designed for command-line use and therefore requires a game path--it won't run the startup game automatically.  What I can do for 3.0.1 is have the engine save the window/fullscreen state from the last run, perhaps per-game (spherun would still default to windowed).  That wouldn't be too difficult to do.

I'll look into that segfault, thanks for testing.

Oh alright, sounds good. Also, is it safe to add system scripts (say, from 1.6) to usr/share/system, as long as they don't conflict with the files already there, to provide compatibility with games already written for 1.6?

Yeah, that should be perfectly fine to do--the only thing in there is Sphere 1.5 scripts, modern stuff like miniRT is placed elsewhere (in /usr/share/minisphere/commonjs).  Just be aware that minisphere doesn't implement the full 1.6 API so depending on what the 1.6 scripts do, some things might not work.

That's fine, I didn't use 1.6 much anyway. I guess I'll be using minisphere from now on, writing code with Visual Studio Code, doing images with GIMP (or the original editor), and spriteset and mapping stuff with the original editor as well.

Make sure you test out SSJ at some point too.  Sphere JS debugging = awesome.

I've never really used built-in debugging tools, and have generally just gone with printf. For my imageboard server, I wrote a wrapper for the main printf function.

Code: [Select]

printf(n int,format string,a ...interface{})

with 0 being startup and critical info/errors, 1 being warnings, and 2 being benchmarking and less important info.

Oh, and n is a constant set by the Makefile

You can do a lot with printf, it's true, but at some point it's just not enough.  When I was using Sphere 1.5 to develop Specs, there were so many battle engine bugs I hit that took me hours to find even with strategically-placed Abort calls that would have taken literally 5 seconds to find with a debugger.  In a simple codebase, instrumentation is enough, but once it gets complex enough a stepping debugger is very welcome.  Particularly valuable is being able to walk up the callstack and see variables at each level, which is very difficult to emulate with prints.

Ah, alright. I'll definitely look into that then. Is there any way to set breakpoints without Sphere Studio, or does that not matter?

Oh wow, never mind, this is pretty neat

Yeah, "bp file:line" will set a breakpoint and give you its ID number which you can use later to clear it.  Run "man ssj" on command line for a full list of commands (or just "help" in SSJ works too).

@Eggbert: I fixed that segfault you mentioned.  I had done some last-minute refactoring to the display code to support letterboxing, and it seems I introduced a crash bug in the process.  It will be fixed in 3.0.1.