Welp.

Not really sure what to say, considering Sphere hasn't been more alive than it currently is since ages, thanks to all the development going on here. But what I do know is that there are plenty of successful game engines that don't have a browser-based thing, and they're doing great. Sphere fills its own niche, and having it work in the browser is currently considered a great extra by most. It's more important to have a modern version of the engine and editor, first, if you ask me.

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.

If you're talking about "splitting up development", you mean in TurboSphere, TurboSphere and TurboSphere? Because that's where the engine development mainly is. Radnen is doing an editor. Sphere 1.7 isn't being developed any more as far as I know.

Edit: kay. Went as far as deleting his account. Not sure what exactly happened, here.

o_O
Uh, thanks DaVince.

Sphere 1.7 isn't being developed any more as far as I know.

That's correct, although if I feel like prototyping any new features I might work on it. The big issue is the age of the code: the SpiderMonkey API has changed SO MUCH in newer releases that it's as difficult to upgrade to SM 24 as it would be to switch to V8. Even 1.8.5, which I tried to upgrade to, has changed enough that the current 1.7 has a nasty habit of crashing due to some changes in garbage collection and compartments that would probably require changing a lot of code to fix.

...huh.

It wasn't I who tried to embed Sphere, it was Eggbert with JavaSphere (or perhaps it was another person and another project as well), but it wasn't me.

I think you shouldn't really be hitting any problems with GC compartments, though. I thought that in this case, you'd only have one compartment (unless this has to do with having a startup game)?

Speaking of prototyping new features, are you still planning on making a sqlite plugin for TurboSphere? I'd really like to get some outside feedback on the plugin system, ideally from someone who is trying to actually use it.

I think you shouldn't really be hitting any problems with GC compartments, though. I thought that in this case, you'd only have one compartment (unless this has to do with having a startup game)?

I'm not fully sure what my problems are, actually. I highly suspect them to be GC related though. The compartments thing came from the fact that 1) they didn't exist pre-1.8.5, 2) they gave me a lot of trouble when I was upgrading, and 3) the documentation on them is extremely scarce. I work on the open-source RTS 0 A.D. and we have a very smart guy working on upgrading to SpiderMonkey 24 (from 1.8.5) and it's very difficult. Fortunately we're one of the most prominent SpiderMonkey embedders and got some help from the SpiderMonkey team. Unfortunately Mozilla basically stopped caring about embedders after about version 1.8.1.

Speaking of prototyping new features, are you still planning on making a sqlite plugin for TurboSphere? I'd really like to get some outside feedback on the plugin system, ideally from someone who is trying to actually use it.

Oh, yes, I almost forgot about that. I'd be happy to. I'm pretty busy with school right now and have 3 programming projects going on (a Common Lisp web app, my RPG using Sphere, and a platformer with Love2D).

The big issue is the age of the code: the SpiderMonkey API has changed SO MUCH in newer releases that it's as difficult to upgrade to SM 24 as it would be to switch to V8.

I'm not fully sure what my problems are, actually. I highly suspect them to be GC related though. The compartments thing came from the fact that 1) they didn't exist pre-1.8.5, 2) they gave me a lot of trouble when I was upgrading, and 3) the documentation on them is extremely scarce.

I didn't really expect this. I knew Sphere was old, but I didn't think it would be like that. I guess that helps to explain why no one seems to be, or as I thought they should be, (as I've thought they would for quite some time) wondering why I would bother to reinvent the wheel instead of fixing up the old one. I always thought I was taking the hard way out, starting from scratch and using a different JS VM!

Oftentimes starting from scratch is less work in the long run than trying to modernize outdated code.

o_O
Uh, thanks DaVince.

Lol, sorry if I jumped to conclusions! It's just that not much visible has been happening in that regard, you know? Though I do appreciate the work you did so far.

Lol, sorry if I jumped to conclusions! It's just that not much visible has been happening in that regard, you know? Though I do appreciate the work you did so far.

Haha, you didn't jump to conclusions at all! I was thanking you for deleting the odd fellow.
Like I said, you're correct about Sphere 1.7 not being developed anymore.


By the way, what are the possibilities of using Sphere with NaCl in Chrome?

By the way, what are the possibilities of using Sphere with NaCl in Chrome?

Do you mean as a glorified webapp or porting the work done on TurboSphere? If the former, I'm sure that both pixi.js and three.js (and whatever third web framework I may choose to experiment with in the future) have some way of tapping into NaCl (either built-in or allow some external shim to hook into the NaCl APIs) to take advantage of its capabilities. If the latter, maybe Jester's done some research in to that.

I stopped my port at drawing primitives. But I see in the pixi.js roadmap, primitive support which is nice. My only concern right now is trying to read in windowstyle, map, and spriteset info.

This test site has an example of a loaded windowstyle. But I'm not too sure about it. http://radnen.tengudev.com/spheretest/test.html

@Radnen - Your ParseData might be taking data[64] as a byte instead of as a 16-bit LE word, same with data[66]. Maybe fixing that will fix the loop for that singular bitmap (the top-left corner it seems)? Also, your loop is only going 1 byte at a time instead of taking the 32-bit RGBA pixel at once.

Also, how does one specify a v2.1 RWS as per the doc?

Lol, sorry if I jumped to conclusions! It's just that not much visible has been happening in that regard, you know? Though I do appreciate the work you did so far.

Haha, you didn't jump to conclusions at all! I was thanking you for deleting the odd fellow.

Sorry, that was poorly worded by me. I meant he deleted his own account!

Do you mean as a glorified webapp or porting the work done on TurboSphere?

I mean the latter, trying to get TurboSphere to run in NaCl.

Sorry, that was poorly worded by me. I meant he deleted his own account!

@_@

Lol, sorry if I jumped to conclusions! It's just that not much visible has been happening in that regard, you know? Though I do appreciate the work you did so far.

Haha, you didn't jump to conclusions at all! I was thanking you for deleting the odd fellow.
Like I said, you're correct about Sphere 1.7 not being developed anymore.


By the way, what are the possibilities of using Sphere with NaCl in Chrome?

I know that V8 has a makefile for NaCl (although I've never seen anything about using it). And TurboSphere has been pretty good about porting so far--getting V8 compiled is almost always the struggle I've had.

It might help that I'm also working on both a permanent replacement for the SDL 1.2 graphics plugin, a shiny new SDL 2.0 plugin, and also an SDL-less OpenGL graphics plugin (ideally to make ports to Android or iOS easier--if Apple ever allows run-time code generation on iOS).

Also, how does one specify a v2.1 RWS as per the doc?

I believe the options make one that properly takes advantage of edge offsets with the old editor are in the background properties (the same place to specify a background gradient).