Skip to main content

News

Topic: TurboSphere (Read 190617 times) previous topic - next topic

0 Members and 4 Guests are viewing this topic.
  • Rahkiin
  • [*][*][*]
Re: TurboSphere
Reply #390
You might be confusing your terms here:

You can't run contexts over multiple threads. Not without locking the isolate, which means there is no performance increase. You might want to run an Isolate per game though, and one Isolate per thread.

As my L8Framework is designed not only to be used for my Sphere runtime, it is a bit more complicated :P At least for 1 isolate and 1 context it works just fine :)

Re: TurboSphere
Reply #391
I wouldn't run contexts over multiple threads. The backends are clean of any V8 usage. The graphics backend is a mostly a combination of what I learned trying and failing at making OpenSVD and the core functionality of FJ-GL, for instance.

I would have one context scope, one context and one isolate per game. I mean that I could have a single set of worker threads that were used by all games, and all games shared the same work queues in them. I like the idea a lot, but oh-me-oh-my-oh would it be a lot of work to implement.

As it is, one context and one context scope. They only need any manipulation when a game starts or stops.
  • Last Edit: March 18, 2014, 09:22:25 pm by Flying Jester

  • Rahkiin
  • [*][*][*]
Re: TurboSphere
Reply #392
But then there is always the most important question: Will it be used?

Who plays 2 games at the same time on the same machine?

Re: TurboSphere
Reply #393
That's a big reason why I am not going to make it work that way.

Of course, I'd like to think of TurboSphere as more of a desktop JS toolkit, something akin to Node.JS but with a greater focus on multimedia usage. If that kind of usage is properly realized, then such features would become more useful.

Re: TurboSphere
Reply #394
Er, I often play two Sphere games at the same time on the same machine to test networked games. Also I've been thinking of/slowly working on a Sphere Debugger that runs as a game and attaches to another running game.

Re: TurboSphere
Reply #395
I was speaking of adding server-client type facilities that specifically address multiple games running in one instance. I'm just going to leave it be, one game per engine instance, for the foreseeable future.

It's true that it does happen (I do the same thing, testing server-client functions without worrying about the network, using two machines, etc.). But having two games share the same backend (more like  how a web browser works) would be tremendously complicated. Simple in theory--but it would be a LOT of work to implement, and would cause at least some overhead when only one game is running.

Running two instances of the engine at once is still quite possible, though. That should always be possible.

Considering a debugger, it would be fairly simple to make a rudimentary piping plugin for TurboSphere that would let a second instance examine the JS stack on another instance.
But V8 already has GDB debugging integration. Or so they say--TurboSphere is always distributed with a V8 library that has that enabled. But there is, as with almost everything Google does, no documentation on how it works or how to use it.
  • Last Edit: April 18, 2014, 02:59:19 am by Flying Jester

Re: TurboSphere
Reply #396

I was speaking of adding server-client type facilities that specifically address multiple games running in one instance. I'm just going to leave it be, one game per engine instance, for the foreseeable future.

Ah, like web browser tabs for Sphere games? Yeah, I can't see that being terribly useful. I can think of some cool stuff involving minigames inside e.g. a larger RPG, but there are other ways to do that involving much less effort.

Quote

It's true that it does happen (I do the same thing, testing server-client functions without worrying about the network, using two machines, etc.). But having two games share the same backend (more like  how a web browser works) would be tremendously complicated. Simple in theory--but it would be a LOT of work to implement, and would cause at least some overhead when only one game is running.

Better to work on other things then, and maybe revist this in a few years after everything else is done. =P

Quote

Running two instances of the engine at once is still quite possible, though. That should always be possible.

Good, I was getting a little worried there. :)

Quote

Considering a debugger, it would be fairly simple to make a rudimentary piping plugin for TurboSphere that would let a second instance examine the JS stack on another instance.
But V8 already has GDB debugging integration. Or so they say--TurboSphere is always distributed with a V8 library that has that enabled. But there is, as with almost everything Google does, no documentation on how it works or how to use it.

That would be awesome, because my current solution is extremely hackish. It involves recompiling the code to add instrumentation and then using the network functions to push to the debugger whenever something changes. Suffice it to say, it doesn't work currently. :P

  • Rahkiin
  • [*][*][*]
Re: TurboSphere
Reply #397
There is the D8, the debugger for V8. Works just fine. You just connect to the app and you can set breakpoints, do traces etc.

Also, multiple isolates is not that hard, the problem will be the multiple opengl contexts I think.

Re: TurboSphere
Reply #398
It's more difficult than having discrete processes for multiple games. This would introduce layers of complexity I am not prepared to manage.

Re: TurboSphere
Reply #399
Given the general silence around here lately, I'm going to post a status update, since I have been working on TurboSphere, day after day, week after week.

The new graphics API (Galileo), which has been outlined as a part of the new Spher 2.0 API (Pegasus) is now functioning. There are horrendous issues still with texturing anything but a triangle, but it is working. It's threaded, allowing pipelining and asynchronous drawing. I've added a new version of FlipScreen in addition to the traditional version. This new version doesn't clear the screen. This lets you do partial redraws if you want, or merely draw on top of the previous scene. TurboSphere supports several additions to the new graphics API, which make it simpler to do things the old Sphere 1.x way (for instance, you can still do a direct blit of an image or surface, and load an image directly instead of loading a file as a surface and then converting to Image).

The old Surface threader has been improved, as I have properly learnt a lot more about lockless programming. It now is basically a garbage-collected heap of operations, with links based on per-surface operations. This lets it check, extremely quickly, if a surface is dirty or clean, lets it do out of order, per-Surface operations without interrupting operation queueing, and even means more surface operation threads could be run (although I'm keeping it to a single worker thread for now).

I've added the ability for the audio plugin to dynamically load any appropriate proprietary Bass library plugins from the root directory of TurboSphere. I also made the midi plugin optional (but distributed with TS by default). The main purpose of this is to add additional codecs for playback.

I've fixed about a million minor and aesthetic bugs with game loading. Ideally this is to make the game loading API cleaner and work properly, but I still haven't done that. There is a magic hook in TS to force it to work, but this only works if all the loaded plugins support it. According to the plugin API, it's not really a TS plugin if it doesn't work, but until now there was no actual test to see if a plugin was meaningfully supporting the Close() operation (and indeed, a few of my own standard plugins had issues).

The InputSDL2 plugin now supports Android-based touch interfaces as pointing devices--if only the graphics plugin supported GL ES! The actual engine binary can be compiled as a shared library, which means you could, theoretically, call it with JNI-bindings, and run TS on Android. I just haven't tried that, mostly since I know that the graphics plugin needs full OpenGL 3.1 at least, and it isn't even fully working there yet.

Rahkiin and I have been working out an API for querying extensions to the core API, and TurboSphere now implements it. This is especially important for an engine like TurboSphere, where your game might need to know what plugins exist, specifically by asking what capabilities are present. But other engines could also use it to say whether or not a dynamically loaded library could be found at runtime or not (for instance, a Windows engine probably shouldn't demand you install Bonjour to work at all--but if you have it installed, it would be cool to use it).
  • Last Edit: May 31, 2014, 12:21:14 am by Flying Jester

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: TurboSphere
Reply #400
That's a lot of progress, nice work! :)

Re: TurboSphere
Reply #401
And now it almost--very almost--compiles on OS X. Mostly I'm adding alternative implementations for the Linux bits that are GNU, rather than early X/Open or SYSV bits. And figuring out the standard programming and deployment guidelines for OS X, too.

If anyone is curious about how the world looks to TurboSphere, at compile-time and run-time (especially gfx and threading) configuration, here is what is going on:

At compile time, there are two kinds of machines: Unix and Windows.
Or at least, there are machines were we have common Unix headers (we specifically look for the SYSV versions, although we also check in the X/Open locations), and there are machines with the MSVC runtime library. This isn't dependent on the compiler.
There are two kinds of compilers: GNU compilers (these include Clang and MingW) and MSVC compilers (this includes the Intel Compiler and formerly DMC). This just affects the specific switches we give the compilers.
OS X is a special case of Unix--while we normally go through some configuration to check for header locations and versions, we just use the OS X standard locations when we are running on an OS that identifies itself as Darwin.

At run time, it's a little different. TurboSphere has a composite architecture--that is, there are a series of interfaces in the code, and for each one we select a certain implementation to use for that interface. Most of the time the interfaces are to abstract Windows from Unix, although not always. For instance, when you call  Delay() from script it becomes a Win32 call in Windows, an X/Open call (usleep2) in Linux, and a Mach kernel call in OS X.
There are also a couple places with multiple libraries that can be used. For instance, the new drawing API can use the Intel Thread Building blocks concurrent queue implementation, or the Microsoft implementation, or (if neither are available) simply a handmade queue wrapped-in-a-mutex. Similarly, when available we use the Intel TBB atomics, but lacking those we use C++11 atomics. Lacking even those, we fall back to SDL2's spinlock atomics.

At run time, TurboSphere recognized three kinds of machines: Machines with OpenGL 3.2, machines with OpenGL 2.0, and machines with OpenGL ES 2. We don't really support pure GL 2.0, we require certain ARB extensions for a some functions (specifically non-pot textures, vertex buffers, and vertex arrays), but we do get along without shaders and use the older initialization system. In GL ES, we remove some calls, and again rely on the GL driver being more than just a core implementation.
TurboSphere does not use any extra OpenGL headers, only the very core GL/gl.h, which isn't much. When we need more advanced functions--so basically everything but generating GL textures--we use run-time loaded function pointers. This has some advantages over just using headers--we never blindly try to use something that isn't there--and over extension querying, which (more often than you'd think) under-reports the implementation. Extension querying also is especially unreliable if you aren't using the default GL version and profile, which TS almost never does.
  • Last Edit: June 09, 2014, 09:22:46 pm by Flying Jester

Re: TurboSphere
Reply #402
The TurboSphere source just got a new coat of paint. Or at least I'm staging things for it. I've made the directory tree much more appealing, and I'm working on making the build system much cleaner. The first is a simple task, the second is not so bad since most plugins need their scons files rewritten anyway with the new version of V8 and the new use of SConscripts.

The new build setup will make it simpler to build install TurboSphere, taking the number of commands to build and install from three to two--one to build the entire source, and one to install or package depending on the platform. The new build setup also puts each plugin in a configuration jail, only giving the ability to modify the global configuration state to the core build files that actually need that ability, which set the build up for everything else.
It also means that the build files will actually be in the same place as what they build or what they configure for. Which is much nicer!

Edit: The new build system is mostly working, just a couple little bugs. The way it works, for configuration the main Scons file simply calls the scons script from where it wants to import includes and libraries, and those are returned in an environment that extends the old one. And most importantly, you don't have to keep hammering Scons over and over again to get the build to complete, it just does it all with a single command.

I really need to find a convenient way to pass data from Scons/Python to make, so that I can have better integration of make-based plugins. Not that I have any, but I'd like the environment to be as welcoming to anyone who wanted to make a plugin as possible.
  • Last Edit: June 12, 2014, 03:12:38 am by Flying Jester

Re: TurboSphere
Reply #403
Your such a legend Jester :)

Its sounding awesome. Cant wait to start building projects with your baby :)

Re: TurboSphere
Reply #404
Thanks! Don't call me legend until it gets released :D There is still lots to do, and right now the engine can only just (almost) draw triangles again.
  • Last Edit: June 20, 2014, 01:22:27 am by Flying Jester