In case anyone hasn't figured it out by now, my new goal is to get Kefka's Revenge to run in minisphere 4.3 without modification.  As I've come to learn over the course of development, that game has some of the worst Sphere 1.5 code ever written, relies heavily on type coercion for function parameters, and requires pretty much perfect emulation of the Sphere 1.5 map engine to function properly.  If minisphere can run it unmolested, that speaks volumes for Sphere 1.5 compatibility in general.  Which is great, because that means there'd then be no excuse at all for anyone not to upgrade.

It was a particular challenge to emulate type coercion for map layer parameters.  minisphere supports named map layers (like Sphere 1.6), so any layer index passed as a string will usually be interpreted as a layer name, the lookup will then fail and cause an error.  Tonight I finally came up with a creative solution to that:

https://github.com/fatcerberus/minisphere/blob/master/src/engine/map_engine.c#L1630-L1643

If a string is passed, the engine first looks up the string in the list of layer names.  If that fails, it then uses strtol() to convert the string to an integer and performs an index lookup instead.  Only if THAT fails is the layer reported not found.

lol at Pokemon Uranium

You're doing an amazing job! It almost makes me want to work on my games again. But I'll save that for sometime early next year or in December. I'm in the process of buying my first house (which I'm sharing with my brother), I'll set up a game room, add my computer and when I find some time, I might just pick up Sphere again.

Sphere 1.5 typing for boolean parameters is odd:
https://github.com/sphere-group/sphere/blob/master/sphere/source/engine/parameters.cpp#L53-L74

Sphere converts numbers, strings, etc. to boolean but will throw if an object is passed (normally truthy).  For legacy support I don't think it's worth it to go out of my way to match those semantics exactly, normal implicit type conversion is more consistent and works fine for compatibility.  Another oddity is that parameters specified as integers get the implicit conversion, while floating point parameters are strict.

Sphere converts numbers, strings, etc. to boolean but will throw if an object is passed (normally truthy).  For legacy support I don't think it's worth it to go out of my way to match those semantics exactly...

And since it threw an error, there probably aren't any legacy games that would use objects in place of booleans.

Jesus, Kafka's Revenge, huh? Good luck getting that abomination to run perfectly. It had issues even between Sphere versions.

I noticed I had been getting undefined errors (kb) in my script, so I reinstalled everything and noticed the API had changed (or for whatever reason I had been doing something wrong in the first place and had somehow not noticed it). I'm unable to download the installer from the releases page on the Github repo. In Firefox, it just fails and in Chrome it says there's a network error. In order to download it, I need to go into the bash subsystem (Windows 10 insider) and wget it.

Yeah, I renamed 'kb' to 'keyboard' a few versions ago for clarity.  There might some other minor changes too, might be worth flipping through the documentation to double check.

Once minisphere 5.0 is released I plan to keep the API stable so that any code written for earlier versions will continue to run unchanged on later versions.  Not sure how feasible that'll be but I'd like to try at least.

Jesus, Kafka's Revenge, huh? Good luck getting that abomination to run perfectly. It had issues even between Sphere versions.

I know, which is what makes it such an interesting challenge.

Honestly I got bored, there were no more new features to add to the engine so I said "okay, let's try to make minisphere more compatible with horrible Sphere 1.5 code"

As a suggestion, could you integrate the terminal module into the engine itself so it wouldn't be affected by things like loops and normal keyboard input?

As a suggestion, could you integrate the terminal module into the engine itself so it wouldn't be affected by things like loops and normal keyboard input?

Hm... that might actually be possible to do.  Actually it would be great if the entire miniRT threader could be more seamlessly integrated so that calling system.run() would update threads automatically.  Something like how update/render scripts work in Sphere 1.x, but available engine-wide.  Thanks for the suggestion, I'll add a note to look into this when I get some time.

@Eggbert: For the time being when using the terminal module, you have an implicit dependency on miniRT threads, so to enter the event loop you need to call threads.join() (this may need some refactoring if you're not already taking advantage of the threads module - like I said, full integration with the built-in event queue would be nicer).

Refer to miniRT docs for how to use threads.

Thanks again for the feature suggestion, finally someone gives me a challenge!

Oh, alright. I thought it was handling threads itself already. And luckily I don't have to do any refactoring. My Personlib that I mentioned in another thread already makes good use of them. It wasn't an initial reason for creating the library but I was trying to figure out why updating/rendering was acting weird, and I noticed that I could use threading to my benefit.

Also, I'm not sure if it was like this in the original engine as well, but is it not possible to get a peron's spriteset's filename by doing GetPersonSpriteset(person_name).filename?

Also, I'm not sure if it was like this in the original engine as well, but is it not possible to get a peron's spriteset's filename by doing GetPersonSpriteset(person_name).filename?

I'm not sure, I'd have to verify against Sphere 1.5.  If it's missing, I'll add it.  There are a few legacy objects which support file name tracking and then others that don't, so I'm not 100% positive.  In any case that's a worthwhile feature to make standard for Sphere v2, in light of SphereFS being a thing, and would be easy enough to return a normalized filename since SphereFS already requires normalization per my specification for it:
https://github.com/sphere-group/pegasus/blob/master/design/SphereFS.md

In line with Eggbert's feature request above, I'm working on implementing better async support for Sphere v2.  The current design I have in mind is based on a single function, system.defer(), which works something like setTimeout() in browsers.  Basically this would be the beginning of introducing some sort of event loop binding to Sphere, which will be needed in any case if we ever want to have a WebSphere.

Also, I'm not sure if it was like this in the original engine as well, but is it not possible to get a peron's spriteset's filename by doing GetPersonSpriteset(person_name).filename?

So it turns out that the above should have worked, but clone_spriteset had a bug in it where it didn't copy the filename.  I'll fix it.

Little known fact: GetPersonSpriteset() returns a copy of the spriteset object and not the original one assigned to the entity.  One of the many oddities in Sphere 1.x I discovered through reverse engineering while reimplementing the map engine.  To save memory and avoid killing performance, minisphere only clones the spriteset structures and not the underlying textures--which works because Images in Sphere are read-only.