@FJ:
I'm using the Allegro monolithic library, which is about a 2.25MB DLL and includes all Allegro functionality, including audio (if you're using more than about 3 Allegro components, the monolithic is actually smaller than the individual DLLs).  The minisphere executable at current is around 550KB.  That's literally the entire engine in 2.8MB.  Even if you count the system directory (which I guess technically you should? Full Sphere 1.5 compliance and all): 3.89MB.

Admittedly not a huge difference--ignoring editor.exe and SciLexer.dll, but including config.exe and the system directory, Sphere 1.5 is 5.25MB.  Still, minisphere is smaller, so I think the name still stands!

@Radnen:
Very odd.  Give me a code sample that you tried that caused the error, I'll look into it.  It runs Spectacles very well, so...

@Radnen:
Very odd.  Give me a code sample that you tried that caused the error, I'll look into it.  It runs Spectacles very well, so...

Well, it does it for anything, even if I use dll files, etc. how are you playing games with it? Do you drag them on to the executable or do you put everything into the startup folder? Because the startup game also did the same thing.

You can put the game into the startup folder, but actually, all you have to do is point Sphere Studio at minisphere and it'll work.  It accepts the -game commandline argument just like 1.5 and SSFML does.

So did you get it to run anything?  Specs uses a good chunk of the API, so I'd expect there must be at least some games out there that work.  Although most games use the map engine, so perhaps not...  Note that the startup game won't work even if you remove the consts as I didn't implement ExecuteGame et al. yet.

Anyway, I've just started on the map engine and am currently trying to get In the Steps of the Blackfoot running.  That was the game that introduced me to Sphere, so I kind of have a soft spot for it.

Note that the startup game won't work even if you remove the consts as I didn't implement ExecuteGame et al. yet.

ExecuteGame is very challenging to implement with most JS engines. It's extremely difficult, or just plain impossible for V8 to cancel execution of a script from native. I am unsure of how difficult it is with SM, although it seems to have better support for such an idea. I would think that JS engines not expressly intended for a web browser may actually have an advantage here.

I basically have just written this part of the API off. It's a cool feature, but ultimately not that useful. I don't lose much sleep knowing the startup games don't run.

That's the awesome thing about Duktape--everything is done in-engine, and the call to game() is protected, meaning all I have to do to bail out of script execution (including infinite while(true) loops!  Assuming they call FlipScreen anyway...) is throw an exception via duk_error().  This drops me off immediately after the duk_pcall, with the exception on the stack.  This is the same mechanism I use to bail out when the game window is closed, and it's awesome.

I basically have just written this part of the API off. It's a cool feature, but ultimately not that useful. I don't lose much sleep knowing the startup games don't run.

Not so fast! There is a... compromise. You could spawn an entirely new instance of Sphere. So you would have two games running simultaneously, but if you minimize one and play the other you should be fine. I'm intending to do this with SSFML.

I basically have just written this part of the API off. It's a cool feature, but ultimately not that useful. I don't lose much sleep knowing the startup games don't run.

Not so fast! There is a... compromise. You could spawn an entirely new instance of Sphere. So you would have two games running simultaneously, but if you minimize one and play the other you should be fine. I'm intending to do this with SSFML.

You mean an OS-level instance of Sphere? Like with `exec`?

That's an option. I for one would far prefer the engine actually be capable of starting and stopping, but so far that has been difficult.

I know that in Posix systems it would even be simple to startup a new Sphere process and assign it to a nohup parent process...hmm...

You mean an OS-level instance of Sphere? Like with `exec`?

Precisely.

So out of morbid curiosity, I ran SSFML's startup game in minisphere and tried the surface fill test, one of the few things in there that actually works.  My results: ~1400 FPS.  Screenshot attached as proof.

Of note: The main menu runs at around 700FPS on the same machine.

Laptop is i5-2450M with 4GB RAM, Win8.1 Pro x64.

Edit: In the interest of completeness, I also ran the test on Sphere 1.5.  It barely broke 550 FPS on the same machine.  Honestly, my experience so far has been that minisphere actually outperforms Sphere 1.5 in all cases.  At least with the standard32 plugin, anyway.  I should probably test it with the OpenGL plugin at some point...

So out of morbid curiosity, I ran SSFML's startup game in minisphere and tried the surface fill test, one of the few things in there that actually works.  My results: ~1400 FPS.  Screenshot attached as proof.

Yep, you have better surfaces, even better than 1.5. But with HW surfaces in SSFML I could do 6500 fps on that same screen (~900 in Sphere 1.5 for comparison). I do 700 fps on that screen in SW (so worse than Sphere). But, only when many HW surfaces and features were used the fps started going way way down, it's like SFML just can't handle more than 2 or 3 surfaces on screen at the same time. I find this odd since I use hardware surfaces for tile animations in the map engine and it's really fast. But then again it's just a single surface.

The startup game is one of the worst games I know of. It does things that are exceedingly bad.

I'd be curious how FJ-GL does on your machine. I got about 600 FPS on the main menu using an ancient Dell D630.

I was referring to the SSFML startup game (essentially a test suite), not the default one that comes with 1.5.

New feature: You can change minisphere's taskbar icon by putting an image in the same directory as game.sgm with the filename game-icon.png.

Okay so minisphere SUCKS at rendering windowstyles.  The "big window" test in Radnen's test suite?  30 fps.  Surface fill hits 1400fps easy, but it can't even maintain 60fps drawing a window?  What the hell?

From what I can tell, the tiling is what's doing it.  Disabling the window background as a test, it hit 1600 fps.  Which is weird, since it's just drawing the same bitmap multiple times, and I'm even batching them (unbatched, for the curious, it dropped to 3(!) fps).

This is a stumper.