So I got minisphere building on OS X again.

Same as last time, it just locks up hard when it starts up. I know that I have no startup folder or games folder, but still...

EDIT:

Nevermind, it deadlocks even with directories nicely in place. I'll investigate.

There's a check in place, if there's no startup folder you're supposed to get an error message like the one pictured in this screenshot.  Maybe OS X and Allegro don't get along?

minisphere only worked with the -game parameter. I just used my Sphere Studio. Building it was easy, I just didn't know how to start running a game. The startup game had consts and so it failed, and dragging a .sgm onto the executable didn't run the game.

@LordEnglish: yes, I meant RAM. .NET apps use the CLR and .NET runtime which are memory hogs, but if I account for that I still get about 20+MB's RAM usage out of it... so it's still a memory hog (but I'm not really going to worry about that, it's just a curiosity).

minisphere only worked with the -game parameter. I just used my Sphere Studio. Building it was easy, I just didn't know how to start running a game. The startup game had consts and so it failed, and dragging a .sgm onto the executable didn't run the game..

Does drag-and-drop work with Sphere 1.5?  Last time I tried I thought it didn't work, so I've always just opened stuff in Sphere Studio.  I'll have to implement that now.

It's not the startup folder apparently, it's the system folder. I opened an issue, you are reading the system font without checking that it exists (maybe more things later, that's where it errors out).

It's not the startup folder apparently, it's the system folder. I opened an issue, you are reading the system font without checking that it exists (maybe more things later, that's where it errors out).

Yeah, there's a gross lack of sanity checks in here.  You wonder how I implemented this all so fast, well, here's your answer.

I'll look into it.

Edit: Found the issue.  There are no checks whatsoever in al_load_rfn_font() despite all my other loading functions having ample error checking.  The crash is because it's trying to read from an ALLEGRO_FILE* that is NULL (because the file didn't exist).

Does drag-and-drop work with Sphere 1.5?  Last time I tried I thought it didn't work, so I've always just opened stuff in Sphere Studio.  I'll have to implement that now.

Well, Sphere was able to do this magical thing called "registering a filetype", I couldn't seem to do this easily in .net but if I implemented drag and drop, I was able to set the Engine.exe of SSFML to open on default for any .sgm related files and it worked. I can play games in SSFML by double-clicking the .sgm game icon. This is a feature I want to add to Sphere Studio too.

Well, Sphere was able to do this magical thing called "registering a filetype", I couldn't seem to do this easily in .net but if I implemented drag and drop, I was able to set the Engine.exe of SSFML to open on default for any .sgm related files and it worked. I can play games in SSFML by double-clicking the .sgm game icon. This is a feature I want to add to Sphere Studio too.

I think that was something that the installer itself did.

Drag-and-drop is much simpler, fortunately.

I think that was something that the installer itself did.

File->Options->Register filetypes. But, it doesn't seem to list .sgm, but it does have .spk.

That reminds me, at some point I have to add SPK support to minisphere.  That should be fun...

SPK support isn't that bad. It's extremely simple and uses zlib.

I would recommend for simplicity having the engine, when told to `run' an SPK, unpack the SPK into a subdirectory of your engine's root and run the game from there.

Or just don't do SPKs. It's a pretty silly format to begin with.

I would recommend for simplicity having the engine, when told to `run' an SPK, unpack the SPK into a subdirectory of your engine's root and run the game from there.

Or just don't do SPKs. It's a pretty silly format to begin with.

I kind of like the idea having a single file to distribute a game, and I found out I don't even have to unpack it to disk--Allegro lets me open a buffer in memory as a file (sort of like a memory mapped file but in reverse...) that I can pass to loading functions.

Of course, if we're being honest, if I weren't trying for near-1:1 Sphere compatibility I would probably just use zip instead of SPK... Well, I'll see what happens.  Either way it's not a priority for a while at least.

(Sort of) new feature: minisphere displays internal FPS when the framerate is throttled, as by calling SetFrameRate().  This helps to differentiate skipped frames from actual slowdown.

I still wouldn't mind having something like an spk2 format which is really just a zip or tarball you can associate with Sphere.

Nice work, by the way. And yes, you could drag an SGM over engine.exe in 1.5. Used to do it a lot.

@Radnen:
Let me just say that the SSFML testbed has been invaluable in filling out the Sphere API.  I'm almost at the point of being able to run all the non-map-engine tests, there's now only 2 or 3 that error out due to missing APIs.  Most of my implementations have gone off without a hitch and produce identical output to SSFML and Sphere 1.5 (outside of the speed tests, which seem universally faster than Sphere 1.5)--except for the surface test.

Here's the thing: I'm not actually sure what's wrong in my implementation because I can't decipher the surface test code.  It creates 4 surfaces and then proceeds to juggle them like crazy, so I don't know where minisphere is failing, but clearly something is screwed up, as you can see in the attached screenshot.  The green-tinged versions of the Blockman sprite are missing, and the whole bottom row is just the green blocks without the rotated silhouette...