I guess the next thing I should do is refactor text rendering.  That's currently one of minisphere's weak points as discovered by Radnen way back in the early versions.  Rendering whole strings as a single primitive should improve it greatly.  It might even fix the performance issues I'm seeing in Specs' battle engine!

This is an easy way to get huge performance benefits. Put each character into an atlas and then construct a single vertex map of the text to draw on screen. It's like a mini tiling engine, but with font characters rather than map tiles.

Hey all

been a while since ive been about here, saw all the improvements and was quickly tempted back

so thought id try minisphere



and of course immediately hit issues? what were once common functions are unrecognized?

Is there a good tutorial for me to go revisit, like i said its been a while. This project works just fine on 1.5 yet everything is "undefined" when i try via minisphere? Even functions i made within this same script its saying are undefined?


Ive hunted around but honestly i cant find any info on getting started again

That should be CreatePerson. (capital C).  Also based on that screenshot, you're running Sphere 1.5, not minisphere?

well i tried the other first, forgot this was case sensitive lol

im guessing this is not the right place for me to be asking also right? Should i be in the support section? Ive been away for years

well i tried the other first, forgot this was case sensitive lol

im guessing this is not the right place for me to be asking also right? Should i be in the support section? Ive been away for years

Yes, but also just keep the function reference open at all times to aid you.

@DaVince: Currently waiting on Launchpad to publish 3.0.4 for Trusty, after which I'll copy it to the later distros.  I found out that Ubuntu will auto-update PPAs, which is very convenient.  Once 3.0.4 is available, could you test it out for me?  I'm curious to see if the Galileo map rendering is an improvement in practice.  It's a bit hard for me to get meaningful benchmarks on this thing, it's a Core i7-6700HQ laptop with a 4GB nVidia GTX graphics card, there's not a lot minisphere can throw at it that it won't take like a champ.   (edit: 3.0.4 is published)

@Eggbert: Could you update the AUR package?  It's still at 3.0.1 and I've fixed a few important bugs since then.

Tested!
My test case was as follows:
I spawned 1500 (fully functional, animating) cupcakes in Sir Boingers.

On 3.0.2: about 25 FPS.
On 3.0.4: fluctuates around 21-24 FPS. Hmmm.
(And bonus: regular Sphere 1.5 flat out crashes after an insane amount of lag. Damn.)

I only realized your rendering techniques are good for layer rendering and not sprite counts afterwards, but I'm not really sure how to stress test that and it's a bit late now since I'm on 3.0.4 now. I can still get 3.0.2 or whatever from Github and test a huge map with many animated tiles or whatever, if you like.

Yeah, sprites are still drawn individually.  However Allegro /should/ be batching those if they come from the same spriteset, so I'm not sure what's causing the slowdown...

The slowdown is probably because there are 1500 sprites pushing COMMAND_ANIMATE to the command buffer all at once. The 1-4 frame difference *might* be the new rendering, but who truly knows?

I'll try making a huuuuuge map with many layers and randomly animated tiles to see if I can stress test the actual map rendering in any way.

Okay, something's obviously not right. All I did was resize a map to 500x500 size, and these are the results:

On 3.0.2, it runs smoothly at 60 FPS.
On 3.0.4, it drops way down to 32 FPS.

Ouch!  Is that true even if the map has no animated tiles?

Yeah, the tiles are completely static (regular Sir Boingers tileset), so I'm not sure what's going on here.

Okay, could you do me a favor: Run the test with spherun --verbose 4, redirect the output to a file (it'll print a lot of stuff!), and look for either "uploading shape" or "caching vertices" in the log.  If you see the latter, then I think I know what's wrong.

@DaVince: I figured out the problem.  The Ubuntu build uses Allegro 5.0, which doesn't support vertex buffers.  This means all the vertices for the entire map have to be uploaded to the GPU every frame.  Which of course is slower than before because originally only vertices for visible tiles had to be sent.  If you have a 500x500 map, that comes out to over a million vertices per frame!  I'll have to add code to fall back on the old method when building against Allegro 5.0.

Alternatively, I might be able to call into OpenGL APIs directly, but that would need some refactoring of the image handling, so probably not worth the effort.

Allegro 5.2 is out, so it's no longer considered "unstable", but the ball is still in Debian's court to update their Allegro packages.  In the meantime, I still have to support 5.0.

Okay, sorry I wasn't around to do that test for you, glad you figured it out though! I think I'll be compiling my own versions from Git from now on, because seriously. I want that Allegro 5.2 support.