My rendering loop will already be tight to the framerate of the display using CVDisplayLink, so it is already limited. But ill look into it.

FlyingJester, Radnen and I talked yesterday (today? err) about making a new incompatible sphere runtime. It came to mind when I found that GetKey() is very hard to implement for me, because it is Blocking and my whole runtime is non-blocking.
The 'Sphere 2.0' would have the OO API much like mine (shims can make them functions again) and graphics will work differently with vertices and masking and matrices (plus utility functions for applying rotations etc). Also, everything would be async and a game state manager would be built-in. It creates a much more responsive engine and game.
JavaScript like while(1) is what I walked against when writing my engine and in web-sphere.

I think it gives opportunity.

Due to the impossibility of a while(1) game loop in a sphere game for my engine (even if I don't redesign it), makes it already incompatible. So it is not a loss

// Rahkiin

It also makes games going between web-sphere and desktop-sphere easier since the web works like what Rahkiin proposes. I could write the web-frontend (finally) and have it work. I think the fact the Sphere 2.0 API being largely incompatible is brilliant. Otherwise there is no way of easily converting a sphere game to web or to a non-blocking engine like Rahkiin proposes.

It'll simply bring Sphere into the 21st century (finally).

We just need to design it On IRC, that is.

Ghehe, just thought about it: the API is 11 years old (2003, nobody uses 1.6..) and what was in that year? There was no google! It was 4 years before the smartphone appeared. There was OSX 10.2 and Windows XP was just released, together with Office 2003. Chrome did not exist, everybody used Internet Explorer. It was that time! And I was 9... 2 years before I started programming.

Just some perspective.

// Rahkiin

I support this idea.

2003, nobody uses 1.6..

I use 1.6 beta 4. Of course, I am the only one using Sphere natively on Linux (probably in the entire world).
But it's not like 1.6 changed much about the API.

Also, I used Netscape back then. Because I'm just a brown-coat or something =P

The JS-based API is technically a little older than 2003. For reference, I found Sphere in late 2003/early 2004.

Ideally I'd like to see 1.6 finalized on all three platforms first before the massive API shift that is intended to be "Sphere 2.0." kyuu previously attempted to similarly make such a Sphere 2.0 by himself and he quickly got fed up with it, switching from a JS scripting engine to Squirrel and opting instead to create a new engine. I don't want to see another quick flame-out due to an engine update attempt and lose another good programmer to the programming equivalent of insanity

Yes well, as far as I know, it the non-graphics will look a lot like my current design (and implementation), like networking and input and file system. I had not started on graphics yet.
We either do this together, or I have an non-compatible sphere engine for OSX alone

Finishing 1.6 and then doing 2.0 doesn't sound like a good idea to me. 1.6 has a userbase of 0 and has functionality that none of the other engines has, like particle systems.

// Rahkiin

I'm with Neo.

I use 1.6, as does (or did) Radnen.

Finishing 1.6 means we will have an engine that is about twice as fast as 1.5. I've tested, and there are some cases where it is orders of magnitude faster than 1.5.
It also will take monumentally less work than any of the new engines will to finalize 1.6. I've already got Corona and Audiere working with new compilers and new thirdy-party libraries, I have 1.6 running stable on Linux.
I've created a modernized (as much as possible) graphics backend for 1.6, which works on Windows and Linux, and (since I borrowed a little code from SphereGL) I am confident has no show-stoppers in it. At least, no more than SphereGL does.

I can say from experience that the issues facing 1.6 going gold are not that severe.

That leaves only the handful of bugs in 1.6. Most of them could easily be solved by someone who knows more about the map engine than I do. In fact, many of the bugs also exist in 1.5, and are simple fixes. We (and by we, I kind of mean myself and anyone else willing to touch the 1.6 source) just need to identify the bugs, find where they are, and either fix them or mark them as `won't fix'. And I really, really don't think many should be `won't fix' issues.

The particle system is one of the planned plugins for TurboSphere. So is the sound effect generator. A lot of thought and work went into those APIs, and although I know almost nothing about the particle system, I really like the sound effect API.

I am totally fine with you (Radnen and FlyingJester) updating your engines to support 1.6. But I have not an engine that does 1.5, so I am not going to implement first 1.5, then also 1.6, with all problems I have with those APIs due to async stuff, only so I can then work on 2.0 that has not the problems I have with 1.x

// Rahkiin

The particle system stuff, however powerful it is, is possibly the most complicated API added for 1.6; the SoundEffect and SFXR stuff looks simple in comparison.

I'm fine with 1.6 having a staggered release depending on when system-specific issues get resolved. Previously one of the stopping points was that neither Rhuan nor myself was able to go in-depth on the Mac builds (there were issues either with updating zlib or updating SpiderMonkey, can't remember off the top of my head) so OSX compatibility held up 1.6's improvement for a long time. If Sphere 1.6 compiles on MinGW especially I will be ecstatic.

I would like to make a small notice:

Sphere for Mac, before also called JSphere (by me alone), is from now on called: Andromeda. And it implements the Pegasus API. (They are both constellations )

// Rahkiin

Just a note on the mention of what happened with 1.6 and osx I believe the issue was that 1.6 depended on a newer version of spider monkey which was not PPC compatible at all some of its source was actually in assembler if I recall correctly and I didn't have the knowledge to even know where to start porting that (well the starting point would have been to spend months studying...) I'm sure an intel mac port of 1.6 wouldn't be too tricky but:

I still only have a PPC Mac and so can't help with newer versions. (I have a work computer I'm not allowed to install my own programs on but that otherwise does everything I need hence buying a new computer would be for fun/hobby purposes only and it's a lot of cash for such)

Yes double posting... But significant change to previous post.

I have 1.6 running on my old PPC mac.

Can't remember when I compiled it successfully or what dirty hacks I did to the source to make it work, it must have been years ago.

The binary is universal so should run on Intel.

Said mac has no internet connection anymore though so I can't think of a way to distribute it.

Did I really not share it with anyone way back when?


I've also just found what I think is the Xcode project I used to compile it, but it throws a 1000 errors if I click compile now...

Said mac has no internet connection anymore though so I can't think of a way to distribute it.

Did I really not share it with anyone way back when?


I've also just found what I think is the Xcode project I used to compile it, but it throws a 1000 errors if I click compile now...

Zip it up, put it on a flash drive, bring that flash drive to your work Mac, then send it to me and I'll upload it to Spherical. Send me that project source as well.

I don't have any working compiled copies of 1.6 Mac from you or compiled myself, otherwise I'd have put them up when I restored Spherical. I think you gave me some XCode project that was an attempt at 1.6 but I never got it to successfully compile on my Intel 10.5 Leopard MBP at the time.

I'd have to buy a flash drive then use a friends computer to email it. I might do at some point but it won't be soon.

The reason for the project not compiling seems to be two fold:

a) loads of hard coded locations for dependencies (and I've moved stuff around)

b) at least one dependency I deleted to save disk space...

Also I've looked it over and it may not have some of the features 1.5 should have as I think it still uses JS 1.5.