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).

For realtime rendering, it's a bit of a tradeoff.  Prior to 3.0.4, minisphere rendered maps as individual quads, one for each tile, and only for those tiles which are actually visible.  In some ways, this is good: You get tile animation basically for free just by modifying the internal image index, you don't even have to blit images around.  But it's not really optimal; if your visible slice is 20x15 tiles, that comes out to ~300*num_layers draw operations per frame.  By using screen sized slices, you only have to issue at most 4 draws per layer.  In any case, as I found out, you don't want to be drawing a whole map's worth of vertices if that map is larger than about 200x200, otherwise you start seeing performance degradation.  Worse, the loss of performance is proportional to the size of the map, where ideally you want it to be constant--or at least proportional to the screen resolution instead.

At first the performance regression for large maps didn't make sense to me.  I figured, okay, the vertices are already in VRAM and if a triangle is not visible, the GPU can just skip it.  But I realize now why it happens: The GPU can't actually guarantee the triangle is not visible until it pushes all of the vertices through the vertex shader first, which may relocate them.  You can't just throw 250,000 quads worth of vertices at the pipeline and not expect it to get bogged down, especially on less capable hardware.

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.

Wait, you weren't ignoring rendering off-screen tiles this whole time???

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.

Wait, you weren't ignoring rendering off-screen tiles this whole time???

I did ignore them prior to 3.0.4, but the map was drawn tile-by-tile.  The switch to Galileo-based rendering in 3.0.4 changed it so that I calculate a mesh for the entire a map ahead of time, and then issue a single draw operation.  For maps up to around 200x200, this is fine even on ~5-year-old hardware.  Any more than that starts to bog down the graphics pipeline with vertices.

So, funny story: Allegro is smarter than I gave it credit for.  It has a sprite batcher built in which is actually awesome and it turns out that didn't need to change the map rendering at all--in fact, I ended up hurting performance by changing it.  See, it turns out that if you do this:

Code: (c) [Select]

al_hold_bitmap_drawing(true);
// draw all visible tiles using al_draw_bitmap()
al_hold_bitmap_drawing(false);

As long as all specified images come from the same underlying texture atlas, Allegro will coalesce all the quads into one triangle list and perform a single draw operation to render them.  You basically get Galileo-level rendering performance for free.

I thought you were already doing that? :/

I was--before 3.0.4.  I misguidedly thought using the Galileo API would improve performance.  Needless to say it didn't.

To clarify a bit on the above, I already knew beforehand that al_hold_bitmap_drawing() did some sprite batching and took advantage of it.  However I assumed it was just basic grouping -- i.e. to avoid rebinding textures when drawing multiple images from an atlas.  In reality, it turns out it's a bit more intelligent than that: It automatically does exactly what I was trying to accomplish with the Galileo routines (i.e. collapsing everything into a single draw operation), and does it better than I was able to do manually.  And this is why minisphere 3.0.6 returns to using that method.

So, I fired up the profiler and figured out the cause of minisphere's slow text rendering: While I do keep the RFN glyphs in an atlas and batch all the characters, the primary bottleneck seems to be the cost of populating a VBO every frame.  By looking at the Allegro source, I found out that, when using al_hold_bitmap_drawing() and drawing from the same texture, it builds up a primitive containing quads for every image drawn and once the hold is released, uploads that into a VBO and draws it.  Since this is happening every frame, it gets pretty expensive.

I'm not sure there's much to be done for this on the engine side.  It's just a fact of how hardware graphics acceleration works.  For game code there are ways around it of course.  One solution would be to create a Surface, render the desired text into it, and just draw that every frame.  Another, less memory-hungry way would be to use the Galileo API, create a Shape for the desired text and cache it.  This way the VBO only needs to be created once.

minisphere 3.0.8 is up.  This is a quick update to add support in SSJ for repeatable commands.  This is a feature inspired by gdb - after typing, say, "stepover", you can keep pressing Enter to step through the code line-by-line, instead of having to type "s" each time.

The commands that can be repeated this way are:

• list - List source.  Repeating a list command will continue listing rather than redoing the previous one.


• continue


• stepover/stepin/stepout


• up/down

I also made a slight usability enhancement related to this: If the SSJ command-line is left blank with no command to repeat, it will give the user a hint to type "help".  This should help out newbies a bit in learning the debugger commands.

There haven't been many replies lately, but I'd just like to say good work on all the progress and improvement.

By the way, @DaVince, did you stress-test 3.0.7 at any point?  Well I guess now it would be 3.0.8...

By the way, @DaVince, did you stress-test 3.0.7 at any point?  Well I guess now it would be 3.0.8...

It'd forgotten about it until you told me just now, but spawning a cupcake every 3 pixels on the X axis 1500 times slowed things down to 14-21 FPS before, while it stays at a smooth 60 FPS now. Wonderful.

I made some enhancements to the Galileo API to make it easier to do transformations and such.  Instead of X/Y/angle properties, I added a group.transform property which is used to work with the transformation matrix directly.  This allows you to do more complex transformations:

Code: (javascript) [Select]

group.transform.identity();
group.transform.scale(2, 2);  // 2x scale
group.transform.translate(10, 0);  // x += 10
group.transform.rotate(Math.PI * 2 / 4);  // revolve 90 degrees
group.draw();

Other enhancements I made in the last commit: Drawing Shapes directly (without a group), and the ability to do Galileo rendering, both Shapes and Groups, onto a Surface instead of the backbuffer.  So those enhancements will be in minisphere 3.1, whenever I decide to release that.

Finally, I have an experimental branch on GitHub (pegasus-api) that overhauls the entire API to be more Pegasus-like and removes a lot of legacy baggage from the core engine such as the classic map engine, ByteArrays, etc.  I'm still unsure if I want to release the Pegasus modifications with minisphere 4.0, or fork it off as a seperate "Sphere 2.0" repo.  Either way, I might release an alpha version of that soon, so keep an eye out for it.  In the meantime minisphere will remain backwards compatible for the foreseeable future.

I took a long look at Cell yesterday and I have to concede that the experiment was a failure.  It tends to just add an inconvenient build step to the Sphere workflow for no real gain.  It's easy enough to write a .s2gm file by hand (it's just JSON) and Sphere's strength, like most JS runtimes, has always been the ability to run code directly with no formal preparation needed.  For more complex workflows, it'd probably be better to have small, purpose-built tools for each task (such as tileset/spriteset generation, etc.) so they can be assembled into a batch file or shell script as needed, leaving the "all-in-one" type stuff to IDEs like Sphere Studio

Anyway I'm going to repurpose the program.  Instead of being a scriptable compiler (a task it does very poorly now), it will be remade into a project management tool and SPK packager.  To start a new Sphere project you run cell init in an empty directory, which creates the .s2gm file.  From there you can do cell add/remove filename to add and remove files from the project (this is needed so Cell knows what to include in the distribution), and cell package to compress it all into an SPK.  There will be more commands available too (such as to set the title, author, API level, etc.), but that's the basic workflow. This will allow Sphere games to be developed entirely on the command line if so desired.

That sounds really useful, especially on Linux. Think you can also generate the standard project folders on cell init?

Also, for the "adding files" thing, I don't know how I feel about manually adding every thing into the project. It adds a factor of forgetting to add that new script or resource you just made that the game uses. Wouldn't adding every file/folder found that matches the standard Sphere format work better? Or perhaps a list of files to ignore for packaging, rather than files to add?