Look what I got running!

It was a pain because a lot of the map scripts included extended characters, which confused Duktape (it expects valid UTF-8 always), so I had to have the engine re-encode the embedded scripts on load.

Amazing. Great work. I need to try this out right away. When the new release is out. Heh.

Amazing. Great work. I need to try this out right away. When the new release is out. Heh.

You got your wish--1.1.4 is posted, with a few other nifty fixes.

As for KR, it's a very interesting testcase indeed.  You can get it to run, but it requires a bunch of minor edits all over the place.  You'll find that there are a lot of lines like this:

Code: (javascript) [Select]

SetPersonLayer('turtletrainer', '3');

Which of course breaks in minisphere, and probably Sphere 1.6, because both support named layers.  If this were consistent, I could write it off as the game making misguided assumptions about the underlying engine... but then I see just as often:

Code: (javascript) [Select]

SetPersonLayer('roofus', 3);

A correct invocation.  And this kind of thing happens EVERYWHERE.  I'm beginning to think Keith had a weird sense of humor and did this kind of thing on purpose just because he could.

Considering how the code is full of jokes (like new retard()), that wouldn't surprise me. Then again, he also told me that he was shitty at coding. KR was the project that helped him learn, and he didn't fix old code. That really turns things into a mess.

And thanks a lot for the new release.

Edit: yep, this game is pretty broken. After fixing a line of SetPersonLayer() and saving a PNG camouflaged as a BMP as an actual BMP, the game runs, but there are lots of problems. Can't enter most doors, can't talk to most people. I'm just impressed it's working this well besides those problems.

Did you notice the cleanup I did on the error screen?  The error location is now set off from the message, which should make it easier to see the location of an error at a glance.

Edit: yep, this game is pretty broken. After fixing a line of SetPersonLayer() and saving a PNG camouflaged as a BMP as an actual BMP, the game runs, but there are lots of problems. Can't enter most doors, can't talk to most people. I'm just impressed it's working this well besides those problems.

Actually, on further testing... I think I broke something.  Person-person collision is screwy.  I definitely remember being blocked by those NPCs on my initial playtests, but now you can walk right through most of them...  which also means you can't talk to them because the engine does a collision check to find persons to talk to.

Edit: Ah ha!  I figured it out.  This is a long-standing engine bug that it took this horrendously buggy game to uncover.  I must have been mistaken about the collision working before, that was probably one of my Sphere 1.5 tests before I got minisphere to run the game.  Anyway, the bug is that minisphere doesn't normalize the spriteset base.  Sphere does, and it seems KR has several spritesets with degenerate bases where x1 > x2 and/or y1 > y2.  This causes the obstruction checks to fail.

It took me forever to figure this out because I was operating on the assumption this was a layering bug.  Not even close!

See, this is what's made minisphere what it is: no matter how broken my test game is, I work on the basis that, if it works properly in Sphere but not in minisphere, then the issue must be on my end (I was perhaps too hard on Blockman earlier, but regardless, this applied there as well).  I'm still very dedicated to compatibility.   Of course, there are two cases where I draw the line: I won't relax type checking for API arguments (you're calling into C code, the engine has every right to police it), and I won't emulate bugs.

But if a bug means a game can be playable... It's a tricky situation. You want a clean version of Sphere with no bugs in it, but if you have to incorporate a bug to make a game work... it's not always straightforward isn't it? But then again I guess you could call those bugs "features".

It can sometimes be a very fine line to walk, I won't deny that.  For example, the color-cycling trick in Sphere is based on what is technically a bug (namely: byte overflow in color components isn't checked for) and when it was brought to my attention I had to think long and hard whether to emulate it.  Ultimately I chose not to in the name of consistency (CreateColor can reasonably be considered "canon" and that clamps the values), which of course breaks compatibility.  However, it's a trivial enough thing to work around (you can do modulo arithmetic yourself), so I don't consider it a dealbreaker.

I guess this is the reason browsers have quirks modes...

Hm, so it appears minisphere's handling of triggers is borked, which is why you can't enter buildings in KR.  Unfortunately this doesn't surprise me, that was one area I didn't do much in-house testing on.  My test map for Specs does include a trigger, but it's only one.  KR tends to cluster them together, and it seems the activation rectangle for individual triggers is so small for whatever reason that they often don't activate at all.

Edit: I did some runs through the debugger.  The issue is a weird race condition between KR's custom movement code (I have to give whoever programmed the movement system credit, they basically independently invented Lithonite) and an optimization in minisphere where I only check for trigger activation if the input person has moved since the last frame.  For whatever reason the person almost always reports as not moving.  I'm not 100% positive yet, but I THINK the root cause is that the game confuses the engine by constantly detaching and attaching input.

Going to make a new post for this because I want it to be seen.  This was quite an interesting pursuit.

Got it!  I was right, KR detaching and reattaching input during custom movement throws it off.  Currently minisphere has an optimization (premature, as I now see) where it runs a trigger check if and only if two conditions are met: 1) There is an input person, and 2) that person has moved since the last frame.  In this case, when the engine runs the trigger check, no input is attached because the game reattaches it in a person script.  And that script runs on the frame AFTER all movement has ceased:

Code: (javascript) [Select]

QueuePersonCommand(thePC.name, COMMAND_MOVE_NORTH, false); // <-- is_immediate is false, suspends command execution until next frame
QueuePersonScript(thePC.name, "trigtest(); if (!Kbusy && !climbmode[0]) AttachInput(thePC.name); walking=false; ", false);

Note the trigtest(); in the reattachment script.  This would normally mitigate the issue, but the function is bugged.  Long story short, this game is very, VERY lucky to be playable at all, even in vanilla Sphere.  The ONLY reason it works in vanilla is because Sphere always walks the trigger list on every update, even if the input person is stationary.  It looks like I will have to do the same if I want to support this corner case.

So yes, this game is broken, but the fact that it works in the original engine makes it interesting: In many cases it's hanging on to its stability by a thread, so the smallest difference in engine behavior under the hood can break everything.  If ever there were a testcase to punish premature optimizations and incomplete reverse engineering, this is it.

I'm  not sure trigger checks need this kind of optimization. I'd let it check as often as I want, after all it's hardly a bottleneck. The more I get away with in native, the better.

What I am interested in here is the reattachment of the player. When the input is not attached, triggers are not executable through the engine (I end up calling ExecuteTrigger() or somesuch). If the idea of the above is to trigger a trigger a frame before the input is attached I'm not sure how that goes. I guess it's the re-attachment of the player that suddenly executes the trigger because the check is indeed being made all the time, every frame. Once it sees the input is reattached, bam, it's triggered. I think that's kind of clever, really.

Yeah, I'm not sure what the purpose of the trigtest() function is there, it's completely redundant as Sphere will run the trigger anyway post-attach.

And now that I think of it, I don't think it was an optimization after all: the same condition ("did the input person move?") covers zone processing as well.  And there it's 100% necessary, otherwise the zone script will keep firing even if the player stands still.

So yes, this game is broken, but the fact that it works in the original engine makes it interesting: In many cases it's hanging on to its stability by a thread, so the smallest difference in engine behavior under the hood can break everything.

This actually explains perfectly why certain segments of the game started breaking randomly on later Sphere versions. For example, I remember the couch moving scene later on in the game sometimes working, sometimes not.

It'd probably be better to fix the game here rather than your code specifically, especially if it means performance regression for all other games. I mean, the game needed some fixes anyway.

It'd probably be better to fix the game here rather than your code specifically, especially if it means performance regression for all other games. I mean, the game needed some fixes anyway.

In this particular case it's not a big deal, as you'd incur the performance hit, such as it is, of constant trigger checks anyway as long as the PC is moving (which is why I now suspect it wasn't an optimization at all, just an oversight).  The only speedup to be had from this is when the player is standing still, which truth be told, isn't very useful.

However, in the general case, I agree with the sentiment.  I'm not about to bend over backwards to get this game to run as-is, but if it should uncover what is clearly an engine bug, I do want to try to fix it.

Trivia: Technically my trigger implementation isn't fully compatible with Sphere's, as I found out last night when comparing the two engine sources.  Sphere tracks current trigger activation per-person, whereas minisphere only has a single "current trigger" variable.  What this means is that, in Sphere, if the PC steps on a trigger which causes input to be attached to another person, if the input is later returned to the original person, the trigger won't reactivate.  In minisphere it would because trigger activation is tracked globally.

Edit: Yeah, even with the trigger and zone fixes I just committed, there's no way this game is going to run in minisphere without some serious edits.  There's way too much of passing strings to APIs expecting numbers.  Regardless, it looks like I've fixed all of the actual bugs: The game looks like it would be playable if not for all the type errors.

Okay, v1.1.5 has been posted, and with it I've decided to declare minisphere 1.1 stable.  Most of the KR glitches are fixed by this release and outside of that my tests haven't uncovered any showstoppers, so I'm thinking it's time to retire v1.0.  The performance improvements in 1.1 alone are worth the upgrade.  I'll leave 1.0.11 in the downloads repo, but minisphere 1.0 should be considered no longer officially supported and won't receive any more fixes.

Go crazy!

(Note that I didn't bump the version to 1.2, as I was originally going to do for stable releases.  I decided it was an unnecessary formality.)