Average the time over 10 frames or something?

Yeah, I was thinking something like that would be needed.  I didn't tag the GitHub issue for v4.7.0 because I don't know how difficult it will actually be to implement.  Once I finish the spriteset refactoring I'll look into it, at least.

I just finished implementing v1 CreateSpriteset().  I think I'll add Spriteset#save() while I'm at it.

@Rhuan @Eggbert: I'm done with feature additions for miniSphere 4.7 for now; anything else you would like to see make it into the 4.7.0 release? (besides the frame-limiting fix; it's far from trivial to fix so I'll probably postpone it).

Here's the changelog so you can see what I've already done:
https://github.com/fatcerberus/minisphere/blob/master/CHANGELOG.md

I can't really think of anything at the moment. I figured out a cheap way to prevent repeated keypress dtection for what I wanted to do (pressing tab toggles a debug popup that follows the player character), and it shouldn't be too difficult to set up a library to handle that for all of the keys.

I was trying to write an algorithm for the frame skipping after work yesterday but all I did was fill paper with numbers May just be too tired at the moment.

I've got some other ideas about optimisations but would like to test what the engine can do with the changes you've made so far before suggesting anything further, thanks for all your efforts.

I was trying to write an algorithm for the frame skipping after work yesterday but all I did was fill paper with numbers May just be too tired at the moment.

One idea I had was to steal time from early frames, but that doesn't help you at all in the case where all your frames are late.  Plus it risks introducing undercrank, i.e. after a late frame the subsequent ones will be given a smaller timeslice and cause the game too fast, leading to jerky animations etc.

So yeah, it's not a trivial problem to fix.

I was trying to write an algorithm for the frame skipping after work yesterday but all I did was fill paper with numbers May just be too tired at the moment.

One idea I had was to steal time from early frames, but that doesn't help you at all in the case where all your frames are late.  Plus it risks introducing undercrank, i.e. after a late frame the subsequent ones will be given a smaller timeslice and cause the game too fast, leading to jerky animations etc.

So yeah, it's not a trivial problem to fix.

I was trying to work out a way to determine what framerate should be targeted based on the delays and how many frames had been drawn so far and hence whether to skip or not and but it felt like there was a step I was missing.

Funny thing happened: In the process of messing with the Galileo code, I discovered a bug: the Shape constructor wasn't checking for failure after uploading the vertices to the GPU.  So I fixed that... and found out that vertex upload has been broken for a long time.  Depending on the game, after a while VBO creation starts to fail.  That doesn't crash the engine because v4.6 and earlier had a fallback for older machines without VBO support.  But now the fallbacks are gone, this needs to be fixed ASAP.

I'm not sure whether I'm leaking vertex buffers, or maybe Allegro is... even so, the failure seems to occur after only a few hundred shapes, while my GTX 1070 has 8GB of RAM!  So I very much doubt I'm running out of VRAM.  What fun...

The vertex buffer failure looks like a race condition of some kind.  If I put a breakpoint after the error, and then Set Next Statement to try creating the VBO again, it succeeds.  Then it fails again a bit down the line.  So I'm guessing it's some kind of Allegro bug, but Allegro is just doing simple bog standard GL calls:
https://github.com/liballeg/allegro5/blob/5.2.2.0/addons/primitives/prim_opengl.c#L666-L669

No idea why that should fail.  The buffers in question are tiny, between 4-100 vertices (circle fans, image blits, etc.).  Even if I ended up leaking every single buffer (which I'm not--the VBO that first fails gets ID 3), it fails after only ~150 shapes.  That's 1MB of vertices, tops.

Seems absolutely bizarre, could you insert an if and just try again if it fails?

Obviously a problem if it fails twice... Run a loop that ends when it succeeds? Seems rather painful, but hopefully should be rare that it takes more than 1 run of the loop?

I guess it's dangerous that if for some reason it never succeeds that loop would go forever.

Yep, retrying the operation even once makes it work.  My theory is that Allegro is forgetting to check the result of glGetError() somewhere, causing the error to be picked up later during VBO creation.  Calling glGetError() clears the error flag, allowing the second attempt to succeed.  I've already reported the bug to the Allegro devs.

Alright, I got everything working again and did a bunch of internal refactoring to make the Galileo code easier to work with going forward and more extensible.

There's also a surprise new addition to the Galileo API (I fibbed about not adding anymore features to 4.7 : VertexList and IndexList objects!  These let you upload a bunch of vertices to the GPU and share them between different shapes--the VertexList contains the vertices and the IndexList specifies which vertices to actually use in the shape.  You can also modify a shape after creation now, by replacing its vertex and index buffers.  This makes Galileo much more powerful and gives it a clear advantage over Sphere v1.  There's only one fix left that I want to do, and miniSphere 4.7 should be out within the next day or two.

Here's all the new improvements to get excited about:
https://github.com/fatcerberus/minisphere/blob/master/CHANGELOG.md

miniSphere 4.7.0 is now available for Windows and Ubuntu 16.10 and later.

This release brings performance enhancements, API refinements (per-surface clipping, e.g.), new VertexList and IndexList objects, better Sphere 1.x compatibility, and more.  Note that a shader-capable GPU is now required, so no more running the engine on old Pentium 4 budget machines.

Built for mac, not sure what I think of the VertexList facility, can't currently think where I'd use it and so at the moment it's just an extra function call when creating a shape.

It is very good to see the better draw speed though.

It's often more efficient to store a bunch of vertices in one buffer and then use an index list to take only the ones you need, rather than having a bunch of separate buffers which was always the case before.  Basically, for a bit of extra complexity in the API you get a lot more power to optimize where needed.  It's a tradeoff.

Also by swapping in a new vertex list you can redefine a shape after creation, which I believe is something you asked for before...?