Skip to main content

News

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

0 Members and 6 Guests are viewing this topic.
TurboSphere
Wow, it's nice to have some Spherical forums again!

For posterity:

About TurboSphere

TurboSphere is designed to resemble the Sphere RPG Engine. TurboSphere uses Mozilla SpiderMonkey for JavaScript compiling and execution. Graphics, audio, input, and various other functions available to scripts are provided via plugins. The default graphics plugin is hardware accelerated using OpenGL 3 or 4, and a script-based map engine that implements much of Sphere 1.5's API is included.

Why Use TurboSphere?

TurboSphere continues Sphere's legacy of providing massive power and functionality to script, while having a simple and effective API. It also continues Sphere's use of JavaScript, which is an easy to learn scripting language which can be used to easily code games.

TurboSphere does not attempt to duplicate the exact script functions of Sphere, although TurboSphere's functions are similar, and in general are intended to equal Sphere's.

In addition, TurboSphere boasts several improvements to the original Sphere RPG Engine. These include

- Extensible plugin interface
- No file system sandboxing
- Asynchronous rendering
- Generalized event-based input API
- Support for Mac OS X and Linux

Downloads


If you have Windows (or are using Linux and Wine), download this:
Latest Version, stable release.

Other Downloads:
TenguDev Turbosphere, older stable releases.
SourceForg site, unstable and source releases.

There are no compiled binary downloads anymore. I do not use Windows on a regular basis, and my OS X machine is heavily contaminated with development libraries. If someone wants, I can doctor up some OS X 10.10, FreeBSD amd64, Linux amd64 or arm6, or Solaris UltraSparc IIIi binaries for them.

The Github repo is the main source code repository:
https://github.com/FlyingJester/TurboSphere/

TurboSphere is expected to compile out of the box on Unix platforms with a 10.x release of Mesa or a modern Radeon or Nvidia graphics driver with OpenGL 4.x.

Resources

TurboSphere Function List
Guide to Making TurboSphere Plugins
TurboSphere Plugin Architecture Description


TurboSphere Function List
Introduction to Galileo drawing API

Is TurboSphere Cross Platform?

Yes. Sort of. It is largely cross platform, and all of its components should work on Windows, Linux, Mac OS X, FreeBSD, and Solaris. Additionally, it should work on 32 and 64 bit PC and Macs, as well as many other devices including ARM machines. However, it isn't tested very well anywhere but Mac OS X and Linux, and Linux testing could be better.

Highlights of Current Version

- Support for various gamepads, including XBox 360 controllers
- Partial Map Engine support
- Full audio support for sampled audio, no mod or midi
- Configurable game-function name and sgm file name
- Fast and flexible Galileo drawing API and scene graph
- Font, Windowstyle, Map, Spriteset, and Tileset support
  • Last Edit: March 26, 2015, 08:17:38 am by Flying Jester

Re: TurboSphere
Reply #1
A guide for making TS plugins is up on the wiki. Of course, until I get TurboSphere working in Windows again (the plugin system is only cross platform in a structural way), you can only see it in action on Linux (and maybe Cygwin...?).
I have no idea if how I've implemented the plugins is genius or idiocy. But it's working, and is much better than the monolithic architecture I used up to 0.1.7, so I'm happy with it for now.

EDIT: the plugin system is working on Windows as well, now. I've got the bmpfont and graphicSDL plugins working, which is a very good sign. graphicSDL is by far the most complicated, and bmpfont requires graphicSDL, so I think it's just a matter of making the same changes to the rest of the plugins and compiling them.
  • Last Edit: March 20, 2013, 12:47:53 pm by Flying Jester

Re: TurboSphere
Reply #2

I have no idea if how I've implemented the plugins is genius or idiocy. But it's working, and is much better than the monolithic architecture I used up to 0.1.7, so I'm happy with it for now.

Any plugin system is better than a monolithic engine. :P

That's actually quite fantastic, I'm very happy that Sphere has plugins (especially since V8 doesn't support js-ctypes like I used in Sphere 1.7). That was on my wish list for 1.7, but the old architecture would make that a real headache.

Expect me to write some TurboSphere plugins for sure. :)

Long live TurboSphere!

Re: TurboSphere
Reply #3

Any plugin system is better than a monolithic engine. :P

Definitely true! It's already saving me time and effort adding features. I didn't expect it to, but it's also saving me a lot of time porting my changes back and forth between Windows and Linux.

Out of curiosity, what kind of plugins are you thinking of making?


Long live TurboSphere!

:)

Re: TurboSphere
Reply #4

Out of curiosity, what kind of plugins are you thinking of making?

Things that I come up with for Sphere 1.7 (yes, I do intend to continue that thing), mostly. The first thing that came to my mind was SQLite. Also possibly a pathfinder plugin, as JS pathfinders tend to run out of memory (in my experience).

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

Things that I come up with for Sphere 1.7 (yes, I do intend to continue that thing), mostly. The first thing that came to my mind was SQLite. Also possibly a pathfinder plugin, as JS pathfinders tend to run out of memory (in my experience).


Those are nice to have for RPGs. +1 on SQLite, I've always wanted an easier way of storing values for items, creatures, and players. As plugins they would be appropriate too since you don't have to make these right away, and are optional anyways. It might turn out that your game doesn't need SQL or pathfinding, etc.
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 #6
I'd thought about a pathfinding plugin. Yes, a very reasonable thing to be a plugin indeed!

Also, 0.2.0 Windows binaries are up on sourceforge. It's got the plugin system all working on Windows, with even more plugins than I had working before on Linux. At this point the only thing that was lost in the transition to the plugins is the sound system, which I was rather dissatisfied with anyway.

EDIT:
The source is also up. It's got a couple minor issues on Linux+GCC+Make (you have to manually build the main libraries and copy them to the working directory), but it does actually compile. I've been spending more time on the Windows side recently, so the Linux-side build process is not quite up to what I'd like it to be. I'll get that sorted out in a bit. Nice to know now that it works on Windows too and has MSVC project files.
  • Last Edit: March 21, 2013, 03:47:42 am by Flying Jester

Re: TurboSphere
Reply #7
Have you considered CMake for the build process? It's quite an excellent tool in my experience. Basically, you write a few dead simple files and CMake can generate Makefiles, VS solutions, XCode whatever-xcode-calls-its-projects, and more.

Re: TurboSphere
Reply #8
If I was going to use a tool like that, I would probably choose scons. I've found cmake to be very difficult to get to work at all under Windows, and I've had problems getting pkgconfig for cmake working under Linux. From my experiences with Scons, it has always just worked and worked well.

As it is, I don't think I want to learn a new tool like that. I might as well just keep working on my makefile skills. I may have a look at making a scons file for TurboSphere at some point, if these difficulties persist.
  • Last Edit: March 21, 2013, 04:49:02 pm by Flying Jester

Re: TurboSphere
Reply #9

I've found cmake to be very difficult to get to work at all under Windows

Works great for me. Are you using a recent version?

Quote

As it is, I don't think I want to learn a new tool like that. I might as well just keep working on my makefile skills. I may have a look at making a scons file for TurboSphere at some point, if these difficulties persist.

The nice thing would be you don't have to maintain both a makefile and a VS solution, you could move to a different build system for Linux (like ninja), support MinGW in addition to VS on Windows, etc. Even better you could enable/disable certain functionality depending on what libraries are present; this would be a great combination with plugins.
If you couldn't tell, I *highly* recommend using a "real" build system instead of hand-rolled makefiles; it's much nicer for maintainability. Make not necessarily CMake (although I've had great success with CMake on Windows; haven't tried Linux), but at least something. Scons would be fine as well.

Re: TurboSphere
Reply #10
Yes, I tried to use it late last year to make Fluidity, using the newest version of cmake at the time. I simply couldn't get it working on Windows, and it took a lot of effort to make it function on Linux, but I did get that working eventually.

I do like the idea of having a fuller build system, particularly now that the project is much more complex. But for now I think I will still work on fixing the makefiles. Once I need more than just SDL, freetype, and V8 (which means once I get to the audio plugin) I certainly may start using scons.

As it is, the makefiles do very almost work the same way they do on Linux as they do on Windows with MingW. If V8 could also be compiled with MingW, I would put a higher priority on making that work. You can actually compile the core Configmanager, Graphicalg, and Graphiccommon libraries using the DMC's cl.exe (making larger and slower binaries, though).

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: TurboSphere
Reply #11
Do you use Code::Blocks for non-VS IDE on Windows? I vaguely remember it having some sort of Makefile generation capabilities in it.

Also, now that you have a GitHub account, why not mirror TS source on it?

Re: TurboSphere
Reply #12
Yes, I do use Code::Blocks, and I did use the cbp2make utility to generate the makefiles. But the thing is that cbp projects just aren't quite as advanced as Visual Studio Solutions (they are pretty much identical to a Visual Studio project), and cbp2make doesn't quite work perfectly with GCC > 4.5 (particularly when making libraries). The makefiles are actually more convenient than Code::Blocks alone could be.
Once I realized that CB wouldn't cut it alone, I relegated it to just handling the turbosphere.exe binary. That's all the turbosphere.cbp file (if I even included it) deals with.

Yes, I believe I shall put TurboSphere on GitHub.

EDIT:
And so I did.
https://github.com/FlyingJester/TurboSphere/

Fixed build instructions for Linux.

Oh yeah, and a little change log for 0.2.0:
- Added Plugin System for Windows.
- Lost sound support.
- Regained TTF functions.
- Fixed leaks in font.DrawText, Image.SetPixel, and RequireScript.
- Added Get- and SetClippingRectangle functions.
- Added File object (no members).
- Added RemoveFile and GetFileList functions.
- Fixed a couple crashes related to SetResolution.
- Changed JS-side exceptions to be of more descriptive types (primarily TypeErrors, but a few RangeErrors as well).

Known Issues:
- TTFFont.drawText leaks memory.
- On Linux, SetResolution still crashes when you give it negative resolutions.
- the game.sgm seems to need to have the right line endings for your platform (although Unix-style seems to usually work on Windows).
- TurboSphere crashes on Windows when it closes because the script ends and you only have one script loaded.
  • Last Edit: March 22, 2013, 05:52:02 pm by Flying Jester

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: TurboSphere
Reply #13
Do you have an API list anywhere? I'm curious to see how much you have implemented. And if I could perhaps get started with making some kind of game... I don't need sound right now, but I hope there's enough to create something interactive.
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 #14
There's a mostly complete API doc in the docs directory included with TurboSphere, and on the wiki for it on SourceForge.

As it is, that game I released just after Halloween (The Unwelcome Guest, it's on RMN) was the first properly working TurboSphere game, and was completely playable except for the sound (at that time it would have worked completely had I replaced the .midi's with .wav's). To be fair, the sound didn't work on Linux with Sphere 1.5+wine for me, anyway!

I might as well give a little list of what works right here:

- FlipScreen and game()!
- Loading and drawing of image files (bmp, png, tga, and certain tiff), windowstyles, ttffonts, and Sphere rfn fonts.
- Creation of Image and Surface objects from files or from specs (w, h, color)
- Some of the graphic primitives: Rectangle, Circle, Line, Point, GradientRectangle, OutlinedCircle (Line is even optimized for drawing in the cardinal directions)
- Image[or_surface].getPixel and setPixel, zoomBlit, and the image.width and height members.
- The Majestic Map engine runs on it!
- Color objects and members.
- Setting and getting the ClippingRectangle, identical to Sphere 1.5
- font.drawText, getStringWidth, and drawZoomedText, GetSystemFont.
- ttffont.drawText, drawZoomedText, and ttf.size (which is writable), although the ttf functions are a little leaky right now.
- GetKey, and all key buffer and keyPressed-related functions. All the Key constants (these are listed in the API.txt and in the SourceForge Wiki for TS, there are some new keys recognized in TS)
IsMouseButtonPressed, the related constants (including support for up to 5 mouse buttons), GetMouseX and Y
GetTime and Delay (which actually idles the engine, so that you don't burn up the CPU like Sphere 1.x does)
GetScreenWidth and Height, SetResolution (use that last with caution! It can handle some garbage data, but some still slips through the cracks and causes hard crashes)
RequireScript (mostly, this is just a little buggy, particularly when the files don't have the right line endings for your platform)

...and more things I don't recall specifically. Once I get the File object fleshed out and get sound up again, you could actually make a full game.

I'm missing quite a lot of the advanced graphics features (especially related to surfaces), and some other stuff. If someone was making a game with TurboSphere, and asked for a specific 1.5 or 1.6 function to be added (or something that would be a good thing to have anyway), I probably would do that function next thing, to be honest. It would be very cool to see someone making a game with TurboSphere, and I would want to help as much as possible.

If you were going to make a game and really wanted sound, I could fairly easily make up a soundSDL plugin out of what I had before. It would be able to play wav and ogg sounds only, but it would work. I'm hesitant to do that and include it in TurboSphere proper because I want to make a new and better sound plugin, probably using BASS or IrrKlang.
  • Last Edit: March 22, 2013, 10:58:09 pm by Flying Jester