Skip to main content


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

0 Members and 1 Guest are viewing this topic.
Re: TurboSphere
Reply #405
lol, you're a legend in my eyes :)

Re: TurboSphere
Reply #406
I've added an alternative to using the MSVC or Intel TBB concurrent queues. Now, the Sapphire graphics plugin can use Unix file descriptors set up as a pipe for threadsafe communication. It's still preferred to use Intel TBB on Unix systems when possible, but setting up TBB can be a pain. Having the option to use Unix file descriptors is just so that this is not vitally necessary anymore. It's also nice, because now there are native threadsafe communications methods on both Windows and Posix systems.

Using a Unix pipe is the default on OS X only, but still an option on Linux and, when using MingW or Cygwin, I suppose it would also work on Windows.

A major reason to use pipes instead of a std::queue wrapped in a mutex (std::mutex or pthread mutex) is that mutexes on OS X are abysmally slow. Using some simple testing, pipes are up to four times faster than mutexes. Of course, Intel's TBB concurrent_queue is still twice as fast as a pipe, and proper lockless concurrent queues are fastest on all the platforms I've tested. But it's nice to have a reliable, reasonable bring-up backend that works on a huge number of platforms out of the box. This would even work with some pretty archaic compilers, since it basically doesn't need the STL, or even pthreads (or any userspace synchronization primitives at all).

As the above gist might suggest, there is also a std::queue wrapped in a std::mutex backend available for the TurboSphere plugin tools. Pthread mutexes are used when there is no std::mutex available, too.
  • Last Edit: July 07, 2014, 04:21:57 am by Flying Jester

Re: TurboSphere
Reply #407
TurboSphere compiles on OS X now. The main engine works fine, including plugin loading and starting games. Unfortunately, only a couple plugins work just yet.

I've updated the SourceForge page, including uploads of the current sources (which, as always, are available on the github page).

I've also began rewriting T5. An outline of what the new T5 will offer is given in a post on the new FJE site. When this is done, TurboSphere will be able to natively and transparently load files to and from archives (zip, tar, etc.) with or without compression (gz/zlib, xz). This will let TS properly run games out of SPKs, or out of any supported archive with or without compression (zip, tar.gz, tar.xz, cpio.bz2, etc).
You'll also be able to save and open files with compression transparently from script, and access files in archives transparently.

The Sphere File object will be updated, too. The new T5 will let you save the key/val files as either their current INI-style or JSON. I'm going to look into other formats (notably BML and XML).

Re: TurboSphere
Reply #408
TS now works as well on OS X as it does on Linux. There are still synchro issues, so it can't draw textures yet. Once those are fixed, it will be able to fully use the Galileo API, which means that Sapphire will have all the old primitives that SDL_GL_Threaded did, but in an extensible way.

It's also paying off that I previously added multiple backends for basic engine features. Since the system library setup is different in OS X than in other Unices, the old code that located and dlopen'ed SDL2 can't find it on OS X. The engine proper used this to display the error popups. Fortunately, I also added a basic terminal backend that it would fall back to if the SDL2 backend failed.
  • Last Edit: July 13, 2014, 07:28:33 pm by Flying Jester

Re: TurboSphere
Reply #409
Now with texturing, windowing, surfaces, images, and primitives.

Some quick stats on the new graphics plugin, all taken on a late 2013 MacBook Pro:

* 4000 FlipScreens per second. This is a hard limit, just like the old 2000 FlipScreens per second in SDL_GL_Threaded.
* 16,000 primitives per second with generic Unix pipes. 32,000 with a concurrent queue (Intel TBB on Unix, MSVC concurrency namespace on Windows)
* 45,000 triangles per second

Given that I'm using OpenGL 3.3 or OpenGL 4.1 depending on the platform, all my drawing in totally asynchronous (particularly from resource uploading and downloading), and all my drawing uses full Vertex Arrays, this should be a powerful enough architecture for a long time. The new graphics API makes it clear what will and what won't be fast, too. It makes graphics object-oriented.

Sapphire also exposes functions similar to Sphere 1.x video drivers, which makes using it from another plugin easy. I'm going to rewrite the old plugins to use this new API. This will also mean that you could use the standard plugins with a different graphics plugin, so long as the exposed interface is the same.

This has taken a long time, but I'm properly proud of Sapphire+Galileo. It fixes all the things that bothered me about SDL_GL_Threaded, about how plugins worked together, and about using the old drawing API with new OpenGL. It replaces all of the APIs I proposed but had reservations about, too (SpriteBatcher, Shader), with a unified graphics API.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: TurboSphere
Reply #410
This is amazing! I know you want to make a better more modern version of Sphere but you had no real direction until now. Your previous direction was more along the lines of "this is cool" and educational at best. But now it seems you've past that and are exhibiting a kind of mastery over the craft. Ok, maybe a bit much, but you get the idea.

Having a well laid out API and looking back at what you thought worked and didn't work is great and this project will be all the better. Plus, you've got it working on Mac! Holy cow!

SSFML has been on the back-burner for some time and it may never achieve multi-plat status (yet), so in the meantime I'm eagerly awaiting each new thing you do. :)

Also, I'll just go say it here: Our newer engines are using compilation approaches to JS and I think it's about time I update Sphere Studio with a fun toy: JSMin. I think it will increase the load/execution times of games by a small degree especially if you are like me and have hundreds of files with only a dozen or two lines of code. Having one giant JSMin'd file would be for the best. Also, I don't know about V8, but Jurassic has to 'spin up' each new file it sees (I think), so that just adds more overhead to it already opening dozens of files.
  • Last Edit: July 14, 2014, 08:03:01 pm by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: TurboSphere
Reply #411
Hmm, wouldn't minifying the source make accurate backtraces impossible?

And yes, until I started working on Sapphire, TurboSphere was very much the victim of 'Ooh, Shiny!' development. That had the advantage of laying a lot of foundations early, but it also meant that very little was fully fleshed out.
  • Last Edit: July 15, 2014, 03:37:30 am by Flying Jester

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: TurboSphere
Reply #412

Hmm, wouldn't minifying the source make accurate backtraces impossible?

Yeah, but it's more for release than for development.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: TurboSphere
Reply #413
Ah, that makes sense. Actually, having proper debug and release settings could be quite nice, there are a few things I can think of that would be well suited for that.

Since I can't poke SDL2 directly from the engine in good faith on OS X, not knowing enough about the system library setup, I wrote a quick Cocoa messagebox backend (almost certainly using the same backend as SDL2 does).

The error is also dumped to the terminal, since you can't select the text in this dialog, unlike the X11 dialog SDL2 provides on Linux.

Theoretically, there is a way to actually make the script's path a clickable link on OS X. That would be really nice!

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: TurboSphere
Reply #414
Two questions:

1. What's the earliest version of OS X that Mac TS supports/will support? Snow Leopard would be SUPER nice, but if there's an inherent limitation like "64-bit only" I'd be fine with Lion. I highly doubt the ability to backport certain features to current Mac Sphere anyways :/

2. Given the use of V8, is there going to be some sort of API for attaching console output somewhere? I know that in my branch of Web Sphere I plan on making heavy use of the JS console for messages from creation functions and such when certain debug flags are turned on, and I would love for a similar functionality on native apps outputting, say, to a given log file or a third-party debugger or something.

Re: TurboSphere
Reply #415
TurboSphere has a soft requirement of OpenGL 3.3 or 4.1 (theoretically, I think you could change the config to only need 3.1? Maybe even a 2.x release, but I can't test that). It will surely work on OS X Lion, I don't really know about Snow Leopard. I mention the OpenGL requirement, since I think that's the limiting factor.

You can always try to compile it on Snow Leopard, the Galileo branch is where I've got it compiling on OS X.

The console API would be simple to implement. I don't have any plans for it in particular, but it sounds like a good idea for a new plugin.

Re: TurboSphere
Reply #416
For those on OS X, you can test out a build here:

This build requests an OpenGL 3.3 context if an OpenGL 4.1 context is unavailable.

I'd be curious to see which versions of OS X it properly runs on. Unfortunately, I only have two Macs to test on, and they have quite disparate versions of OS X on them (Jaguar and Mavericks). I can only say that I know it works on Mavericks.

You need to run it from the terminal, with the extracted folder as your working directory.

If you are on Linux, you can see if the build is currently broken or not by checking the Travis CI page for TurboSphere:

If you are using as ancient an Ubuntu or Debian as Travis, and can't be bothered with things like having a C++11 or C11 compatible compiler, my first suggestion is to use a distro with a rolling release. My more reasonable suggestion is to set 'TRAVIS' to 'true' before building:

Code: (bash) [Select]

export TRAVIS=true

Note that at this precise moment, the plugins are NOT compiled in the Travis build. Very related, case-insensitive filesystems are a scourge upon the world that will destroy us all someday, and I curse Apple for having case-sensitivity be optional for HFS+, but have the factory setup be case-INSENSITIVE. Hopefully someday Apple will use a not-hack filesystem in their OS.
  • Last Edit: July 17, 2014, 07:33:16 pm by Flying Jester

Re: TurboSphere
Reply #417
A couple of super quick demos:

Both of these use a not-quite final API, I'm having issues with JS Accessors in V8, so everything must be done with member functions.

We get easily 2000 FPS drawing just a single image. I tried filling the screen with Sphere logos, drawing about 1000 of them. We still get 600 FPS. It's not linear, we can draw more and more shapes with lower and lower overhead. Even better, using Galileo Groups, we can draw those 1000 logos with a single JS call.

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: TurboSphere
Reply #418
If the forum had a "like post" function, I'd be using that rather than clutter up the thread with an extra post, but I just have to let you know how much I like how you're progressing right now. Once I get back to making games, I'll be sure to do it with TS. :)

Re: TurboSphere
Reply #419
Thanks, that's good to hear!

I've re-added PNG and BMP saving from SDL_GL_Threaded into Sapphire. This time, I'm doing it much smarter. We load libpng at runtime (without any exceptional circumstances, it's possible for TurboSphere to not need it), and we avoid many allocations that I previously had. We also avoid the infinite loop that a failed PNG save incurred previously--that's why it was disabled by default in SDL_GL_Threaded--and now we fail semi-gracefully.

I must admit, I didn't really understand the libpng API when I used it in SDL_GL_Threaded. And it's still a pretty dense library, but at the very least Sapphire uses it much more intelligently.

I plan on eventually adding JPEG, TGA, GIF, and TIFF saving.

The old idea of adding mouse click events in an analagous API to GetKey/AreKeysLeft has been added to the input plugin. I've done it in such a way that it would be trivial to add another kind of input with the same API (like GetGamepadButtons, or GetTouches, perhaps). Also, they basically share the same code but abstract interpreting the event itself--which is good since this API is really not fault tolerant at all, it's extremely important that behaviour is absolutely correct.

I haven't forgotten about the Sphere 2.0 API, these are just stepping-stone API changes I'm making. The new API is somewhere in between Sphere 1.x and Sphere 2.0. I kind of expect a lot of TurboSphere's natively exposed API to stay similar to how it is now, and most of the actual Sphere 2.0 API to be implemented in script from on top of what I am working on right now.
  • Last Edit: July 22, 2014, 03:51:03 am by Flying Jester