I applaud your efforts Radnen, but yes, if we are going to pull off another release, we will need consensus about the engine (the editors, I like them to be numerous, as each user using them can see which one is more comfortable. For *.js coding I do not use the editor, I use notepad++, the graphics I edit in other programs, and paste them into the editor. Especially with fonts, where I export to a PNG, edit it, then use a converter program to put that back into a .fnt file. While other would prefer to only use one tool...). But the engine... we should concentrate efforts on one. Especially because our numbers are dwindling.
As you might remember, the big problem with 1.6 was stability of the build. I was never able to duplicate the stability 1.5 had.... even with 1.5 sources. Which meant that the MSVC compiler was either buggy, or I could not find the perfect settings. Even after rewriting parts to remove warnings, the build was never stable. A shame too, I saw Anatoli write the best optimized code for displaying. And was in awe at what the particle engine could accomplish.
I guess goals are lower now, and it is to recreate the Sphere 1.5 functionality. But we have 3 options:
1. Keep going with the 1 man - 1 Sphere fork. I can help with the requested test cases, will start this week.
2. Choose one, and work together on that one to get it up to par. (basically what the Verge team did with IKA)
3. change scope and hope for new users and developers. (very hard to pull off)
I like the fact you are using node.js as networking glue. I like the fact Sphere had networking, and somebody actually made a webserver back in the day.... (doing what node.js does now, but way earlier)
Sphere still is unique. It works like imagemagick, in that you can generate graphic images with external data. Ten years ago, I created performance graphics that way at work. (combined with irfanview batch processing to convert the graphics to smaller jpg's (both in size as well as dimensions))
It works as javascript test case software. Where I coded ITM5 monitors (IBM Tivoli Framework) in Sphere. Using mock input, and knowing the expected output, I used it as testcase-first programming. Then moved the tested functions into the monitor template, builded it, and did the real test with real data. As I could program it everywhere, I could work on the train, and test each change with arrow up + enter (commandline sphere). Fast iteration = Very productive hours.
Granted, there is better software now to do what I did back then with Sphere, but it was used that way, by me, on purpose.
Oh, and a primitive mathjs viewer, where you could actually display values, plot them or save them to file. But now, browsers have come a long way:
http://mathjs.org/examples/browser/plot.htmlMy main question (better asked in another post, but why not here) is if we have to put efforts into the main branch... making it compatible with the new JS, which has renamed quite a few functions... at least to try to see if it is fast as V8?