Somehow I would prefer having FlipScreen() not changed how it currently works, because it should just flip the screen buffer like it name suggests. So a FlipScreenDelay( ms ) seems much more appropriate. Also you can write that function as a system script instead of hardcode it in the engine.

Somehow I would prefer having FlipScreen() not changed how it currently works, because it should just flip the screen buffer like it name suggests. So a FlipScreenDelay( ms ) seems much more appropriate. Also you can write that function as a system script instead of hardcode it in the engine.

But the thing is, old Sphere had a SetFrameRate() which (I think?) directly affected FlipScreen() anyway, so if Jester were to add it in like this, it actually *would* be how it originally worked! That is, if it indeed did work like that.

Besides, if you never invoke SetFrameRate(), FlipScreen() just works like it always has: working as quickly as it can.

If that is the case I would agree on that solution. But -I think- the SetFrameRate was only affecting the MapEngine. I can't check it out currently...

If that is the case I would agree on that solution. But -I think- the SetFrameRate was only affecting the MapEngine. I can't check it out currently...

Nope, there was a separate function for that, SetMapEngineFrameRate().

Haha wow I think there are still things I can learn about the old Sphere ^^
Ok I have no objections then.

Alright, I have DoesFileExist, font.wordWrapString, and font.drawTextBox (including the escaped character parsing) working. I'll make a release in a bit, there's a couple things with DoesFileExist that I need to port back to Windows.

I'm also working on making the small(ish) change to let TurboSphere use V8>3.15. I've been holding pretty steady with 3.15, but I need to make this change if TurboSphere is ever going to use V8>3.15. Plus, this change (coupled with the new V8 function that needs it) will significantly reduce the overhead of parsing TurboSphere objects out of JS and back to the engine. It will also improve the speed of calling any object's member function that is defined by the engine or a plugin, and possibly of internal calls as well (it certainly won't hurt). So there's a lot of cases where it will provide at least a modest speed boost without even considering the performance upgrades to using newer V8.

So I'm curious, is TurboSphere's ultimate goal to be a drop-in replacement for the current 1.x engine? That's the vibe I'm getting, but I want to make sure.

Oh, and I also have to ask: It won't go Turbo and deliberately introduce game-breaking glitches into my game out of jealousy, will it?

It is mostly a drop in replacement for the 1.x engines, yes.
At the same time, I've made a few minor changes that there had been talk of adding to the 1.x engine for ages (like using proper constructors for Sphere objects, for one).

It's not ready to be that just yet, though. You can theoretically make a full game with it right now, but for one it's missing a lot of the Sphere functions still (including the entire map engine and any sound or networking support).

If it does go Turbo and takes over your game, and possibly your computer and house and city, just open an issue on GitHub and I'll see about fixing the megalomaniac behaviour.

So I'm curious, is TurboSphere's ultimate goal to be a drop-in replacement for the current 1.x engine? That's the vibe I'm getting, but I want to make sure.

It is mostly a drop in replacement for the 1.x engines, yes.
At the same time, I've made a few minor changes that there had been talk of adding to the 1.x engine for ages (like using proper constructors for Sphere objects, for one).

Once it reaches stable WRT replacing 1.5, I'd recommend having some console output (eg, "Warning: xyzFunctionality is TurboSphere specific, please consider rewriting code to be compatible with Sphere Engine vM.N" or something) whenever TS-specific API is used. Once it reaches 1.7 (the most recent official version currently being developed by ANYBODY) then we can talk about merging APIs if there's any deviation left at that time between vanilla 1.7 and TS 1.7.

Hmm, I should actually add info statements about such things, that's a good idea. Visibility being controlled by configuration, of course.

Saving up for another release? I do the same with my Sphere Studio. I really wanna try out the .wordWrapString() though. Did you look at the original source or did you try to re-implement it? Just wondering, because if you did not copy the original source, then I can't expect the same reliability. I hope that your implementation may fix any bugs or issues that were present in the old function (though there are no bugs that I know of right now, which means, at the very least, it is your implementation that could have bugs in it).

I reimplemented it.

I tested it fairly extensively, and it seems to work pretty well. At the moment, I know of no way to make it misbehave. I'll bet there are bugs to be found in it, though!

If you are really itching to try it, that change (and the addition of .drawTextBox) has been pushed to the github repository, which compiles using MSVC 2010 just fine for me (and it may work with cl.exe and scons using the MSVC command prompt too, although I haven't pushed the exact changes I've been using to do that just yet). You'd need to compile V8 from scratch, and get the SDL .libs, though.

Well, someone has seen Wreck-it Ralph.

In any case, you're making a lot of progress now, and I am looking forward to the next release!

Question (since I haven't checked things out in a while): is a startup game still supported? I'm going to be trying my hand at writing a new one.

Not yet. The functions to switch games while the engine is running don'w exist yet. The only way to start a game other than the one in the startup folder is to start turbosphere(.exe) with the path to the game as an argument (I think I made that work the same way engine.exe does it).

Well, someone has seen Wreck-it Ralph.

Haha, indeed, and that movie was awesome. Every gamer owes it to themselves to see it at least once, if only for the nostalgia factor alone. The filmmakers really did their homework there. The fact that the story is great is just icing on the cake (no pun intended, I swear! )