Hm, you're right about the mod music not playing.  I suspect another Allegro bug, I will look into it later after work.

Nice work, thanks!

Will try to get the git and compile it myself...

Forgot to mention: make sure you get the "unstable" 5.1 version of Allegro.

minisphere 1.2.2 is up, which fixes the BGM in Sully Chronicals.  I never bothered to implement map BGM, so that's why it broke.  Nothing to do with the MOD music at all, those work just fine.

Nice work, thanks!

Will try to get the git and compile it myself...

Forgot to mention: make sure you get the "unstable" 5.1 version of Allegro.

So I decided to try to make my ancient Pokémon GoldenSky/SilverSea project compatible with minisphere. This was basically my first big project, and where I gained learned the bulk of my scripting experience. And you can tell - the code is a mess all over.

Along the way, I noticed a few interesting things:
I declared var Font, var WindowStyle, var Surface. Needless to say, this worked in the original Sphere but minisphere complained because the objects are in use. I got this error, which baffled me until I finally figured out what was going on:

Code: [Select]

JS Error: TypeError: invalid base value

After fixing those (and also converting the used MIDIs to Ogg files), I was pleasantly surprised to see it RequireScript() through my dozen other script without complaining whatsoever. Awesome.

However, now I've stumbled across another difference between Sphere and minisphere: GetKey() is not aware of KEY_CTRL. Either that, or GetKey() doesn't return key codes at all. This means you cannot get past the menus. I filed a bug report.

Yeah, that "invalid base value" error from Duktape is the bane of my existence.  What it means, specifically, is that you're trying to access a property on a variable which is not object-coercible (only null or undefined, in practice). It could at least tell you the name of the variable you're trying to access (SpiderMonkey does), but instead all you get is a vague "invalid base value".  Nothing I can do, unfortunately.  I'll have to file an issue on the Duktape repo about it.

I declared var Font, var WindowStyle, var Surface. Needless to say, this worked in the original Sphere but minisphere complained because the objects are in use.

I have no idea how that ever worked.  By definition when you do that you're overwriting (or at least shadowing) the prototype on the Font constructor, so everything should break.  Yet somehow in Sphere that works normally... very odd.

Original Sphere never exposed any Font, etc. constructor to the scripting side of things, as far as I'm aware.

...Actually, since my code was crappy, the only thing I did with the Font variable in particular was this:

Code: [Select]

var Font;

Then I proceeded to never use it. So I doubt it had any bearing on the actual existence of var Font.
The others were used, however, and that made it crash. In minisphere, I mean.

Speaking of crappy code, I discovered another bug thanks to that "Crap RPG" you posted a while back: minisphere's text rendering didn't handle tabs properly.  It tried to render the tab character directly instead of inserting spaces and didn't even honor it as a word break for purposes of word-wrapping.  It was also fixed in short order.

minisphere 1.2.3 is out, with a bunch of fixes for bugs found by DaVince.

Lots of fairly important bugs fixed, too, especially (for my current project) the hidden layer for obstructions one. I had just settled for fully transparent tiles, now i can actually make them visible in the editor

Nice work. I love how quickly you always manage to fix these.

mezzoEmrys: if you find any bugs, please report them? The layer bug could have been fixed earlier if you had filed a bug, I would say. Lord English is really doing a great job with fixing these.

I just realized I may be able to fix the "invalid base value" issue when variables are declared overwriting Sphere constructors.  I don't actually have to--it's a very bad practice I don't like to condone, but Duktape's error message for it is so obtuse that working around it is actually preferable at this point.

The issue arises because minisphere stores internal metadata properties in the object prototypes.  So when you declare a variable named, say, Font and then call a function which works with Font objects (e.g. GetSystemFont), the engine tries to access the Font prototype (this is why there is no line number--the error happened on the native side), which fails the same as if you did this in script:

Code: (javascript) [Select]

var Font; var foo = Font.prototype;

To elaborate on that: the boundary between native and script in Duktape is very thin.  Duktape's bytecode interpreter internally calls many of the same functions its public API does.  That's the reason why half of the Duktape API is macros and a big reason it can be as fast as it is.

Luckily Duktape also has this thing called the "stash" where you can store JS objects out of band such that they won't be garbage collected but are not otherwise accessible from script.  I could keep the object prototypes in the stash so that, if Font.prototype itself became inaccessible, the engine could still access it internally through the stash.  This would be enough to stop the errors, I think.

Hey guys, glad to see work being done on new versions of the Sphere engine. I haven't played around with it yet, but does minisphere have all the same built in functions as Sphere has? IE. Can I follow old sphere tutorials or is there a new wiki/tutorial area specific to MiniSphere?

minisphere is for all intents and purposes fully compatible with Sphere 1.5.  There may be a few obscure functions missing and the type checking for function parameters is stricter, but other than that anything you can do in one is done the same in the other.

minisphere also has a ton of new functionality not present in Sphere--you will have to look at minisphere-api.txt to find out how to use the new stuff.