Actually could you do that?  Build 3.0.4 against the Allegro PPA and do that huge map test again.  Also run the map engine with framerate = 0 so we can get a good benchmark.

Oh, I didn't know I could make the framerate unlimited in the map engine too. On it!

On self-compiled 3.0.2: approximately 205 FPS.
On self-compiled 3.0.4: still ~16 FPS.

I'm using the Allegro unstable PPA, which still seems to be at Allegro 5.1.13, compiled in January. I guess this is too old? Should I be getting Allegro the old-fashioned way (i.e. messing with the source tarball)? Could you maybe include an Allegro 5.2 in your PPA, or is that too much hassle?

No, 5.1.13 should have the vertex buffers.

I can probably statically link against Allegro.  However I suspect in this case it might be that your graphics card doesn't support VBOs and I'll have to add a fallback.  Is this the P4 machine with OpenGL 1.3?  If so that's probably the issue.

No, the P4 would never ever support that or get any high framerates. I'm back in possession of my ~4 year old laptop (that nonetheless still serves me fine), which uses an NVIDIA GT540m. From what I can tell, that... should support VBOs? I'm not sure how new of a feature that is... GPU definitely supports OpenGL up to 4.5 though.

Yeah, that should definitely be supported.  Minimum should be GL 3.0, the 450M says it supports OpenGL 4.5.  If this is occurring on modern hardware, I can probably reproduce it locally on my laptop's GTX 950M.  Thanks for testing, looks like 3.0.5 is in the offing.

@DaVince
So I did some experiments.  On my laptop, I can create the VBOs successfully, and then even the 500x500 map is rendered fast (= literally no difference in CPU usage between that and 50x50).  If I artificially disabled vertex buffer support, the framerate drops to 10-20fps.  So what it looks like is, for whatever reason minisphere is failing to create the vertex buffer for you, and falling back on storing the vertices in system memory.  So now you're sending 1M+ vertices to the graphics card every frame (for the 500x500 map), which is very slow.

That said, turning vertex buffer support back on still only got me to 40fps for a 500x500 map in Sir Boingers.  In that case the animated tiles were to blame--every time a tile changes the map needs to be recalculated.  But I think I have a clever way to get around that.

Sorry about the performance regression--this is actually kind of embarrassing.

DaVince, can you test my Sphere-SFML? I know I'm not really developing it right now, but I'm just curious of the performance, seeing if a faster script engine is better when it comes to things like command animate, or if that isn't the bottleneck.

Lord English: not sure what's going on on my side, then... By all means it SHOULD make the VBOs.

Radnen: I'm not exactly in a position to do that right now, since my Windows install is pretty broken! I'll try once I fix that, though.

That said, turning vertex buffer support back on still only got me to 40fps for a 500x500 map in Sir Boingers.  In that case the animated tiles were to blame--every time a tile changes the map needs to be recalculated.  But I think I have a clever way to get around that.

Sorry about the performance regression--this is actually kind of embarrassing.

My solution to this was to just make shapes for every combination of animations. It avoids the main issue, but I do think there must be a better solution to this.

It also means that once animated tiles start their animations at a non-zero time (such as when SetTile is called) you start to get very large numbers of shapes.

An alternative would be to simply make each animated tile its own shape, but I never really explored that. Perhaps a combination of this and per-animation-frame shapes would work well.

EDIT: I might add that it should not be an unreasonable requirement to use VBOs. This sounds like an issue in Allegro.

My idea was quite different: I have the tileset loader create two images, one for the original atlas, and another which is used as the texture for actual rendering.  When the tileset is loaded, the texture is a perfect copy of the atlas.  When a tile animates I use render-to-texture to update the texture image by blitting the proper tile from the atlas.  This way I can calculate the map vertices once, at map load, without sacrificing animated tile support.  SetTileImage() would of course do the same thing, updating the texture instead of recalculating the map.

SetTile() would still have to recalculate the map, but that shouldn't be a huge issue as a game hopefully won't be calling that every frame!

This approach of course uses more VRAM, but since you can only have one tileset loaded at a time, it shouldn't be an issue.  And for non-animated tilesets I can have a copy-on-write scheme to avoid cloning the atlas unnecessarily.

My render-to-texture method worked, and improved performance with animated tiles a ton.   Now I just have to figure out why it's failing to create the vertex buffer...

My idea was quite different: I have the tileset loader create two images, one for the original atlas, and another which is used as the texture for actual rendering.  When the tileset is loaded, the texture is a perfect copy of the atlas.  When a tile animates I use render-to-texture to update the texture image by blitting the proper tile from the atlas.

I do this exact method in SSFML! I blit from the original texture map straight to a copy that is the texture to render to screen. The copy was needed since you're always overwriting animated tiles and lose information. I found it helped out by a solid margin.

Hm, I'm starting to question whether the VBO creation is actually failing.  With my laptop set to use the i7's iGPU, if I resize the Boingers tutorial map to 500x500, I can hit around 100 fps.  At its normal size of 100x15, that goes up to 1600+ fps (!).  It looks like if you give the GPU a million vertices, it gets bogged down regardless of whether they're cached in a VBO or not--even though they are not all visible on the screen.  If I had to guess, I would say it's vertex shader overhead and if that's the case, there's not much to be done for it other than avoiding creating huge 500x500 maps.

I guess this is one case where map stitching would come in handy.  You could stitch smaller maps together to create one huge one and just avoid drawing the ones which are off-screen.

edit: Actually... that gives me an idea!  Rather than creating one large triangle strip for an entire map, I could slice it up into screen-sized rectangles and only draw the slices which are actually visible.  If we assume a 320x240 screen with 16x16 tiles (or equivalently, 640x480 with 32x32 tiles), each slice would be 20x15 tiles, or ~1500 vertices.  In the worst case we have to draw 4 of those, so that's 6000 vertices--which remains constant regardless of the overall size of the map and is quite a bit less than a million!

I think I'll hold off on implementing that slicing idea until the next release (3.1).  With the changes I've made in the last 24 hours, the map rendering performance should now be acceptable in almost all real-world cases.  The primary bottleneck for sanely-sized maps in 3.0.4 was animated tiles, which I've solved in 3.0.5.

edit: Actually... that gives me an idea!  Rather than creating one large triangle strip for an entire map, I could slice it up into screen-sized rectangles and only draw the slices which are actually visible.  If we assume a 320x240 screen with 16x16 tiles (or equivalently, 640x480 with 32x32 tiles), each slice would be 20x15 tiles, or ~1500 vertices.  In the worst case we have to draw 4 of those, so that's 6000 vertices--which remains constant regardless of the overall size of the map and is quite a bit less than a million!

I do that too! But for the Sphere editor, and instead of screen sized slices, the slices are much smaller. But think of Google Maps. There are thousands of small panels that stream in as you pan the mouse.

The only other thing I could do for performance is add asynchronous panel loading (adding multi-threading to it).