Allegro has a lot of stuff built in that I would likely have to implement myself or go looking for third-party add-on libraries to do in SDL, and it's ridiculously simple to compile static (the official Windows releases are statically linked to Allegro).  Also, SDL as far as I know is LGPL, making static linking more of an iffy proposition due to minisphere's BSD license.  Allegro is zlib licensed.  Oh, and I like the Allegro API, very C-like.

Allegro can be compiled on Android, and actually I wanted to do an Android build of the engine at some point in the future, but getting the build environment set up seemed like a daunting task, so I keep putting it on the back burner.  Feel free to try it yourself and let me know the results!

If that's the case, it might be easier to just use SDL or something. I'll look into working with one of the other cross-platform engines, or just making my own and using some code from them as reference. But I'm already working on a non-Sphere related project, so that may or may not happen. (shameless plug)
Heck, since it's developed by Google anyway, can is compatible with Linux, OS X, Windows, Android, and iOS and it can link other non-Go libraries like SDL and GTK, I wonder how feasable a Sphere engine written in Go would be...

Do keep in mind that when I said it seemed daunting, I was developing exclusively on Windows at the time--a platform which is not really well-suited to cross-platform development.   Now that i have access to Linux, I might try it again at some point in the future.

That's fine. I haven't used it a whole lot since building it a few days ago in Linux, but it seems to run pretty well. This was more of a random idea, since Radnen suggested I look into porting JavaSphere to Android.

minisphere has a man page now!

Allegro has a lot of stuff built in that I would likely have to implement myself or go looking for third-party add-on libraries to do in SDL, and it's ridiculously simple to compile static (the official Windows releases are statically linked to Allegro).  Also, SDL as far as I know is LGPL, making static linking more of an iffy proposition due to minisphere's BSD license.  Allegro is zlib licensed.  Oh, and I like the Allegro API, very C-like.

SDL2 is zlib licensed.

SDL2 is also extremely similar to SDL1 in an API sense (to the point that a few very common functions now have dummy arguments to match the API of their SDL1 counterparts). I personally prefer SDL2's API, and if you were going to call it from Java I think it would be a much better choice since its API is very well suited to being used from an object-oriented environment. SDL2 also has full support for Android, and has a variety of features to either query the actual touch system or to just emulate a keyboard and mouse with it.

If cross-platfom is a goal, SDL1 and even SDL2 utterly annihilate Allegro, though

Not sure about Allegro 4, but v5 supports Android back to API level 12, iOS, and of course the big three (Windows, OSX, Linux).  Possibly BSD as well, not sure about that though.  Allegro 4 is very much a legacy platform (being designed originally for MS-DOS games and ported elsewhere over the years), v5 was rewritten from the ground up but it gets a bad rap because people assume it's just an incremental evolution of the classic Allegro.

SDL probably does support more platforms, but for something like Sphere, the 5 listed above should cover the majority of users.  Honestly though most of why minisphere is still using Allegro is inertia - it was the first thing I tried after SFML, and had everything I needed--and still does--and now that I have the whole Sphere API built on top of it (note: the Allegro 5 API is VERY similar in structure to Sphere 1.x) it would be a massive undertaking to port it to a new backend.

Speaking of porting, I backported minisphere to be able to compile against Allegro 5.0, which is what's pulled by default via apt-get and homebrew since 5.1 is "unstable".  This should make it easier for people to compile the engine now.

minisphere has a man page now!

Nice! So is this something that will be installed by make install?

Allegro 4 is very much a legacy platform (being designed originally for MS-DOS games and ported elsewhere over the years),

Wow, I knew Allegro was around during the DOS days, but I didn't know that Allegro 4 was that old.

minisphere has a man page now!

Nice! So is this something that will be installed by make install?

Yes.  There are also man pages for Cell and SSJ, but they are currently incomplete.

Allegro 5 sort of supports FreeBSD (no sound), and doesn't support OpenBSD at all. They say they do, but the OpenBSD people say they don't (and Allegro doesn't compile in OpenBSD 5.7+, I know from experience). Either way, they don't support the OpenBSD audio system for sure.

The other targets that are important to me are Solaris (particularly on UltraSparc) and Haiku. SDL2 supports both, although their raw Surface video backend is pretty bugged on Haiku (the Render backend and OpenGL support has no issues, though). It also has audio on BSDs. But I don't use SDL2 for audio anyway, I usually use OpenAL or OpenBSD's native sndio when on OpenBSD or Linux (which is easily the best audio backend I've found so far).

You're right, though, these are pretty obscure targets. Allegro could probably be made to support FreeBSD with PulseAudio enabled, but the BSD people hate the PulseAudio people and the PulseAudio people hate the BSD people, so I don't suspect that's a good long term plan.

So I finally got Travis to actually use clang to build minisphere (turns out SCons doesn't honor the pre-existing environment, it was simple now that I have a makefile), and said compiler now seems to hate me, mostly because I like to do this:

Code: (c) [Select]

if (thing = create_foobar(...)) {
    ...
}

It's just so succinct and elegant that I got into the habit of doing it everywhere.  I can easily shut up the warnings of course, by adding another set of parentheses, but that triggers my OCD and makes the statement look uglier.

I should try adding -Wall -pedantic to that command line and see if I can get clang even angrier at me.

Anyway, I think I'm getting close to releasing the first 3.0 beta, but I have to get SSJ to be able to locate source code properly first, and also implement breakpoints.  It's kind of useless without those.

I think minisphere on Windows XP is a lost cause.  I set up Windows XP x64 edition in a VirtualBox VM yesterday and tried to get minisphere going on it, but failed miserably.  I think it might just be that the MSVC 2015 C runtime doesn't like XP - everything was fine until something tried to access the file system.  Cell will report that there's no cellscript in the current directory, minisphere errors out if a game is passed on the command line, the "select a game" dialog doesn't show up at all, etc.

So yeah, I'm just going to cross XP off the list of supported platforms.  Anyone know if minisphere runs on Vista or should I just say the minimum requirement is Win7 and call it a day?

In any case, I decided not to drop the 32-bit builds after all.  There are still quite a few 32-bit Windows installs in the wild, particularly netbooks tend to be preinstalled with a 32-bit OS to counterbalance the low RAM.  Since both the 32- and 64-bit binaries are built from the same source, it's not a big deal to maintain two sets of binaries.  Speaking of which, starting with minisphere 3.0 the entire toolchain will be built for 64-bit.  In minisphere 2.x, Cell was 32-bit even in a 64-bit minisphere installation.

XP is more than 15 years old. If someone is disappointed with Minisphere not supporting it, I would be more disappointed they are still using XP.
Literally even Wine is better supported, more compatible, more stable, and more secure at this point.

So I finally got Travis to actually use clang to build minisphere (turns out SCons doesn't honor the pre-existing environment, it was simple now that I have a makefile)

It's easy once you know how, but I agree that SCons should really accept hints from $CC, $CXX, etc. When I started fiddling with Emscripten I had to learn how to accept environment settings, but it really should be the default to do so.

Code: (c) [Select]

if (thing = create_foobar(...)) {
    ...
}

It's just so succinct and elegant that I got into the habit of doing it everywhere.  I can easily shut up the warnings of course, by adding another set of parentheses, but that triggers my OCD and makes the statement look uglier.

I sort of understand why they do this. It's because using both equality and assignment has screwy precedence order...

Code: [Select]

int x = 1;
if(x=0 == 1)
    causeNuclearWar();
else
    puppiesForEveryone();
// I hope that turned out OK!

It also is intended to show you that in such cases variable decaration will not be hoisted to the next block. But I wish they would just leave these warnings on conditionals with both assignment and equality.

Hey, could someone with a 64-bit installation of Debian or Ubuntu test out this .deb package for me?
https://drive.google.com/open?id=0BxPKLRqQOUSNVmR3SFU0QXB6ZUE

I'll be providing .deb's and tarballs for minisphere 3.0, so I figured I'd make sure everything is in order now.

I suppose the Allegro 5.1 PPA is mandatory for this one, since it gave me "Dependency not satisfiable: liballegro-acodec5.1" in Ubuntu's package manager.

Installed fine after adding that. The minisphere desktop entry also appeared in my Xfce menu. It opened the standard "open file" dialog; can't help but feel that showing the launcher game with sample games would be better though. (Maybe with a simple game that explains/demonstrates what this whole thing is? That could be a future step, I suppose... )