May 30, 2013, 05:12:08 pm

WARNING: LONG BUT IMPORTANT POST

With the development of Flying Jester's TurboSphere, casiotone's sphereclone, alpha123's 1.7 development, Metallix's three.js-based and Radnen's pixi.js-based Sphere-compatible web engines, Radnen's Windows editor Sphere Studio, and my eventual contribution to the web engines and some upcoming desktop apps as well as my recent de facto takeover of project management, the Sphere engine is finally seeing its first definitive expansion in years! Now while I'd love to see engine development continue to move forward on all fronts, the engine is nothing without Sphere projects to test, demo, and showcase its abilities.

If we go all the way back, we have a fair amount of projects made for Sphere with varying degrees of completeness, but some are lost with the last site reset and some of the recovered projects are apparently just too old to work with Sphere's API since 1.5. We need one or two definitive projects to demo and test as much of Sphere's capabilities as possible and the last attempt at it, the Sphere Community Game Esphera, ended in failure for numerous reasons.

First and foremost, I am NOT advocating we create a new community game or even attempt to continue the old one. I would expect attempts at that would produce similarly failed results unless something fundamental in circumstance has changed with those last involved.

What I AM advocating is a master suite of API tests and/or tech demos. With Sphere-compatible engines being built with vastly different libraries and coding methodologies, we need something that will make sure there is as little fragmentation as possible with regards to output; a Circle needs to blit the same size and color no matter if it's on the web or on the desktop, etc.

Let me make clear: I don't care how you as an individual code. You can put braces on new lines or put them on the same line as the statement blocks they accompany. You can use spaces instead of tabs or vice versa. You can use a while loop instead of a for loop or vice versa. I don't care. What I DO care about is that a Circle is a Circle is a Circle, MapEngine aborts at the same line of code on the web as on the desktop and obstructions are handled the same everywhere, and the engine isn't slowed down by five separate statements doing what could be done in two.

I am not asking for unit tests. If you have unit tests even better, but they only go so far before the human element comes into play.

I am not asking for complete games. If you have complete games great, but they're clearly meant to be played fully and completely and expect a finalized engine.

I am not asking for demonstrations of complex maths. We can come up with timing benchmarks later.

I want tech demos. I want API tests. I want things we can put into a single project and let the engine step through them one at a time to make sure engine output matches expected output. My Wave Editor doesn't belong in it, but my old particle flame demo (updated to use the 1.6 ParticleEngine) would. Radnen's Hold the Line and Jump! wouldn't belong, but his chatroom demo (modified to be automated) would. Flying Jester's, casiotone's, and Metallix's personal test scripts for their engines would be right at home, even though Majestic, standard, and Aquatis would be out of the scope of what I'm asking for.

Visit the Functions list to see what we should have for API (even if articles aren't finished), and I'll start compiling a list of submitted demos/tests for engine devs to use when testing for completeness. The managers of the Downloads will eventually host them on our Drive account and hopefully each section of API gets at least two fully functional demos; I recommend some of the newer or more obscure bits of API first so that the easy stuff like images or surfaces doesn't get saturated with demos immediately.

I for one have hit many, many points, especially since so much of the wiki is now lost, where I don't know exactly how things are supposed to work in TurboSphere. Usually I test in Sphere 1.5, sometimes I just choose the most logical choice.

But it would be a very good thing to have definitive tests. For instance, is a line supposed to blit GL style, with each end point centered at the edges of pixels, or the way I do it in software and always have the endpoint pixels filled? Are circles perfect, or are their edges bound by ceil or floor distances from the center point? (In Sphere 1.5, it's floor'ed. That one caught me by surprise).

For instance, is a line supposed to blit GL style, with each end point centered at the edges of pixels, or the way I do it in software and always have the endpoint pixels filled? Are circles perfect, or are their edges bound by ceil or floor distances from the center point? (In Sphere 1.5, it's floor'ed. That one caught me by surprise).

Exactly the kind of things I want to make sure stay consistent throughout all the implementations of the Sphere engine; hit the nail on the head, dude!

I myself will probably take up writing demos for Sound and maybe SoundEffect. Definitely Bezier curves, tho, as I'm the reason kyuu put them in to begin with.

@DaVince: Just giving it a quick look (without actually opening the files), I know that I like the idea of testing some of that stuff on TurboSphere and on Sphere and comparing the results. I'm especially interested to see the mode7 demo, that sounds like a good test for the Map Engine.

Oh, that Mode7 demo is nothing more than me grabbing the backbuffer or whatever's on the map and then transformBlitting that on top... Perhaps it's a good test for not only the map engine but also screen grabbing and special blitting, though...

Can you define me what type of testcases we need? I still have a unittester. I used to blit in different modes (openGL, 8bit and 32 bits), then write the blit to file, and use Sphere to diff the images. We found that way that sometimes, the OpenGL was blitting one pixel off. It'll be fun (and useful for me) to redo some unittest work. So, what needs to be checked?

+1 on surface stuff. I have noticed things are implemented differently for surfaces than for screen: rotations for example go the other way, and certain parameters are in a different order. I know this from creating SphereSFML and noticing the quirks.

Also a lot of map engine checks would be nice. It's good to get a good test suite of the thing that's hardest to code and maintain.

If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

This is what I had back in 2014. I have not done any work on it. I will delve into surfaces (Radnen request), and isolate/remove all 1.6 tests so that it works in classis Sphere 1.5, to serve as a testbed. Unfortunately, it uses a few complex functions, and I am not sure all Sphere derivates can handle them... we will see...