Yeah, you need Allegro 5.1 "unstable" (i.e. the API is unstable, it's actually quite reliable).  Not sure if that's available through homebrew; you may need to build Allegro yourself:
http://github.com/liballeg/allegro5

Thanks, managed to build Allegro. Now having a problem with libmng - I can't get that to build on OS X at all. I have no plans to actually use MNG, is there any chance you could add an option to compile without MNG support?

You're the second person to request that, I'll see what I can do.  For now you can probably disable it by:
* Remove 'animation.c' from msphere_sources in the SConscript
* Remove 'mng' from msphere_libs in the SConscript
* Comment out the call to init_animation_api() in api.c

There's been talk of Allegro adding optional MNG support to the library; if that happens I can do away with my own libmng dependency.  Oh, that reminds me, watch out with Allegro's audio support; if you didn't set WANT_ACODEC_DYNAMIC_LOAD=0 when using Allegro's CMake, then it attempts to dynamically load libvorbis, etc. at runtime and fails silently if it can't, so if minisphere fails to load any sound files--it's most likely not my fault!

By the way, casiotone: I just found out you didn't have to compile Allegro from source after all.  5.1.12 was available on homebrew after all, the command is:
brew install --devel allegro

@NEO: You might want to take note of the above as well.

By the way, casiotone: I just found out you didn't have to compile Allegro from source after all.  5.1.12 was available on homebrew after all, the command is:
brew install --devel allegro

@NEO: You might want to take note of the above as well.

Two errors:

Code: [Select]

airlux:magento lux$ brew install --devel allegro
Error: You must `brew link libogg libvorbis cmake freetype flac' before allegro can be installed

...then...

Code: [Select]

airlux:magento lux$ brew link libogg libvorbis cmake freetype flac
Linking /usr/local/Cellar/libogg/1.3.2... 
Error: Could not symlink lib/libogg.0.dylib
Target /usr/local/lib/libogg.0.dylib
already exists. You may want to remove it:
  rm '/usr/local/lib/libogg.0.dylib'

To force the link and overwrite all conflicting files:
  brew link --overwrite libogg

To list all files that would be deleted:
  brew link --overwrite --dry-run libogg

Give me a bit of time to eventually focus on doing this and I'll let y'all know results.

You're the second person to request that, I'll see what I can do.  For now you can probably disable it by:
* Remove 'animation.c' from msphere_sources in the SConscript
* Remove 'mng' from msphere_libs in the SConscript
* Comment out the call to init_animation_api() in api.c

There's been talk of Allegro adding optional MNG support to the library; if that happens I can do away with my own libmng dependency.  Oh, that reminds me, watch out with Allegro's audio support; if you didn't set WANT_ACODEC_DYNAMIC_LOAD=0 when using Allegro's CMake, then it attempts to dynamically load libvorbis, etc. at runtime and fails silently if it can't, so if minisphere fails to load any sound files--it's most likely not my fault!

Works like a charm, thanks again.

minisphere 2.1.5 fixes corruption at the end of a WAV stream (note: this was an Allegro bug) and adds an option to the GDK plugin to Test Game in windowed mode.  The default is still fullscreen, of course.

So I've been thinking on and off about the direction I want to go with in minisphere 3.0, but I've been wracking my brain because pretty much all of what I set out to implement has been implemented as of minisphere 2.1.  I haven't even been able to muster a clear plan for a v2.2 (which will likely end up just being some Cell enhancements), let alone a major upgrade.  Which really only leaves one more hurdle: plugins.  The engine already has most of the framework in place for this (the extension system), most of the work would be coming up with an API.

http://www.drdobbs.com/cpp/building-your-own-plugin-framework-part/204202899

I like DrDobbs magazine for the conceptual things it contains. Just relax, sit down in non-programming mode, and read it. Around page 3/4 it goes into code... maybe it gives you an idea on how to start the API.

Hey, so this is just my selfishness speaking, but how feasible would a software renderer mode be? I'm developing something while temporarily on quite a crappy computer (Supports up to OpenGL 1.3...) so I obviously stumbled against the issue of not being able to run minisphere.

Hm, in theory it's possible to initialize Allegro in D3D mode, which would raise compatibility.  The downside is that shader support would be disabled, but it would allow the rest of the functionality (including base Galileo) to work.  I'll see about making that change in minisphere 2.2.

I've read that Dr Dobb's article, and I'm not really a fan of how they do it.

I did about the simplest thing in TurboSphere. The API looked like this:

Code: (C) [Select]

const char *Init(JSContext *ctx); // Returns the plugin name.

int GetNumFunctions(JSContext *ctx);
const char *GetFunctionName(JSContext *ctx, int i);
JSNative GetFunction(JSContext *ctx, int i);

int GetNumVariables(JSContext *ctx);
const char *GetVariableName(JSContext *ctx, int i);
void GetVariable(JSContext *ctx, int i, JSMutableHandle out); // It's much better to use an out-parameter for handles with SpiderMonkey.

void Close(); // Closes the plugin.

I'm still using a variant on that in UltraSphere/Turbo. I guess why complicate things, I never found I needed anything more than this. With how minisphere handles extensions, you could also add a GetExtension/GetNumExtensions component.

That's just my two cents from my own experiments.

I've read that Dr Dobb's article, and I'm not really a fan of how they do it.

I have to agree.  I looked over it and the very OO method they provided just seemed overcomplicated for most purposes.  That said, I did use a similar setup when I overhauled Sphere Studio's plugin API, but at least there it's justified since 1) There are a bunch of different plugin roles (debugger, editor, engine runner, and so on) but I needed to be able to have one plugin implement multiple roles while still having a unified interface, and 2) It's C#, so I don't have to worry about name mangling differences, etc. like I would with C++.

minisphere now runs on my ancient OpenGL 1.3-only system. Thanks a lot for the support, Lord English.

Having just started work on minisphere 3.0, a question occurs to me: Would anyone be opposed if, for the 3.0 Windows release, I provided only a 64-bit build?  The x86 build seems pretty redundant nowadays, I personally haven't encountered a 32-bit version of Windows in years.