Okay, so the downloads repository wasn't really ever completed, partially because there are so many Sphere games to sift through, old and new. I'd wanted to test them all out and upload/document the ones that functioned, but in the end this was way more of an undertaking than I thought it'd be.

So I'm left with a TON of neat and intriguing little Sphere games and projects archived on my hard drive. I figured I'd upload and share them all without bothering to really go through them all in that much detail. There's a lot of stuff out there, after all.

I'm entirely certain that I'm still missing a lot of Sphere games. For example, I'm missing a lot of the stuff that Radnen, Flying Jester and Beaker have made.

The games can be found here: https://drive.google.com/open?id=0Bw-4UFVty4u1TWtINDZLNDB4TUE

If you have Sphere games that I'm clearly still missing, please upload them here? I love keeping an archive of all this stuff.

Oh my god, I'm really happy about rpgmaker.net right now...

https://rpgmaker.net/games/?engine=2

There are so many games. Finished games, at that. This is excellent, I'm getting them all and I want to feature them on Spherical more prominently somehow. Having a showcase of especially finished games for this engine is a really good thing.

Also, I never realized just how productive some of the members here have been over the past years.

Unfortunately, a number of my better tech demos (including Attack! and Organ Grinder) I never actually released, and they are completely lost now

But it's amazing that you saved my SimCity attempt, that's a real trip back in time.

This is a ginormous collection of stuff; I don't even know where to start.  For now I'm just cherry-picking stuff to test that sounds interesting.

Dragon Town errors out under miniSphere apparently due to a race condition, but I don't understand why.  What I know so far: The render script depends on a tile cache which is set up in the update script, but the render script gets called first, leading to an error.  However, Sphere 1.x calls the render script first too,, so I can't figure out what's different between the two engines.

So I'm just going to throw this out here--miniSphere breaking compatibility with every major release is hardly unprecedented: many of the games in this collection not only won't run in miniSphere, but they don't run on Sphere 1.5 either, due to missing functions, system scripts, or sometimes even both.

Here's an actual compatibility issue I found: Pokemon GS/SS has collision issues under miniSphere.  The tile movement engine over- or undershoots, leading the character to collide with walls on the tile above or below.  I know I fixed a similar bug in Blackfoot that made some of the block-pushing puzzles unwinnable (this was an interesting case, as it demanded pixel-perfect emulation), but it seems it's still not 100% accurate.

Pokémon GS/SS has collision issues? That's funny - I was actually recently working on that engine a little bit for fun and it seemed fine then. Maybe it's that old included version that has issues. In any case, the tile engine in that was very bad to begin with as I could never *quite* figure out how to make it behave, especially when you start running.

And yeah, there's a LOT of broken stuff in there. Some only likes to work on very specific Sphere versions, and with other stuff I really have no idea why it is the way it is - I haven't moved any files around in projects, myself.

By the way, a lot of Beaker's games refuse to run properly, usually because of one missing function in the map engine. (About layer scaling, I believe.) Worth supporting?

By the way, a lot of Beaker's games refuse to run properly, usually because of one missing function in the map engine. (About layer scaling, I believe.) Worth supporting?

Yeah, he seems to be the only person that ever made use of those.  I'd have to look into how difficult it would be to add.  I believe the map engine is coded with the assumption that all layers line up, but then again, parallax layers can already have different dimensions as the rest of the map, so maybe it won't be too hard.



edit: Regarding Dragon Town: It turns out that Sphere 1.x in fact DOES call the update script first; the reason I didn't realize this is that the behavior is kind of an accident of circumstance and isn't obvious just from quickly reading the code.  Here's Sphere's map engine loop:
https://github.com/sphere-group/sphere/blob/master/sphere/source/engine/map_engine.cpp#L3942-L3998

Note that the order of the calls is ostensibly Render -> UpdateWorld -> ProcessInput, so I implemented the same in miniSphere (the code of which is incidentally much simpler due to better internal planning):
https://github.com/fatcerberus/minisphere/blob/v4.5.11/src/minisphere/map_engine.c#L2979-L2984

However, look again at Sphere's frameskip logic:
https://github.com/sphere-group/sphere/blob/master/sphere/source/engine/map_engine.cpp#L3956-L3973

m_NextFrame is initialized to the current time when the map engine starts.  Which means actual_time is always equal or greater than that and therefore the first frame will always be skipped.  This shifts the order of processing such that it goes in practice UpdateWorld -> ProcessInput -> Render.  And thus my emulation was imperfect.  Easy enough to fix, thankfully.

Here's an interesting breakage: Kamatsu's Supa Koopa Troopa.  This one took me a while to figure out and I probably wouldn't have been able to without a debugger (because I don't say it enough, SSJ is the best thing ever )

There's a map glitch in this game where the left half of the background is cut off, but that's just cosmetic.  The actual breakage has to do with differences between the Duktape and SpiderMonkey JS engines.  Specifically, Duktape doesn't keep track of source code for functions, causing this check in Kamatsu's class library to fail:

Code: (javascript) [Select]

if ((ancestor instanceof Function) && (value instanceof Function) &&
	ancestor.valueOf() != value.valueOf() && /\bbase\b/.test(value)) {

It checks whether the code for the class constructor contains the word "base" anywhere.  If not, then it ends up extending Class directly rather than the specified class.  Which causes the base class constructor not to be called and in turn, other weird untraceable bugs.  There's literally no way for me to fix it unless Duktape adds function source code tracking.  Thankfully, this kind of class library isn't needed nowadays anyway, since you can just use ES6 which has classes as part of the native syntax.

Damn, that sounds incredibly specific. Sounds more like a thing to work around in the game itself.

Speaking of backgrounds being cut off, I have a bug with fullscreen miniSphere where the first image that's displayed/FlipScreened will be cut off. Only the bottom left part of the image will be shown, presumably just the part that matches up with the game's original size before the window is resized into fullscreen.

It happens with literally only the very first image that gets shown on the screen, and looks like the attached image. It's happened for every single game that does this.

That looks like a clipping bug--I would have to check into the logic for setting the clipping rectangle, but it's very possible your hunch is right and it has to do with the window resizing.  Scaling was tricky to implement in miniSphere because a scaled window actually runs at a higher resolution--the engine multiplies a scaling transformation into the screen matrix to stretch the image (which is what causes those weird gaps between tiles in fullscreen sometimes--the texture gets interpolated and bleeds into adjacent tiles).  Clipping is relative to the screen, so setting it correctly requires some manual transformation:
https://github.com/fatcerberus/minisphere/blob/v4.5.11/src/minisphere/screen.c#L176-L186

If the scaling factor or letterboxing is changed without recalculating the clipping rectangle, it would cause issues like the one you mentioned.

That sounds like it makes sense, especially since it doesn't happen when run in windowed mode with Spherun.

This is pretty awesome. I lost a lot of my code and resources a long time ago (glass of milk + laptop + seizure = spilled milk and dead laptop) which is a shame. I had a lot of Sphere resources as well that unfortunately aren't in your zip file or the repository in general, so they're pretty much lost as far as I know, like that synchronous terminal I posted about in the old forums. Thank goodness for Dropbox now.

I'm still disappointed that I lost my copy of Onigiri Sunshine, one of kamatsu's competition entries. I've been through multiple computers and a hard drive failure since then, so I doubt I'll still find it lingering anywhere.

@mezzo: I think I saw a copy of that in here actually.  No idea how old it is, though.

Yeah, the collection is kinda hit and miss, because I lost some of the games or never even downloaded some when I did have the chance. I'm glad it's still useful to you guys. Kinda wish I had preserved more.

Really, if you look at Sphere as a whole, a surprising amount of stuff has been done with it by a surprising amount of people. It's just never been properly preserved, and I kinda want to make sure it is, and that Spherical as a whole gains a platform to upload your games to and have them stick around permanently. (Hence the Public uploads folder on the shared Google Drive, although no one ever used it, so obviously something better must be put into place )