Most of my implementations have gone off without a hitch and produce identical output to SSFML and Sphere 1.5 (outside of the speed tests, which seem universally faster than Sphere 1.5)--except for the surface test.

I'm curious if you've tried the version of Sphere 1.6+ that I compiled with MSVC 2010 a year ago, available at rpgmaker.net/users/FlyingJester/locker/sphere16fj.zip. I found that simply using a newer compiler made the engine between 10% and 50% faster, depending on the situation. Using slightly newer OpenGL with FJ-GL also mad many tests--particularly texturing--up to 25% faster.

I would not be too surprised if you were still faster than that, but it would still be interesting to see the results.

I was doing another round of speed tests, this time using my link library.

I have a test where I compare Link.js with Lazy.js and my old Query.js functional programming libraries. I was shocked to see Query.js outpace the other by a magnitude of 10. Lazy execution is just SLOW on both minisphere and Sphere-SFML.

Code: (javascript) [Select]

// times in SSFML:
Link: 966ms
Lazy: 965ms
Query: 76ms

// times in minisphere:
Link: 2300ms
Lazy: 2298ms
Query: 132ms

// times in Sphere 1.5:
(out of memory)

// in 1.5 using 10 times less results:
Link: 300ms
Lazy: 300ms
Query: 19ms

As a reminder, Query is the library I originally made that Link is based off of. The only problem is it doesn't lazy execute the chain. Safe to say, it really is fast and kicks the crap out of the other two if you need it for a tight execution loop. In a web browser, this is not the case and is actually slower by many factors (query forces through the chain n times, where n is each added operation, Link and Lazy go through the chain once).

I'm curious if you've tried the version of Sphere 1.6+ that I compiled with MSVC 2010 a year ago, available at rpgmaker.net/users/FlyingJester/locker/sphere16fj.zip. I found that simply using a newer compiler made the engine between 10% and 50% faster, depending on the situation. Using slightly newer OpenGL with FJ-GL also mad many tests--particularly texturing--up to 25% faster.

I would not be too surprised if you were still faster than that, but it would still be interesting to see the results.

minisphere still beats it, but admittedly by a much narrower margin.  Anything purely script-based though, like the Color creation benchmark, blows minisphere out of the water.  That doesn't surprise me though, since I assume this is TraceMonkey or newer and not the ancient SM in 1.5.

All 1.6FJ tests are with FJ-GL.  Testbed runs at 320x240.  CPU is an AMD A10-6800K and I'm using the GPU built into the chip (Radeon HD 8670D).

Surface Fill Rate: Fills a full-screen surface with solid green via .rectangle() and blits it.
1.6FJ: Hovers around 650 fps.
minisphere: ~2300.

Big Window: Draws a window covering nearly the full screen using a windowstyle with a 1x1 tiled background.
1.6FJ: An abysmal 15 fps.
minisphere: ~2800. (although I haven't fixed that tiling bug yet...)

Many Primitives: Fills the screen with 32x24 GradientRectangles (so 100 of them).  The one test 1.6FJ beats me at.
1.6FJ: ~3000 fps.
minisphere: ~1450.

Surfaces: Creates 4 surfaces and juggles them in odd ways.  As mentioned above, I can't really decipher the test.
1.6FJ: ~320 fps.
minisphere: ~425. (caveat emptor: minisphere doesn't render this test correctly).

Windows: Draws 3 windows using a windowstyle, two of them with a color mask, the second of which continuously expands and contracts. Note that minisphere currently ignores the colormask.
1.6FJ: ~2230 fps.
minisphere: ~2900.

So yes, minisphere is still faster at rendering, in most cases by a sizable margin.

minisphere still beats it, but admittedly by a much narrower margin.  Anything purely script-based though, like the Color creation benchmark, blows minisphere out of the water.  That doesn't surprise me though, since I assume this is TraceMonkey or newer and not the ancient SM in 1.5.

It's the very last release without any JIT or tracing engine.

For a few things it's still the fastest JS engine I've seen--for example, the empty loop test with lower values (~1000000), probably since it's a very mature interpreter and isn't spending time running the code through any tracers or type analyzers, as modern SpiderMonkey does. In most real-world scenarios, this isn't the case, though.

Just started work on the map engine, and I have a question regarding the RMP format.  The layer header contains the following fields:

Code: [Select]

float32 parallax_x;
float32 parallax_y;
float32 scrolling_x;
float32 scrolling_y;

What I'm wondering is, what do these coordinates represent, exactly?  I know what parallax is, but I'm completely stumped as to what purpose the X/Y coordinates serve.

Also, whose idea was it to make map layers have individual width and height?   I can't think of a single circumstance where that makes sense.

Also, whose idea was it to make map layers have individual width and height?   I can't think of a single circumstance where that makes sense.

I know what parallax is

You've answered your own question

So what, it just tiles the parallax layer if it's smaller than the main layer(s)?  Besides I thought Sphere's implementation of parallax was just an image, not a real map layer.

That still doesn't answer what the parallax and scrolling X/Y in the layer header are.

No, a parallax layer could, if a different size, benefit from being larger than the main map layers.

I haven't worked with this in a while, but I'm fairly certain that parallax values control the origin when using parallax, and scrolling control the parallax speeds.

You could just poke those values with a hex editor and see the result, too. That's how I originally figured it out.

Parallax X/Y is a value usually default at 1. It is the mutiplier added to the camera for the parallax effect. 1, 1 is neutral, or no movement while 2 is twice as fast, etc.

Scroll X/Y is a value usually default at 0. It is the constant speed that constantly moves the background by that amount. 2 makes it scroll fast (2 pixels), while 1 is slower (the maps FPS dictates apparent speed).

So if the scroll values are nonzero, then it scrolls continuously even if the player isn't moving?  That makes sense, then.  I guess you'd use that for a moving cloud background or such.

I got the map engine working!  So far it can load the bitmaps from an RTS tileset and load and render a map using the proper tiles.  ChangeMap works.

Oh, and just because I'm meticulous like this: I ran minisphere and Sphere 1.5 at the same time, lined up the windows, Alt+Tabbed between them and the output is identical!  I wasn't sure if I got the alignment on the sprites right or not, but it looks like I did.

Awesome! The map is the most daunting part. It's not hard to do but there's certainly a lot of pieces in it. To emulate Sphere correctly you'll basically need to copy it's line intersection code for obstructions and the command queue code for movement. I'd be impressed if you manage to get lithonite.js working the way it was intended. (In SSFML it works mostly correctly besides a few edge cases... with edges!)

If you are drawing the layers to surfaces and then drawing the surface to screen, check to make sure you can do tile animations easily and fast enough. That'll be the next big step.

I didn't even bother with the extra complexity of surfaces.  I just told Allegro to defer drawing and drew all the visible tiles directly to the backbuffer.  See, I looked into how the deferred drawing works, and what benefits most from it is bitmap drawing--when you defer, Allegro batches all al_draw_bitmap() calls and then sends them all to the GPU at once as a single, huge triangle list.  In theory this should be blazing fast without the need to cache the layers on a surface.  Even more so once I implement atlasing for tilesets (currently each tile gets its own bitmap).

I didn't even bother with the extra complexity of surfaces.  I just told Allegro to defer drawing and drew all the visible tiles directly to the backbuffer.  See, I looked into how the deferred drawing works, and what benefits most from it is bitmap drawing--when you defer, Allegro batches all al_draw_bitmap() calls and then sends them all to the GPU at once as a single, huge triangle list.  In theory this should be blazing fast without the need to cache the layers on a surface.  Even more so once I implement atlasing for tilesets (currently each tile gets its own bitmap).

Ok, awesome! That actually will make animations easier to do. Tileset atlasing would also end up as a huge win, too. Allegro would be using OpenGL, and sending different texture pointers to HW is certainly a bottleneck.

Okay, whose idea was it to use line segments for obstruction? . I know it's more flexible than bounding-box collision, but the crazy math required to check for intersections is insane.  Nothing like rects where it's just a few comparisons and you're done.  I looked at Sphere's source code and the TestSegments function alone must be at least 100 lines of code...