The main reason the discussion of Sphere as a web app even exists is because we use JavaScript, a primarily web oriented language, as our higher level scripting language and web browsers already have tried-and-tested JS engines running, so why not build a bridge to take advantage of what they already have?

I personally do not think this is a good idea, unless you're talking about sphere 2.0, sphere is ancient.
If you want to develop games for the web try out stencyl, wait for 3.0 though as Haxe will be the default language.

Hmm, but wouldn't you like to see Sphere's easy API usable for web games, too? I personally know I'd like that. And yeah, progress is already being made with this.

I wonder if it's possible to compile TurboSphere with Emscripten and get good performance thanks to asm.js and WebGL. It might be possible with regular Sphere with SphereGL as well. The hard part is we'd probably have to mock V8's API to use the JS VM asm.js would be running on, since compiling a JS runtime to JS isn't exactly good for performance.
Epic Games and Mozilla got Unreal Engine running in a browser with asm.js and WebGL with decent performance, so it should be totally doable. At the moment it only gets good performance in FF 23+, but it will run at some speed in any browser with WebGL.

@alpha123 - before we even consider Emscripten I'd actually like to see any of the four current Sphere versions (1.5, 1.6 beta 4, 1.7 alpha, TurboSphere) compile with Clang or Apple's XCode version first. Most of our compilation instructions assume gcc and while that's certainly reliable for the foreseeable future I'd like to make sure we continue to supply more options whenever possible.

We also kinda need to update the MSVC workflow too...

I would hope that using Emscripten we wouldn't also be compiling the JS engine as well using it.

Since TS seems to compile at least mostly with XCode, I would think that (except for V8) it would work (from a technical standpoint) with emscripten as well. And TS works very well with MSVC, too, using Scons or solution files. But the problem is obviously the JS engine.

Which raises the interesting question of whether you can compile V8 using LLVM bytecode, and then using emscripten into JavaScript to be run (possibly) on a native version of V8. V8 seems to be always on the edge of not compiling right or not compiling at all anyway even when precisely following the instructions. It sounds like a very interesting idea, but also a bit like madness. JS engines (the ones we use in Sphere stuff) go to great lengths to turn the fluid JS to something that can be grappled with the rigid C++. It sounds quite inelegant to then turn that rigid C++ back into fluid JS, and run it on a differently compiled version of itself. The one possible saving grace could be to modify V8 so that its built-in JS code is run on the browser's engine instead of on the resulting engine, but I'm not sure that's feasible to begin with, and I don't think that the built-in JS code in V8 is all that extensive.

It could be useful to use emscripten to compile modified versions of TS plugins (the backends, parts that aren't entrenched in talking to V8) and Sphere video drivers maybe (I'm not sure quite what emscripten is capable of), and have those work with a JS or HTML5 core. That sounds like a much more reasonable scheme to me. And it would mean that quite possibly the same source code could produce Linux, Mac, and Windows native plugins, and web-TS plugins. But that is an aweful lot of work.

Just personally, I'm not sure what is gained by having a Sphere-like API that is run by a browser. I still think a more elegant and much simpler (and likely higher performance) solution would be to perfect a JavaSphere like system. With HTML5 and WebGL, I would think that there may be a way to even redirect the output of the engine to a frame in a browser.

Jest: well that's why the web based Sphere ideas exists: to harness the power of the browsers JS environment for use in Sphere. How awkward would it be to compile the JS engine when you'd be running it in a browser that already has one (and possibly a newer faster version of it too).

The way I see Web-Sphere is that it'll get better / faster as the two main driving technologies: JS and WebGL get faster and better over the next couple of years. And that's all without recompiling! It'll just happen!

well that's why the web based Sphere ideas exists

actually i just wanna put my games up on the interwebs, and i love sphere, thats why i started this conversation. im glad to know such a straight-forward (or so it appeared at first) solution to my problem existed. too bad im such a noob i cant help the idea grow!

welp, since i guess everyone else dropped this inexplicably, i gunna switch from my game into this. and only this.

i love sphere. i want to share it with other people. i want to share what it can do. i want sphere to grow.

welp, since i guess everyone else dropped this inexplicably

Yeah because it's a whole lot of work! You can still share Sphere games with friends though, and someday there might just be a web version of it, but not anytime soon.

Yeah because it's a whole lot of work! You can still share Sphere games with friends though, and someday there might just be a web version of it, but not anytime soon.

too bad everyone isnt working together to find a way to make sphere a better program

Hey, hey, everyone's busy with their own projects, for example without me there wouldn't be an awesome .NET editor for Sphere. And FlyingJester is working on a newer more modern Sphere design called TurboSphere. Just because you can't get an online version of it doesn't mean we aren't all trying our part here.

Perhaps if I wasn't the one working on the new engine (not including 1.7 or Yet Another Sphere Clone, but 1.7 has been dormant and YASC is much younger than TurboSphere), there would be more activity on this front, though.

I will admit it. I don't really care about making the Sphere API available in a web browser.

Of course, if you really want this, Sphere is open source. If you really want it, you can try to compile it yourself using emscripten. You can try and get the Sphere_GL drivers working with WebGL.

ty jester for helping this noob get started, i will contribute to sphere as u all have, i will make this my one goal in life. i thank everyone that has already contributed to this thread giving me lots of ground work to play around on.

whelp, ur right radnen! it sure is alot of work. too much for me. which sucks cause i really liked sphere. well, honestly, like is too weak a word.

i wish u guys luck with turbo sphere, radnen sphere, sphere 1.7, and all the other current ways u have split up development of sphere and locked it down into oblivion without a cohesive future.

ps and the way u guys quit this thread when i brought up the fact that i came up with the idea is both sad and pathetic. enjoy the dead end u guys made for urselves.

...What just happened?