GitHub repo: https://github.com/sphere-group/sphere (engine should eventually be split into https://github.com/sphere-group/sphere-engine)

SourceForge: http://sourceforge.net/projects/sphere/

Hey, so here's a question.

I saw in the 1.6 source the following (https://github.com/sphere-group/sphere/blob/master/sphere/source/engine/ss_functions.table#L117):

  SS_FUNCTION(DeflateByteArray, 1)
  SS_FUNCTION(InflateByteArray, 2)
  SS_FUNCTION(DeflateFile, 2)
  SS_FUNCTION(InflateFile, 2)

These functions are exposed to script. Does anyone know how they work or if they work, and why they are not a part of the documentation?

FBN added that, and AFAIK it works completely. There was a test suite that released with the 1.6 binaries that showed off all the new neat additions from an sfxr inspired wave editor to particle effects.

What Radnen said.

The *flate API was to finally expose zlib functionality to Sphere coders instead of limiting it to SPK processing or as a supporting library for PNG et al. 1.6 was supposed to finalize all of kyuu's additions (the built-in particle system, etc), FBN's additions (the aforementioned SFXR, zlib, etc), and various cleanups by tung et al in preparation for not only alpha123's 1.7 work but also kyuu's proposed migration to an API closer how JavaScript already works (what was supposed to become Sphere 2.0 and instead became his squirrel prototype).

I highly recommend we work any remaining bugs out of vanilla 1.6 so that it can go gold. Most of the bugs seem to be concentrated on the map engine (surprise surprise) and a bit in the new stuff; I also wanted some vetting of the particle system since even though kyuu documented it thoroughly it's still a bit confusing to work with out-of-the-box, as well as field testing for myself the SoundEffect API.

I believe it would also be useful to fix Corona so that it at least compiles on a modern(ish) system. The only thing stopping it from compiling for me is the PNG component, and it just seems to be because of differences with the newer versions of libpng.

I suggest that the overwriting of sgm files be removed, as well (if it isn't already from 1.6).

I have read through the Sphere source on github a bit. I don't know why the SDL driver doesn't use doublebuffering mode--I don't think there's any reason not to, ever.

I've also found that the 1.6 editor defaults to saving scripts as PHP when no extension is given. But I don't really expect bugs in the old editor (or small inconveniences in this case) to be fixed.

Wait, zlib functionality was exposed in 1.6? Man, this needs to go on the wiki somewhere.

I know. I wanted to do this in TurboSphere, and I'm glad that the API already exists for it.

I have patched Corona to work with libpng 1.5, the newest version distributed with Fedora 19. It works (at least somewhat) on my computer, but it would be nice for someone with Windows to try it out. It's going to take more for it to fully work, specifically saving PNGs doesn't seem to work anymore. But it's better than it was.

EDIT: I take that back. It seems to work perfectly.

I suggest that the overwriting of sgm files be removed, as well (if it isn't already from 1.6).

Whoever thought this was a good idea, anyway?  From an engine standpoint there's no reason to modify the .sgm file at all.  This still baffles me.

If we can find the exact location in the vanilla source SGM handling takes place on game start/end, I will fully support changing its behavior.

We will need a check against unsupported modification of it and we need to define what actually happens if/when the currently running SGM file is modified in script by ANY file edit function (eg, changing window size/resolution in a config menu and calling RestartGame() like so many older scripts do).

I updated Audiere to compile using GCC 4. Most of what needed to be done was to add some header includes. If it doesn't yet compile with MSVC, this had to be done to make that happen anyway.

EDIT: After a lot of work, I got the latest Sphere sources from github to compile on Linux. I've put my changes on GitHub.
Most of the work was adding #includes to cstring, memory, and cstdlib. I also found a couple places with mismatched #defines removing a definition but not a use of some variables in Unix, and an issue with the scons file.

I still don't quite understand that last bit, except that I think the old, binary-incompatible version of zlib seems to be referenced somewhere in Audiere or Corona, so you need to prepend a zlib reference to the environment's LIBS flags for the engine.

I do feel a bit of sincere gratitude to the developers who worked on Sphere in the old days. There were several comments mentioning some of the changes I had to make! Mainly, showing what needed to be done, commented out, mostly if Audiere was never updated fully for Unix--I guess it never was. Sphere has one of the cleanest and best written code bases I have ever seen for a project of its age.

I still need to test this build a lot more, but it looks like (except for the ancient libjs/spidermonkey), I've got Sphere compiled on Linux using the newest stable versions of all the libraries it uses (same with Audiere and Corona), and with the latest version of GCC. I'm pretty happy with that.

Thanks for the work! It will be very nice if we can get something that will compile properly in Linux for the coming time. (And we can get deb packages out of it, of course!) Will definitely be using this.

Speaking of adding Linux compatibility, maybe it'd be a good idea to associate sgm and spk files with Sphere during sudo make install. If it doesn't do that already. Makes it a one-click solution to run Sphere games after Sphere is installed.

(edit - fixed apk to spk ~neo)

Jester, can you do a pull request on the original repo diff'ing your changes so one of us can merge them in, or can you do it yourself since you already have push+pull privileges on it?

No one wants to test it out before it gets puled?

Well, all my changes are guarded so that they don't affect Windows compilation, and it already didn't work on Linux, so I'll go ahead and pull it to the original repo myself.

I can build Arch packages and RPMs, but I don't have any idea about debs (or a machine for testing them on properly). It would be awesome if the final release of 1.6 had rpm and deb packages!

FJ: going to compile it now, will let you know if it works without issues. (32-bit Xubuntu 13.10)

Edit: building fails. Lots of wx errors; do I need a specific version? Never mind, I was missing libwxgtk.
It fails on audiere now, though - didn't realize that was a separate thing in a separate Git. Doing that now. We really need a nice automated build script for these things...

Edit: audiere fails to build. http://pastebin.com/v29kRQ1i

Are you using my version of Audiere?

You need to use the versions of Audiere and and Corona I modified to compile on Linux. The wxPlayer example program in Audiere always fails. You can still run and install without it.

Audiere and Corona

You'll also need some ancient JS. Link here, and choose 1.5. The build instructions tell you use to gmake, but just using make will work. You have to call make on the specific file mentioned in their instructions.