The way I did it was first using SDL's dialog methods, and then later a little platform-specific code to make dialogs for X11, OS X, and Win32.

I think that if you do implement error message copying, you could get away with simply copying the message to the clipboard once you click the screen.
But then again, the errors output to the terminal too, so how necessary is it really? Well, useful for reporting the errors, I suppose.

This is why the Galileo API is the way it is. It stops you from needing thousands of calls for thousands of sprites. That's also why I dropped the old API altogether. It's really not how OpenGL or D3D or any modern rendering technology works, and it shows.

But we will always be slower than dedicated 3D engines. They will always have specific functions built in, which the engine can be optimized for at the cost of flexibility. I'm more content to lose a little performance be be generally useful

I think you're right about the API. Sphere's immediate drawing routines are the issue here, even if you do creative batching like in SphereSFML. There are newer tricks that are easier to use had Sphere's API been different, which is the case for Galileo.

Agreed.  However I won't drop the legacy routines as they serve as a convenient stepping stone.  Don't underestimate the value of having a fully Sphere-compatible engine.  It makes porting painless, so then you get access to all the nifty new features (like Galileo!) pretty much for free.  And then eventually you do start using them, and before long you wonder how you ever lived without the neat new additions.

Basically minisphere is set up to let you learn new ways of doing things at your own pace rather than being forced into it, which from my own past experience I can say tends to make you resent "the new way".  Better to be able to ease your way into things than being thrown to the wolves.

That said, while the legacy primitives are included in the engine, I deliberately didn't document them for precisely the reason Jester mentioned.  They are available for backwards compatibility and easy porting, but for all intents and purposes they should be considered deprecated at this point.

edit: A deflate bomb is possible:  http://security.stackexchange.com/questions/51071/zlib-deflate-decompression-bomb

Today I added an optional max_size parameter to bytearray.inflate() and InflateByteArray(), to defend against inflation bombs.  I left the default dynamic allocation behavior in for when a max size isn't provided however, as that may sometimes be preferable for trusted data, such as local save files.  Any inflation of data coming over a socket should definitely include a max size clause, though, I totally agree with that.

minisphere 1.3 is nearing release, I just want to do some updates to miniRT and then it should be good to go.  Unless I decide to add more features, I swear there was another new feature idea I had but now I've forgotten it...

I had to create a shell function "gup", to update my git each time... man... chose changes are pumping through faster than I can make testcases.

Yeah, nobody who saw this engine would believe it was one guy who put it together in 3 months, huh?  Nonetheless...

I started development towards the end of January, minisphere 1.0 was released mid-to-late April.

It's funny, I'm generally bad at finishing projects I start, but minisphere... I don't know, it's been very easy for me to keep the wheels of development turning with this project for some reason.  Which is a good thing of course, I just don't understand it.

I remembered the feature I wanted to add: SPK support!  I always aim to have at least one killer new feature for each version bump, so 1.3's will be archives.  For game packages I want to support, at the very least, SPK and ZIP.  To do this, there's apparently a zlib-licensed library called "PhysicsFS" that will let me access files directly from archives:

http://icculus.org/physfs/

Awesome! I have some ideas for redistributable games in that regard:

- Obviously, direct filetype association with spk files would be nice. Double-click the SPK, play the game.
- Renaming the zips with a different extension (like .spk2 or .spherezip or something). This makes filetype association easier for Sphere zips. (Compare to .cbz "comic book zip" files, which are just archives filled with pictures)
- The game launcher detecting these packages if you put them in games/, of course.

And some more special ideas:
- If you distribute just the engine binary + an spk file, it'll pick up on the spk file so you don't even need a games or startup folder, it'll just open that when you start the engine.
- The ability to load multiple spk/zip files. Could be useful for loading the game and then loading extra resources on top of it (like a mod, a levelpack, etc.)

Since minisphere reports as Sphere 2.0 now, we can definitely make an .spk2 format.  I think we'd have to standardize on an archive format though.  Zip seems the best option, as it can be supported easily enough with just zlib, regardless of what minisphere ends up using to support it.  Plus it seems to be what most compressed formats go with.  OpenDocument and Office 2007+ docx files are just relabeled zips, for example.

7z would of course compress better, but would hinder performance as decompression can be slow, especially if solid compression is used.  Ideally I'd want a format with decent compression but without sacrificing too much random access performance.  A non-solid deflate-based format like zip fits the bill, I'd think.

Where things get hairy is handling write access.  RawFile is the biggest issue here--the same API is used to open a file for either reading or writing, but you can't really write to a package at runtime.  It might be necessary for me to step back and look at refactoring the asset management first, before baking in package support.

I would also have to make sure running a game from a package is transparent.  This is an issue I know Sphere has had: some things just don't work when running games from an SPK.  It's a big reason I gave up on packaging games back when I was using 1.5.  Which is a shame, because being able to distribute a single .spk for your game is nice for when the person on the other end may not really know what to do with a zip file.

You know, I'm actually beginning to wonder if the FS sandbox imposed by the original engine wasn't deliberate, but just a necessary evil of supporting packages.  Not to say you can't dispense with the sandbox by using fallback clauses, but for consistency's sake Chad Austin might have decided to just sandbox always, regardless of the packaging method or lack thereof.

Since minisphere reports as Sphere 2.0 now, we can definitely make an .spk2 format.  I think we'd have to standardize on an archive format though.  Zip seems the best option, as it can be supported easily enough with just zlib, regardless of what minisphere ends up using to support it.  Plus it seems to be what most compressed formats go with.  OpenDocument and Office 2007+ docx files are just relabeled zips, for example.

7z would of course compress better, but would hinder performance as decompression can be slow, especially if solid compression is used.  Ideally I'd want a format with decent compression but without sacrificing too much random access performance.  A non-solid deflate-based format like zip fits the bill, I'd think.

I believe that a combination of tar or cpio and zlib or xz is the best. tar and cpio provide the same strengths, but are far simpler.
The reason I never got around to fully supporting spk's was that writing to a file from a game that is running from one is very complicated, as you mention. I finally said enough, and gave up on packages, since at that point the benefits seemed very small for the amount of complexity they introduced.

My final plan is to just unpack the package to some local directory and run the game there. If it looks like I've done that before, I merge the existing directory with what I unpack, favoring existing content. This bypasses many of the issues associated with packages, at the expense of having both a packaged and unpackaged game on the local disk at once.

In the interest of making package support as painless to implement as possible, I've decided it would be best to standardize on a file system.  I call my initiative SphereFS, and it'll be a key pillar of the Sphere 2.0 API.  More details forthcoming, but suffice to say it will be backwards compatible with the Sphere 1.x sandbox but would allow, e.g. absolute paths via an escape.

SphereFS support will have its own extension designation in minisphere, sphere-spherefs.  Once I've fleshed things out some more, I will post a new thread in the Engine Development forum.

where doing it man
where MAKING THIS HAPEN

Re Bezier curves - Fortunately for you I understand the maths and once wrote a script to use in Sphere. It's in the Wayback of the old wiki somewhere. I also C++-ed it for my hello-phoenix project on my GitHub. The de Casteljau curve algorithm is essentially a divide-and-conquer one, but you may also need to limit the recursion depth if you don't check for point distance (NCurve in hello-phoenix does both, but I think the JS version only tests point distance).

Re spk/zip - If you choose to implement reading of renamed zip files as the next generation of spk and you want to keep a three-character extension, I recommend spz. If it's renamed 7z, sp7.

Re SphereFS - Feel free to make a "Future of Sphere" post for it, maybe including spitballing sphere:// or sph:// protocol handling or something too for a bit farther into the future.
edit: seems you already posted, I didn't finish catching up +neo

Ugh, the package support wasn't even the most painful part of the SphereFS implementation, it's the abstraction that's the killer.  The whole engine was written with the assumption files will exist on the local FS, forcing me to not only have to implement custom sfs_fopen() etc. but even things like GetFileList() ended up getting broken.

The biggest issue though is loading images and such through Allegro.  If it weren't for Allegro's memfile add on (file-mapped memory!), a clean abstraction wouldn't even be possible--I'd have to resort to temp files.

...nonetheless, I finally got it up and running this morning. A few things, like MNG loading, are still broken, but for the most part the engine is back in working order and will run a game from either a local folder or an SPK.

SPK is implemented by an spk_fopen() function which unpacks the requested file into memory and an emulated spk_fread() etc. which operate on the buffer.  This avoids a potentially lengthy unpacking step on startup without sacrificing too much performance, as memory is fast so the only additional overhead over straight disk access is the inflate step.

The end result is that the rest of the engine doesn't know or care where or how the file is stored, it just gives SphereFS a sandbox pointer and a filename and gets a file handle in return.  It's a very clean setup this way.

edit: It actually might be possible to support writing to an SPK, now that I know how the format is set up.  Every file, and the index itself, has an explicit offset stored in the headers, which means it's trivial to just append a new or modified file to the end.  For existing files you just modify the index entry, and new files can be tacked onto the end.  Of course this could cause the SPK to grow inordinately large without some method of compaction available... Just a thought.