Skip to main content

News

Topic: neoSphere 5.9.2 (Read 522083 times) previous topic - next topic

0 Members and 28 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 2.1.6
Reply #960
Right now, single letters aren't accepted as valid commands, but I do want to implement that.  It gets tedious typing 'step' (or selecting it from history) over and over again. :)

For the most part I take inspiration from gdb for command naming, but a few of its naming decisions baffle me.  For example in gdb `step` is actually Step In, while Step Over is mapped to `next`.  This is weird to me, since it's been my experience that the vast majority of stepping done is Step Over.  In most cases with well-placed breakpoints you don't need to step into functions unless the code is really tangled. (the reason this matters is that it's quite a bit faster to type 's'+enter than 'n'+enter)

I will most likely rename `trace` to `backtrace`.  Even though the term is odd to me, it matches gdb and lldb naming and is an accepted term for a call stack listing. As for `print`, I was considering that initially, but hesitated: `eval` can execute arbitrary code with any number of side effects.  Someone using a command called `print` may not expect that.  That said, I'll probably do it anyway though for parity with gdb.

What's your opinion of the command line (see screenshot posted earlier)?  gdb's prompt is just "(gdb)", likewise for lldb, whereas I include the source file and line number.  I'm undecided on whether this is legitimately useful or just adds noise.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 2.1.6
Reply #961
I think the debugger having its own prompt name makes more sense when you have control of stdin, since many programs (in Unix at least) provide line-editing like features.

`print` in lldb does perform JITing in expressions via llvm.

In general if it were me, I'd take more inspiration from gdb than lldb. The latter tends to be much more annoying to use, since it's extremely verbose. The reasoning is that it's more orthogonal and descriptive, but in reality it just makes everything more work.

Most of the unusual names in gdb were just to give each command a unique but initial letter synonym. If you always call stack traces 'backtraces', you will always remember they are `bt` or just `b`.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 2.1.6
Reply #962
I implemented stack walking, yay!  You can now enter `frame <x>` to switch to a different function in the stack.  Future requests to print variables, run code, etc. will then use that scope.

This is actually coming together pretty quickly!  I do still need to implement source code listing and most importantly, breakpoints, and that should put SSJ pretty close to feature parity with the Sphere Studio plugin.  Heck, I might even be able to rewrite that plugin to use SSJ under the hood, to avoid having to maintain two debugger codebases. ;D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • FBnil
  • [*][*]
Re: minisphere 2.1.6
Reply #963
.. nice...

I managed to finally compile minisphere, but only after using http://download.gna.org/allegro/allegro-unstable/5.1.13/  (but I also removed all allegro libs from my debian, breaking allegro games, then make installed the new version)
I noticed that --game is not an option anymore, and I couldn't see why in the git log's, so I assume it is a bug?

Code: [Select]
fbnil@convoy$ strings msphere.20150610 |grep ^-- |sort >a ; strings msphere|grep ^-- |sort >b;diff a b
0a1
> --debug
3d3
< --game
6c6,7
< --windowed
---
> --version
> --window

fbnil@convoy$ comm a b
        --debug
                --frameskip
                --fullscreen
--game
                --log-level
                --no-throttle
        --version
        --window
--windowed

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 2.1.6
Reply #964
-game (single hyphen) should still be supported for legacy compatibility, however new-style --game is not, because I switched to the more Unix-y convention of:
msphere [options] <path>

This was changed in version 2.0.  I don't think it will accept an .sgm file on the command line though, due to a bug I haven't gotten around to fixing.  As a workaround for now, just pass the name of the directory containing game.sgm.
  • Last Edit: January 27, 2016, 04:00:58 pm by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 2.1.6
Reply #965
Here's another screenshot.  It's starting to look very mature now. :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 2.1.6
Reply #966
This may have already been addressed, but have there been any plans to add mp3 and/or midi support? I have it in Linux, fully updated as of yesterday.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 2.1.6
Reply #967
mp3 is impossible without relicensing minisphere as GPL (no thank you), and MIDI... I don't even know where to start with that.  For Windows I can probably just call into winmm, no idea for other platforms.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 2.1.6
Reply #968
Oh, alright. It was more a matter of convenience. I have Audacity, so converting oggs is no problem, and I have timidity installed, so I can just use a soundfont to render a midi file as an ogg.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 2.1.6
Reply #969
I think .ogg is better than .mp3 because it can play at lower bitrates with nearly the same quality, thus reducing filesize (especially useful for certain songs in midi or other soundfont formats).
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 2.1.6
Reply #970
That's definitely true in my experience - .ogg still sounds decent even down to 48kbps in stereo (the lowest bitrate the encoder will give you in "constant quality" mode) - try that with an mp3 and it'll be so full of compression noise as to be unlistenable.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 2.1.6
Reply #971
SSJ works on Linux too!
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 2.1.6
Reply #972
I just switched minisphere's UNIX build system from SCons to make.  Not autotools, I don't have time for that. :P  It's a hand-made makefile.  The makefile allows minisphere and GDK tools to be installed in /usr/bin as well:
Code: [Select]
make && sudo make install


Also, "make dist" will make a tarball.

From there it's a simple matter to run games from the command line:
Code: [Select]
sphere game.spk
sphere game.sgm


Or to debug them (note SSJ doesn't yet show source):
Code: [Select]
ssj game.sgm
ssj --pause game.sgm
(the debugger works with SPKs too!)
  • Last Edit: February 01, 2016, 02:27:44 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 2.1.6
Reply #973

I just switched minisphere's UNIX build system from SCons to make.  Not autotools, I don't have time for that. :P


The days when Autotools made sense are mostly gone. Supporting Unix no longer means supporting Linux, Irix, Solaris, HP-UA, AIX, etc., and ignoring the hoopla, most Linux distros are very similar. The only thing you really need to do is support prefixes.

The other main use of autotools was to smooth over different libc's, but again, those days are gone. Every system either uses glibc, bsd libc (which is very similar in API to glibc), or something that tries its best to look like glibc (like musl).

Re: minisphere 2.1.6
Reply #974
So since Oracle either stopped or will stop working on the applet system (though thanks to Oracle's crap security, it was pretty much dead in the water a while ago) JavaSphere is a no go there, and since doing JavaSphere from scratch would be effectively reinventing the wheel, do you think it would be at all possible to port miniSphere to Android? Looking around, it doesn't look like it should be too difficult to compile Allegro stuff for Android. I'm not familiar with Allegro (I've mostly just used SDL in the past), but I'll see what I can do. Keyboard stuff might be a bit tricky, if impossible, but mouse stuff could possibly be converted to swiping and touching. So while there might be a lot of Sphere games that either won't work at all, or will have to be heavily modified for Android, I still think it could be pretty cool.
  • Last Edit: February 01, 2016, 05:08:22 pm by Eggbert