Skip to main content

News

Topic: Sphere SFML v0.90 (Read 106447 times) previous topic - next topic

0 Members and 4 Guests are viewing this topic.
  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Sphere SFML v0.90
Reply #300

Oh definitely, Duktape can never hope to even touch Jurassic without a JIT...


Oh I know, it's just weird to see Jurassic take so long on this. It's just weird. And don't worry about speed (I do because I'm weird like that). You actually have the best engine so far! :P

I've put out a word on Jurassic, see if he gets back to me about that, but I'm not sure it can be helped. He is slowly adding ECMA6 features to it though, so I guess there will be a newer version... sometime.

In the meantime, if I want to continue this engine I'm going to have to think more critically about supporting Lithonite to it's fullest and other quirks I've noticed thus far... but at this point I'm not sure what the benefits are of Jurassic and SFML? I can barely get it to run on Windows and cross platform is just not going to happen anytime soon. <sigh>
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • FBnil
  • [*][*]
Re: Sphere SFML v0.90
Reply #301
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.html

My  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?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.90
Reply #302
The old engine is ancient, not just the SpiderMonkey but the engine itself.  It uses old-fashioned rendering methods which make it inefficient on modern hardware.  Better to put the work into, say, minisphere or TurboSphere which are modern (the former of which is feature-complete with Sphere 1.5) than trying to hammer the old engine back into shape.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: Sphere SFML v0.90
Reply #303

My  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?


I wrote about my thoughts on this in the Sphere 1.5/1.6 thread. TurboSphere has my experimental work, some of which influenced MiniSphere. MiniSphere is a simpler but still fully featured reimplementation of Sphere, which has better performance. It's tempting to try and modernize the old engine, but not that tempting. For me, at least.

If you want help with integrating newer SM (like SM 40) and either my or Chad Austin's Corona forks into the old engine, I would be quite willing to help! I would also like to help switch to OpenAL rather than Audiere. But I don't want to be the maintainer of the original engine.

I would also gladly help make TurboSphere plugins of parts of the old engine, like the particle engine.

...On V8 and SM...

SM is actually faster than V8 is now. It's quite possible they will leapfrog again. But V8 is a huge mess. It has fundamental flaws that make poorly suited for anything but Chrome (and even then it's questionable). It has a demented build process and its API radically changes every release.
SpiderMonkey is quite comparable, if not better performance, and is a much better designed (and redesigned) VM. That's why I ditched V8 for SpiderMonkey in TurboSphere. It was worth throwing away years of V8 knowhow. V8 is just that messed up.

  • Rukiri
  • [*]
Re: Sphere SFML v0.90
Reply #304
I don't post here often, just came to say hi!

Nice work on modernizing sphere, but now that it has sphere 1.5 features wouldn't it be best to move onto other "new" features that have been talked about oh since 2003 but never added?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere SFML v0.90
Reply #305
See minisphere for that.  It has a bunch of new stuff not available in 1.5. ;D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub