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.
// times in SSFML:Link: 966msLazy: 965msQuery: 76ms// times in minisphere:Link: 2300msLazy: 2298msQuery: 132ms// times in Sphere 1.5:(out of memory)// in 1.5 using 10 times less results:Link: 300msLazy: 300msQuery: 19ms
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.
float32 parallax_x;float32 parallax_y;float32 scrolling_x;float32 scrolling_y;
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
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).