@Rhuan: Sorry I haven't provided very much input here, you pointed out ChakraCore to me and the MIT license + pure C API + cross-platform-ness sealed the deal.

@Rhuan: Sorry I haven't provided very much input here, you pointed out ChakraCore to me and the MIT license + pure C API + cross-platform-ness sealed the deal.

No worries. Getting a decent modern JS engine into sphere seems like a pretty important thing to focus on.

I'm getting there with this stuff, just trying to make an engine that's crazily flexible whilst also as micro-optimised as I can manage isn't quick.

Well I think I've just implemented a great algorithm for collisions between sprites using polygon based detection.

Except I've not included a handler for anyone who goes off the edge of the map - so insta crash

Fixed the crashes but there's still an error somewhere

EDIT: why does:
var end_x2 = (((x + max_w + d_x)/ t_size)|0) + 1;
give a different result to
var end_x2 = ((x + max_w + d_x)/ t_size)|0 + 1;
That's just odd.

I've become obsessed with bitwise operators instead of the Math library, aside from them scoring higher on most performance bench marks I just think they look cool.

But they do seem to have a few odd properties - adding that extra bracket seems to have got my sprite polygon collisions working.

It's because addition outranks bitwise-OR in operator precedence:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence

In general, logical and bitwise operators are weird precedence-wise.

It's because addition outranks bitwise-OR in operator precedence:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence

In general, logical and bitwise operators are weird precedence-wise.

But the effect of a bitwise or with 0 on a number should be to it number down to the nearest integer - whether the 1 is added before or after shouldn't impact the result.

If the result of the first sum was 0.8 whever you do 0.8 rounded down = 0 then +1 = 1 OR 0.8 + 1 = 1.8 then round down = 1 it should be the same.

Addition binds before bitwise or--so you were actually OR'ing with 1, not 0.

Addition binds before bitwise or--so you were actually OR'ing with 1, not 0.

Oh, no wonder I was getting odd results.

When dealing with operator precedence, I've found that it's more intuitive to think in terms of binding power, i.e. how "magnetic" each operator itself is, rather than trying to work out which subexpression will be evaluated first.  In your code, addition is more "magnetic" than bitwise OR, so the 0+1 gets combined before the OR is evaluated.

Addition binds before bitwise or--so you were actually OR'ing with 1, not 0.

Oh, no wonder I was getting odd results.

...wait, was this a stealth pun?  Anything | 1 is always an odd number!

I'm afraid I've had a busy week and I'm not ready to release a usable version of the engine Hopefully one more week.

Also got a question I can't work out how to answer at the moment - how do I process entity data read out of a Map file? Particularly when it's an RMP file and it's pointing at RSS files.

I need to add the entities to an instance of SEngine -but that's a different class from a different module - I could pass MEngine a reference to SEngine (I already pass SEngine a reference to MEngine...) it does start feeling a little awkward at that point - though I suppose I never iterate through the top level objects so the recursion shouldn't matter.

But there's another problem in my structure, at the moment my .RSS loader is a utility function sitting in my main script I didn't want it in SEngine as I thought it was horrible - but to avoid passing even more references I'll probably have to put it into SEngine .

Possible long term solution - RMP and RSS loaders get converted into a cellscript and removed from the core modules completely, for now though I think I'll have to add an RSS handling method to SEngine...

@DaVince I'd like an extensive test for my systems - just running a map on it's own doesn't really cut it, and I have no significant projects of my own to test it with as most of my projects are a few 1000 lines of code with no graphics that then gets abandoned.

So I'm thinking to test it I should re-factor Kefka's Revenge to use the v2 api and my systems for the map and sprites - this would be a great test BUT I obviously don't own KR, I can't see any license with KR it's just distributed freely, you were involved with its creation, what do you think of me using it for such a purpose? Particularly if I share the finished result (if there is such) as a proof of concept any objections?

The RSS filename in a map file is relative to @/spritesets:
https://github.com/fatcerberus/minisphere/blob/v4.8.4/src/minisphere/map_engine.c#L1908

This kind of thing is why I designed SphereFS the way I did.  Paths are always relative to @/ in low-level APIs, so it's never ambiguous which file is referred to.  If some JS wants to use a base folder itself, it's made explicit by calling FS.fullPath() with a base directory name.

By the way, the pain points you're hitting here re: separation of concerns, this is exactly the problem I have any time I try to design an object-oriented map engine.  It's like designing a GUI framework, there's encapsulation in theory, but under the hood everything gets inextricably connected to everything else and there's usually no way around that.

By the way, the pain points you're hitting here re: separation of concerns, this is exactly the problem I have any time I try to design an object-oriented map engine.  It's like designing a GUI framework, there's encapsulation in theory, but under the hood everything gets inextricably connected to everything else and there's usually no way around that.

It'll be fine ...

But as it's going to force me to put an .rss loader into my SEngine.js script I'm currently working on a v2 .rss loader (I've snagged your  old rss schema and am currently tweaking to integrate with the datareader script I'm using)

By the way, the pain points you're hitting here re: separation of concerns, this is exactly the problem I have any time I try to design an object-oriented map engine.  It's like designing a GUI framework, there's encapsulation in theory, but under the hood everything gets inextricably connected to everything else and there's usually no way around that.

It'll be fine ...

But as it's going to force me to put an .rss loader into my SEngine.js script I'm currently working on a v2 .rss loader (I've snagged your  old rss schema and am currently tweaking to integrate with the datareader script I'm using)

OK RMP loader now tips the rss loader and then when a map is displayed entities appear all over it correctly.

Next step entity scripts.

(Note RMP is far from an ideal format I'm using it as a way of ensuring I support all the features we want, I will aim to implement extensive Tiled support once I have rmp handling finished)