Bad things. Because without the logic that is needed to tie it all together, it's anarchy in there.

Code: (javascript) [Select]

var c = new Color(0, 0, 0);

Abort(typeof c) // object

Abort(c instanceof Color) // false

Abort(c.toString()) //  ReferenceError: [name of last variable created with 'new Color()'] is not defined.

So it's impossible to get at the prototype from JS right now.

Ok ^^ against your recommendation I am going to play around with turbo sphere. I like the Delay( ms ) function and I think I do not need advanced graphic function for now. But I have problems running a simple script using the RequireScript function. I wonder if I am doing something wrong with the encoding of the scripts? The editor is showing me UTF_8. ( I am currently playing around with some alternative js editors... but that should not be an issue ) See the screenshot for all details. I double checked the path. The file is there. Both are encoded UTF_8. Am I missing something?

Metallix, are you using the latest version (0.2.2)? I had reported that error to the issue tracker, and I thought Jest fixed that.

That doesn't look like the newest version (which accidentally lost the turbocharger icon and just uses the default windows program icon).

I've seen that bug before, and it was recently fixed.

The newest binaries are on SourceForge right now: Win32 and Win64 Binaries

TurboSphere should be able to handle UTF8, as well. It uses that internally when casting strings out of JS.

The Delay function is cool. It was the first thing I did in TurboSphere where Sphere doesn't really have the capability of doing the same thing.

Yea, usually everyone just "rolls their own" Delay function in script, often not much more than the following:

Code: (javascript) [Select]

function Delay(ms) {var t = GetTime()+ms; while (GetTime()<t);}	// uses Sphere-specific GetTime, no checking on `ms`

Using the Date object would allow greater portability across JS engines, however, so in the future if someone wants to RYO Delay function I'd recommend using that instead.

Well, in TurboSphere, the built in Delay function actually idles the engine and cedes the processor, so that it doesn't eat up all available CPU time. That's why I like it.

Well, in TurboSphere, the built in Delay function actually idles the engine and cedes the processor, so that it doesn't eat up all available CPU time. That's why I like it.

Cool. That's rather handy.

Could you also implement DoesPersonExist and DoesFileExist? These are two more often-implemented but trivial functions that regular Sphere doesn't have. I implemented DoesFileExist for Sphere 1.7, and it appears Sphere 1.6 at least does have DoesPersonExist. I'm not sure about 1.5.

To add to alpha123's request, another reason to have those two built-in is because doing them in script (particularly DoesPersonExist) has been known to cause multitudes of problems in the past.

Thanks! It works I thought I had the newest binaries, but I was wrong.

Yeah, I added DoesPersonExist to Sphere 1.6, or rather tung committed it for me since he had access to the then sourceforge version (but I remember he didn't like it originally since he believed what you can do in code should stay in code, and the interface between JS and the engine should only give you access to Sphere's features, and nothing else).

I'm guessing Jester will only add DoesPersonExist() when he starts the map engine, which would be some time now... Maybe.

@Jester: I don't know how hard it is to write plugins for your engine, but I'm guessing it's not so hard, if you want I could help with coding the map engine. I have emulated it's code once before in another project of mine (how players are handled / the command queue) So I could help you with that when the time comes. But I'm also going to be super busy for the next 33 weeks as I finish my college education.

Yeah, I added DoesPersonExist to Sphere 1.6, or rather tung committed it for me since he had access to the then sourceforge version (but I remember he didn't like it originally since he believed what you can do in code should stay in code, and the interface between JS and the engine should only give you access to Sphere's features, and nothing else).

Well, the problem is doing DoesPersonExist in JS is very inefficient (basically GetPersonList().indexOf(person) > -1... I suppose you could monkey-punch CreatePerson and maintain your own person list, but that gets ugly).
DoesFileExist is a bit annoying to implement, and it turns out Sphere 1.6 (and probably prior) actually has that function in the C++, I just had to expose it to JS in 1.7.

DoesFileExist is certainly something I can add.

I haven't begun the map engine yet. Well, sort of, I've played with the idea and made a couple prototypes. But I'm not calling either of them the base of the map engine. That's something I'm kind of putting off, since it will require some things from the graphics plugin in particular that I haven't quite gotten working to where I want them yet.

Writing a plugin for TurboSphere, as shown in some detail here, is not especially difficult. Certainly no more so that it would be to write it anything that would be included inside the engine itself. I've even written up a couple little functions that make it a bit easier to talk to V8, and I've abstracted a little bit of the SDL-related code as well, to give the graphics plugin more control of the graphics.

The plugin API is still not quite done. I haven't worked out the final system for dependencies yet, just a few config file entries that can control the order of plugin loading. But it's pretty close to what I expect I will have in the end, and I certainly think every part that exists now will be a part of the final design.

Since you've already made a Delay() function, could you add SetFrameRate() to that (and change FlipScreen() to use it too, of course)? It's actually my preferred method of controlling the frame rate because it simplifies the whole thing.

Yes, that could be done.

I'd have to ask, though, since I don't normally do it that way: Does SetFrameRate just throttle the frame rate, or does it also try to catch up after lagging calls to FlipScreen?

Yes, that could be done.

I'd have to ask, though, since I don't normally do it that way: Does SetFrameRate just throttle the frame rate, or does it also try to catch up after lagging calls to FlipScreen?

I'm entirely not sure about this. But I always thought it made the engine wait an exact amount of time after each FlipScreen() call in order to get to n FlipScreen() calls per second. Maybe it just added a small delay in FlipScreen() itself, since only invoking that causes the framerate to actually throttle.