Albrook from Kefka's Revenge might be a good test map too. Lots of layers and scripts everywhere.

Map and entity scripts are scaring me slightly, roughly I'm planning on using the function constructor to parse them and I can set up execution conditions easily enough my concern is I'd like to make v1 maps work which means I need to implement a shim over the top of all the v1 map/entity related functions AND provide that shim to all the map and entity scripts, I can do it but I haven't worked out an efficient way to do it yet (if you've read my code you'll know what I think of inefficiencies...)

I also need a mechanism for passing other functions and variables to those scripts as by default in v2 they'll be run with no access to anything global.

If you're striving for full Sphere v1 compatibility, you actually want to run map/entity scripts with `EvaluateScript()`, making them into functions (they get their own scope) or using `eval()` (uses scope of caller in ES5+) will change the behavior.

The difference if you're curious is that Sphere 1.x runs all scripts as top-level program code, the same way browsers handle multiple scripts.

This, incidentally, is the reason I made SetUpdateScript() etc. be able to accept a function instead of a string, since it let's you access local variables in your update/render/person scripts that way.

If you're striving for full Sphere v1 compatibility, you actually want to run map/entity scripts with `EvaluateScript()`, making them into functions (they get their own scope) or using `eval()` (uses scope of caller in ES5+) will change the behavior.

The difference if you're curious is that Sphere 1.x runs all scripts as top-level program code, the same way browsers handle multiple scripts.

This, incidentally, is the reason I made SetUpdateScript() etc. be able to accept a function instead of a string, since it let's you access local variables in your update/render/person scripts that way.

i'm trying to avoid using any of the v1 api, I want all of this stuff to work if you build sphere without vanilla.c

I'm not looking to emulate v1 the idea of the compatability shim I'm thinking of is to make it do enough so that anyone with a v1 project who wants to switch to v2 can use their existing maps without going through editing them all; their main script files will obviously need some updates.

Why can rts tiles have individual obstructed pixels?

No idea, I never implemented it in miniSphere and haven't had any compatibility issues, I think even the Sphere 1.5 editor only supports line segment-based obstruction.  The RTS spec says:

Code: [Select]

byte blocked;       // 0 = no obstruction data, 1 = old obstruction data, 2 = new obstruction data

So I just assumed it was deprecated.

edit: Yep, Sphere 1.x ignores it too:
https://github.com/sphere-group/sphere/blob/master/sphere/source/common/Tileset.cpp#L513-L517

No idea, I never implemented it in miniSphere and haven't had any compatibility issues, I think even the Sphere 1.5 editor only supports line segment-based obstruction.  The RTS spec says:

Code: [Select]

byte blocked;       // 0 = no obstruction data, 1 = old obstruction data, 2 = new obstruction data

So I just assumed it was deprecated.

edit: Yep, Sphere 1.x ignores it too:
https://github.com/sphere-group/sphere/blob/master/sphere/source/common/Tileset.cpp#L513-L517

The very first example map I tried has pixel based obstruction data...

And opening it in the 1.5 editor allows me to edit it and keep it.

If you make a new tileset you don't it get it but if you use an old one it's kept. And I want to get this to work now...

Sphere 1.x also ignores it, though, as you can see from my GitHub link.  Kind of weird that the editor still supports it but the engine doesn't...

Although that tileset code is in the Common folder so that means the same code is shared with the editor... maybe 1.5 still supported pixel-based collision and they removed it later.

Oh I'm wrong - they're not pixels, it's just it lets you have segments of 1 pixel only.
And I found something not in tileset.rts.txt, a tile in an rts file can optionally have a name, the tileset I was trying to read had a named tile in it which was throwing off my reader. I found this by looking at tileset.cpp.

tileset.rts.txt states that the tile information block ends with 22 reserved bytes, conversely tileset.cpp has a 2 byte name_length then a byte for "terraformed" (seemingly not used) then 19 bytes reserved. THEN after that it looks for a name of length: name_length. (the length can be 0 in which case it looks for nothing).

tileset.rts.txt says nothing of this name.

Hmm... not sure where I picked up the information if it's not in tileset.rts.txt, since miniSphere has code to load the tile names:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/tileset.c#L154

Hmm... not sure where I picked up the information if it's not in tileset.rts.txt, since miniSphere has code to load the tile names:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/tileset.c#L154

Test map and tileset I was using are from spectacles so I'm guessing you either saw it in tileset.cpp or you had the same problem and fixed it when you were first working on miniSphere.

I'm not sure if the effects suit the map, but for testing purposes here is South Figaro from Kefka's revenue being rendered by MEngine with a Scale2x filter and a small mode7 effect.

Looks really nice, although your aspect ratio seems off (the tiles are too tall).  I think this might be the cause:

Code: (javascript) [Select]

var wh = screen.width / 2;
var hh = screen.height / 2;
screen.transform = new Transform()
    .translate(-wh, -hh)
    .scale(3 / wh, 3 / hh)  // <-- HERE
    .rotate(0.6, 1.0, 0.0, 0.0)
    .translate(0, 0, -1.0)
    .project3D(120, wh / hh, 0.1, 2.0);

The factors for both axes should be the same, you want to divide by either wh or hh but not both (I tend to prefer the former).  That was my mistake when I originally wrote the code.

Albrook from Kefka's Revenge might be a good test map too. Lots of layers and scripts everywhere.

So I tried loading Albrook and just got a black screen, I also tried deleting the nightsky layer in case it was to do with handling alpha wrongly but that had no effect. something to fix I guess but hey I'm not done yet.

Albrook is a hell of a map, I even remember having trouble getting miniSphere to load that one properly.

Kefka's Revenge in general is a monster of a game.  The fact that miniSphere runs it nearly flawlessly at this point is a testament to my dedication to backwards compatibility.

The factors for both axes should be the same, you want to divide by either wh or hh but not both (I tend to prefer the former).  That was my mistake when I originally wrote the code.

In the original you divided both by wh, I assumed it was a mistake and changed it...

Albrook is a hell of a map, I even remember having trouble getting miniSphere to load that one properly.

All I'm processing at the moment is the tile data, I'm ignoring scripts and entities, so I'd hoped it would just work.