For SSJ, to make it as efficient as possible to debug on the command-line, I think I want to go with 1- or 2-character commands, for example "s" to step, "st" for a stack trace, "v" to list local variables, and so on.  No prefixing commands with a dot or ! as that just slows down command entry.

I'm not sure yet how to handle locating sources for a game.  Cell can optionally include a source map if needed when building a game (this is very useful as it allows SPKs to be debugged!), but even that uses relative paths.  In Sphere Studio it's trivial to just resolve the relative path against the current project, but SSJ will need a command-line option or something to provide the location of the sources.

What features would you want to see in the debugger?  Keep in mind some things might not be possible until Duktape implements them in its debug API, but I'll make sure to note any requests regardless.

I would like a break command in the code to set a breakpoint. If the break command can have an identifier, to know which one breaked....

I don't know if anyone remembers the --explode switch you could pass to Cell to get an easter egg (specifically, a quote from the program's namesake), but I'm starting a tradition with SSJ where all the GDK tools will have this little secret.

For point of reference, sample output from Cell:

Code: [Select]

C:\Users\fatce>cell --explode
Cell seems to be going through some sort of transformation...
He's pumping himself up like a balloon!

    Cell says:
    "If only you'd finished me off a little bit sooner..."

And now, from SSJ:

Code: [Select]

C:\Users\fatce>ssj --explode
Release it, release everything! Remember all the pain he's caused, the people
he's hurt--now MAKE THAT YOUR POWER!

    Cell says:
    "Would you stop interfering!?"

Let nobody say I don't have lots of fun while programming these tools!

Also see this:
https://github.com/fatcerberus/minisphere/issues/56

Actually does minisphere even run on WinXP?  Defiant had issues a while back, I think I fixed it but I don't have an XP machine to test on.

I haven't got it to work yet on my XP machine. Doesn't crash, just loads up a dialog and then exits, can't see the error before it disappears.

Try running it in a cmd.exe console? That's usually the thing to do when errors pop up too fast to read.

So it crashes when it tries to create the window. I copied the data it contains in the technical stuff, let me know if anything else would help diagnose this.

I see you're using minisphere 1.7.4.  I was going to suggest upgrading to 2.1.6, but I think I know the cause of the bug: Your machine might not support OpenGL shaders.  minisphere currently requires shader support to run.  In the latest builds I added a fallback for that, but I didn't backport the fix to 2.1 because I figured it wasn't a practical concern.  Seems I was wrong.

I'll try running minisphere in my XP VM to verify my theory.

edit: Hm.  The last line printed out by minisphere 2.1.6 on my Hyper-V WinXP SP3 VM is:

Code: [Select]

Looking for a game to launch

Seemingly no crash, though.  Really weird.  I'll review the code for the "looking for a game" to see if I can find anything.

Interesting oddity I found: Cell doesn't work properly under XP either.  I tried compiling Spectacles with it, and was told "no Cellscript.js in input directory", which is patently false.  So it seems this might be file system-related.  I'll keep digging.

Sorry, I should clarify that I can load a game, doesn't matter which one, but it fails to load the window when launching the game, sorry for the confusion.

So it successfully runs the startup game?  That's quite strange then.

It successfully loads minisphere. It allows me to select a game, but then crashes there after. It doesn't load the game.

Good news everyone: I finally got Ubuntu 14.04 successfully installed on my laptop to dual boot with Win10.  What this means is that I can actively support the engine code on both Windows and Linux now (or Ubuntu, at least).  Now if only I had a Mac, we'd have the trifecta...

If I could get some official Ubuntu packages going that'd be great for exposure too, I think.

Yes, that would certainly help a lot. You have time until Allegro 5.x hits Ubuntu (at least, your unstable version with the code you need to get it compiled/running).
Also: Documentation documentation documentation.
From using it as node.js (sphere was a crappy node.js, but I could serve webpages)... hmm.. maybe not this one...
to debugger (good work getting it working!)
to using it like image magick (I have some turtle code I think lost it) read png, add text, write to jpg things. Read file, parse data, create graph...
to well... a game making software.
Bundle it with some small default examples (from pianola to slideshow, an rpg, a sidescroller, things like that)

I still need to get into the code to add the things I miss (like changing the spriteset directions labels to "swap" graphics) and test out if I finally can access the spriteset image to mix it (overlay different hair (processed through a color matrix) and such to generate spritesets on the fly).

oh boy oh boy... very good news...

Now if only I had a Mac, we'd have the trifecta...

If you personally invest money in a Mac, I highly recommend getting into iOS app dev at that point, since IMO that's the only thing a Mac can do properly that no other OS can come close to (basically the iOS equivalent of the C#+Visual Studio vs. Mono+MonoDevelop and/or maybe the wine vs. Windows debate).

I have to say I'm not liking Linux as a development environment.  It has all kinds of neat tools like valgrind (note: minisphere, Cell and SSJ all leak like a sieve ), and of course the package system makes it ridiculously quick and simple to install new stuff, but for everyday code maintenance I'd much rather have Visual Studio, bloat and all.

Doing everything from the terminal and using a text editor to edit source files feels like a massive downgrade after being spoiled by Intellisense.  I know there are IDEs that work on Linux, but... eh.  I think I'll just stick to Windows for primary development.