So after agonizing for weeks trying futilely to get my recursive threader to play along with the default map engine, I finally decided to chalk it up as a lost cause (realizing that UpdateMapEngine() doesn't check for input was a big part of this decision) and write my own map engine for Specs.  My question is, how feasible is this in Sphere 1.5?  I know TurboSphere is going to have its map engine all in script, but that's modern V8, i.e. blazing fast.  The ancient SpiderMonkey in Sphere 1.5 is slow as hell though, and I'm worried it won't be up to the task of running a full-featured map engine entirely in script...

tl;dr I did it before, it's quite doable.

I once wrote a somewhat advanced tiling engine in script (The 'Majestic Map Engine', it's possible there is still a copy kicking around somewhere), and it worked quite well. I was using it for a an RTS game, and had very decent performance managing relatively large numbers of entities in script in Sphere 1.5.

Both then and now, the most important part is to use graphics system smartly. I implemented animated tiles as simple blank spots in each layers' image (which was an amalgamate of the tiles), and then drew up surfaces that represented all states the map could be in for animated tiles. This let me put as much of the map into as few images as possible.

This worked very well. The one issue was that swapping a tile on the map kept its animation phase locked to that of all other tiles. But I basically just let that be. If I wanted to do something more advanced, I'd use units/persons.

Wouldn't that cause RAM/VRAM usage to skyrocket though, pre-rendering the map layers to surfaces like that?  One map-sized image for each map layer, multiplied by maximum number of animation frames, i.e. tons of huge images.  I feel like you'd run out of VRAM very quickly doing that with large maps, even if you only have a single map loaded at a time.

I've never had that issue. I was doing HUGE maps, too (think 4096x4096, tiles 16x16, 8+ layers). I wouldn't worry.

Probably because Sphere using standard32 is actually using software rendering.

I'd say if you build your own script-only version of a map engine using Sphere 1.5's API you'll easily be able to run a full speed game and even get better performance when you switch over to TS or SSFML. So I'd say go for it! You'll learn a lot about making a tiled map engine!

(SSFML is also open for the possibility of adding an event hook for map input like SetInputScript() to go along with SetUpdateScript() and SetRenderScript()).

Now, regarding FJ's method: How would I go about drawing part of an image?  Sphere's .blit() method for both surfaces and images only takes a single X and Y pair: the location to blit to, and then renders the whole image.  Am I going to have to have one image for each type of tile instead of the usual tile sheet?  Seems like that could get really messy really fast.

Oh and @Radnen: I already have plenty of experience doing tilemap engines, but thanks for the thought!   I've written at least 4 of them already at various stages in Specs history, most of those in C++ before I discovered Sphere.  I've even done a map editor or two--using the Win32 GDI API, so you can imagine how painful that was.  For a while I had a nice RPG Maker-style IDE going to do the BattleMon project with (BattleMon being a Pokemon knockoff which eventually morphed into the Spectacles Saga as it exists now), called SuperSpeedGE.

Now, regarding FJ's method: How would I go about drawing part of an image?  Sphere's .blit() method for both surfaces and images only takes a single X and Y pair: the location to blit to, and then renders the whole image.  Am I going to have to have one image for each type of tile instead of the usual tile sheet?  Seems like that could get really messy really fast.

I think he did a lot of surface stuff, look into Surface.cloneSection(). I did a technique similar to this years ago when I toyed with making a game engine in sphere itself (like the OHRRPGCE engine, if you know what it is).

Oh and @Radnen: I already have plenty of experience doing tilemap engines, but thanks for the thought!   I've written at least 4 of them already at various stages in Specs history, most of those in C++ before I discovered Sphere.  I've even done a map editor or two--using the Win32 GDI API, so you can imagine how painful that was.  For a while I had a nice RPG Maker-style IDE going to do the BattleMon project with (BattleMon being a Pokemon knockoff which eventually morphed into the Spectacles Saga as it exists now), called SuperSpeedGE.

Oh, well then! Might be a piece of cake then! I have done a tile engine in allegro and C and then primarily in C# for various personal projects, which is what made me want to do SSFML since it was me basically adding a JS engine to my existing tile engine code, then with lots of Sphere-centric stuff added to it.

I used an individual surface for every tile, and blitted them all onto a single surface for each layer. I then made those into one image for each layer.

It was pretty smooth. I actually stored the 'map' data in an image file, too, using the color of each pixel as the index for the tiles. I used the alpha in later versions to do height maps, to (a lot like in Sim City 2000). In later versions, I added shading and contour lines. The big strengths really were the height-mapping and the ability to quickly and dynamically modify the map. Because the tile data was stored in a surface, too, I could use the surface primitives to change the map quite easily.
The original RTS game I was working on this for used this to make craters for cover when a large explosion happened, or using engineer units to make hills.

This is a picture of the last tech demo I made with the Majestic Map Engine, called Gryphon Chapter.

Okay, so when you rendered the final map layers to the screen, what did you do?  Just blit the whole image (using the camera to offset) and let the engine clip it?  Because as I said, there's no way in Sphere to blit only part of an image/surface.

@Flying Jester, maybe DaVince - Is that last version of Majestic in the Downloads repo? If not, I think it should be there. At the very least, that tile set looks good even without terraforming height.

Okay, so when you rendered the final map layers to the screen, what did you do?  Just blit the whole image (using the camera to offset) and let the engine clip it?  Because as I said, there's no way in Sphere to blit only part of an image/surface.

That's exactly what I did.

I'll see if any old copies of the Majestic are floating around. I still have the old machine I write Gryphon Chapter on.

There is a version of the Majectic map engine here, but I think it's an earlier demo. To be honest I thought FJ was still using/developing that map engine for use in TurboSphere.

I just tried that demo out in SSFML and it works! It also draws much faster than the map engine (partly because it's just the tilemap without units or render scripts updating every frame). But still that's good performance for an in-script only map engine.

There is a version of the Majectic map engine here, but I think it's an earlier demo. To be honest I thought FJ was still using/developing that map engine for use in TurboSphere.

The new map engine uses the new graphics API I wrote for TurboSphere to do almost all of what the Majestic was used for. The new map engine is certainly the culmination of what I learned with the Majestic, but it is not a direct, source-related descendant.

Ah, I see, that makes sense. Also means we have similar solutions for both the old and the new engine!