For its age and complexity, Sphere's code is easy to read.

Believe me, I am very thankful for this.  I reverse-engineered a lot of stuff through playtesting, but there were some things, like zone handling, that required a read of the source.  If the original source weren't as clean as it is, minisphere 1.0 would still probably be in alpha.

Nonetheless, some of the algorithms used in it are pretty dumb, like reading strings from a file one character at a time or similar nonsense.  It also violates DRY a lot.  This, for example, happens way too often:

Code: (cpp) [Select]

    if (!m_Engine->IsScriptBeingUsed(m_DefaultMapScripts[which]))
    {
        std::string error;

        if (!ExecuteScript(m_DefaultMapScripts[which], error))
        {
            m_ErrorMessage = "Could not execute default " + list[which] + " map script\n" + error;
            return false;
        }
    }

In minisphere, that functionality is centralized in script.c, so from outside all you see is run_script(s_update_script, false);, which makes the intent much clearer and cuts down on the boilerplate.

Nonetheless, some of the algorithms used in it are pretty dumb, like reading strings from a file one character at a time or similar nonsense. 

This isn't as bad as you'd think. Almost all file reading is well buffered on a modern OS (I mean even vaguely modern, think Windows NT, OS X 1.0, Linux 2.6, that stuff and newer). Plus, std::strings aren't naive, and begin with anywhere from 8 to 255 bytes preallocated (older GCC and Apache, respectively). It was just likely never an area that needed much optimization.

It also violates DRY a lot.  This, for example, happens way too often:

Code: (cpp) [Select]

    if (!m_Engine->IsScriptBeingUsed(m_DefaultMapScripts[which]))
    {
        std::string error;

        if (!ExecuteScript(m_DefaultMapScripts[which], error))
        {
            m_ErrorMessage = "Could not execute default " + list[which] + " map script\n" + error;
            return false;
        }
    }

In minisphere, that functionality is centralized in script.c, so from outside all you see is run_script(s_update_script, false);, which makes the intent much clearer and cuts down on the boilerplate.

The part that surprised me was that basically all error messages are not just hard coded that way, they are almost all written inline. TurboSphere is similar in some places, but the basic stuff like argument parsing, number of args, and argument unwrapping/wrapping has system-wide error messages. Similarly, I use a library that is shared between all my plugins to perform script compilation, and it sets the error on the context internally (and can be flagged not to, in case we want to tolerate errors).

Is there someone who has compiled 1.6 and has it stable? Is there a place I can read up on compiling in Linux? (seems like the wiki is gone?)

Stable is relative

The code on the github repo https://gihub.com/Sphere-Group/Sphere should work. You will need a slightly doctored version of Corona (either mine, at https://gihub.com/FlyingJester/Corona or Chad Austins at https://gihub.com/ChadAustin/Corona), and Audiere https://gihub.com/ChadAustin/Audiere. Obviously you will need SM 1.8.5, which OpenSuse still hosts RPMs of. Otherwise, it still compiles pretty easily.

There is no sound with Audiere anymore, since OSS doesn't really exist on Linux anymore. But other than that it works fine.

There is no sound with Audiere anymore, since OSS doesn't really exist on Linux anymore. But other than that it works fine.

What about padsp?

Ok, so what I understand: engine is not functional, it needs replacement of:

• SpiderMonkey, which has new API calls https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Releases
  


• Audiere to OpenAL (Due to no support for OSS) I guess: http://repo.or.cz/w/openal-soft.git


• Corona to support current libpng https://github.com/FlyingJester/corona

The link to SpiderMonkey 31 shows what functions to replace with which, and the current unstable is 38.

That is a huge effort. For now, not too enticing (as we also need to test on Linux, Mac and Windows).

My perspective: I have limited time. I want to start again on the RPG I was making, and get Sphere running on an OpenPandora Handheld. I want to make some testcases to make sure quality is ok (all Sphere forks can benefit of that). My C/C++ is rusty, as is my Javascript.
Several ppl have pointed me to MiniSphere, so I think that is the way to go (I'll miss those particle effects, but most of my gamelibs are vanilla Sphere1.5, so no biggie). And sfxr's can be made online http://www.bfxr.net/ now ... although it was nice for pseudo random sounds.

And of course, I'm curious too to see if SpiderMonkey (JaegerMonky).... whatever... EcmaScript... can work again. But I'd rather help on Sphere-sfml (browser Sphere... huge user base!).


For now I have: migrated from Debian 7 to 8 (2Gb of downloads, at least 3 reboots, and a whole lot of reconfigurations later, I meet the requirements to compile MS). Not sure what I miss, as I still have this error:

fbnil@tortuga:~/JUMP/minisphere/minisphere$ gcc -o obj/animation.o -c obj/animation.c
In file included from /usr/include/allegro5/internal/alconfig.h:57:0,
                 from /usr/include/allegro5/base.h:50,
                 from /usr/include/allegro5/allegro.h:26,
                 from obj/minisphere.h:23,
                 from obj/animation.c:1:
/usr/include/allegro5/platform/alucfg.h:53:2: error: #error Unix Allegro now REQUIRES pthreads
#error Unix Allegro now REQUIRES pthreads
  ^

Allegro "make" only plays nice if I disable FFMPEG and CG

Allegro for Debian: https://wiki.allegro.cc/index.php?title=Install_Allegro5_From_Git/Linux/Debian

Please note you need to also enable HEAD:

Code: [Select]

git clone git://git.code.sf.net/p/alleg/allegro
cd allegro
git checkout 5.1.3

Brush up your C++:  http://www.entish.org/realquickcpp/realquickcpp.html

I'd like to implement a particle engine in minisphere at some point, so you might not have to go without it for too long.

Allegro sans ffmpeg is fine, I don't use the video component at all.  You do need libmng to build the engine though.  And Allegro 5.1.10 (5.1.3 you have there is too old to support shaders I think, which minisphere requires).

As for that error, it says it right there, you need pthreads.  Presumably you don't have a dev package installed for that...?

Also minisphere is written in pure C, not c++.

Thanks a lot! I had to go to 5.1.10, recompile allegro, and scons now continues.

galileo.c:(.text+0x70a): undefined reference to `al_destroy_vertex_buffer'

Strange, because I do have...
/usr/include/allegro5/allegro_primitives.h:ALLEGRO_PRIM_FUNC(void, al_destroy_vertex_buffer, (ALLEGRO_VERTEX_BUFFER* buffer));
Had to clear out manually the old allegro .so files... although they seem to coexist happily... probably still an old header files somewhere... hunt continues tomorrow...


About the OSS wrapper : I remember using that some years ago, it made the game sound a bit stuttery. not unbearable. I guess now with faster computers it should not matter all that much.