Since I'm very very busy with real life stuff anyway, I'm also going to wait on the New And Improved Map Engine before developing anything. It sounds very promising so far!

Well I'm back and making progress.

After making a total mess of it for no clear reason I've now got the coordinate system for the map engine and the sprite engine working together properly, incorporating the ability to apply a transformation to the entire drawn map (including all sprites) and separately a facility to draw the map zoomed in or out.

I've been doing a few speed tests, I'd like the code to be a bit faster if possible, currently drawing 1200 sprites the update script takes approximately 7.5 milliseconds and the renderscript takes 6.9 milliseconds. (This includes processing movements and applying zoom and any other transformation).

Just a brief apology that I haven't got a product to show yet I keep going down the rabbit hole of refactoring and micro-optimising what I've already written rather than making progress towards having a usable release; I'll hopefully be there soon though, most of the infrastructure is in place for the three scripts just need to get collision logic set up properly and then clean up the interface used for initiating everything.

Well some progress made:
1. I can move around the map with the camera following me - (though I can't manage to make it always stay centred if I zoom in and out too much)

2. Collisions with map scenery work

3. Collisions with other sprites on the map did work earlier they're not working now and I'm not sure why, I will fix this...

4. An equivalent of FF6 style Mode 7 works with no slow down (thanks to Fat Cerberus)

4. An equivalent of FF6 style Mode 7 works with no slow down (thanks to Fat Cerberus)

I guess that means you figured out the projection matrices.

4. An equivalent of FF6 style Mode 7 works with no slow down (thanks to Fat Cerberus)

I guess that means you figured out the projection matrices.

In the end I copied and pasted your screen transformation code and edited a few numbers; I was fiddling around with z coordinates which actually appear to be irrelevant unless I'm missing something, the working version I'm using has all the z coordinates set to 0.

In other news, tile based collisions all work now. Polygon based collisions is the next target, then an RMP loader.

If you're doing a 3D projection then the Z coordinate affects how close or far away the vertex is from the screen, extending from zero (the camera "lens") to negative-infinity.  Anything outside of the Z clipping distances (defined by the near and far parameters of project3D) won't be rendered.  That's why there's a Z translation just before the projection in my example.

Note: Anything with positive Z will be clipped by definition because it lies "behind" the camera.

In any case, good that you got it working at least.  3D is hard.

If you're doing a 3D projection then the Z coordinate affects how close or far away the vertex is from the screen, extending from zero (the camera "lens") to negative-infinity.  Anything outside of the Z clipping distances (defined by the near and far parameters of project3D) won't be rendered.  That's why there's a Z translation just before the projection in my example.

Note: Anything with positive Z will be clipped by definition because it lies "behind" the camera.

In any case, good that you got it working at least.  3D is hard.

I still can't draw shapes with z-values but I can transform the screen which works sufficiently well.

Not finished yet (obviously) but I think these are really starting to take shape.

I'd be interested what people think of the code style and features etc, files are on dropbox so people can take a quick look: https://www.dropbox.com/sh/9rug8p7bjll4e8l/AAAbiYncMBRbYd8k7Wps5CpHa?dl=0

3 system scripts + 2 shader files needed for them to function + main.js shows using them - this isn't a full demo yet as they're not finished (so I haven't included the resources (map and sprites) that the main.js script is looking for.

Quick note on licensing etc. When finished I will release these under the 3 clause BSD license in line with miniSphere - for now I've posted them for comment but ask they are not used in any public projects as they're incomplete.

Just skimming real quick, I came across this bit of ugly Sphere v1 code:

Code: (javascript) [Select]

var file = OpenRawFile("output.txt",true);
var avgs = [0,0,0,0];
for(var i = 0; i < m_render_times.length; ++i)
{
	avgs[0] += (m_render_times[i] / m_render_times.length);
	avgs[1] += (s_render_times[i] / s_render_times.length);
	avgs[2] += (m_update_times[i] / m_update_times.length);
	avgs[3] += (s_update_times[i] / s_update_times.length);
}
file.write(CreateByteArrayFromString("average m_r = " + avgs[0] + "\n average s_r = " + avgs[1] + "\n average m_u = " + avgs[2] + "\n average s_u = " + avgs[3]));
file.close();

You could change that to (Sphere v2):

Code: (javascript) [Select]

// [snip: calculate averages]
FS.writeFile("~/output.txt", "average m_r = " + avgs[0] + "\n average s_r = " + avgs[1] + "\n average m_u = " + avgs[2] + "\n average s_u = " + avgs[3]);

I haven't actually tried it out yet, just skimming over the code for now.

Just skimming real quick, I came across this bit of ugly Sphere v1 code:

Trust you to spot that... I like being able to write to the directory I'm working in so I can have less open... That's just some temporary code for testing speeds of the different key functions though it won't remain in anything final.

Also main.js isn't really part of the project it's just a playground for trying it out, there isn't any v1 code in MEngine, SEngine or CEngine.

I figured it was temporary debugging code, I just used it as an opportunity to point out that Sphere v2 has a function for writing a string into a file in one shot so you don't have to mess with byte arrays.  Maybe you already knew about that function though

Please could someone suggest some really massive/complicated .rmp files I can test with?

Whilst I'm aiming at supporting Tiled maps as well as .rmp ones I want to support .rmp fully so would be good to have some horrible test cases.

FBnil's Puff-Puff has pretty big .rmp files in the ~80k range.  They have embedded tilesets and lots of entities, so they'd be a good test I think.  I'd be interested to hear if my RMP-loading code from oh-so-long-ago works to load all (or even most) RMP maps in the wild.  It's a pretty gnarly format, topped only by RSS that has 3 versions all of which are totally different from each other!

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