Where's the FFV engine?  I couldn't find it in the Downloads drive.

This just reminds me I have SO many more Sphere games to upload. I think I'll just dump them all in there somewhere later.

MIDI support is possible, would be a bit more work than the formats currently supported because for those I can just tell Allegro to load the file.  Here I would have to decode the file myself.  Now that all the mp3 patents have expired and the format is public domain, it might be a good time to look into implementing that too (although the lack of non-[L]GPL decoders may get in the way of that).

MP3 support is a good idea, especially for compatibility reasons. As for MIDI, I was just entertaining the thought of it (also for compatibility reasons like some of Radnen and FJ's old games), but frankly it could be a very intruiging addition when music could literally be the MIDI files and an accompanying soundfont to make it all unique for a specific game and stuff. I dunno. But like you said, it'd take more to implement it.

Edit: by the way, a LOT of old Sphere games didn't *quite* seem to want to work under MiniSphere. I'll definitely upload the whole batch of them later so you can really see what's going on and where.

FFV engine uploaded: https://drive.google.com/file/d/0Bw-4UFVty4u1T1pvRlRpbHVocGM/view?usp=sharing

Got a bug that is regularly acting up: some games crash with:

Code: [Select]

minisphere: /build/allegro5-3qTrvn/allegro5-5.2.2/addons/memfile/memfile.c:175: al_open_memfile: Assertion `size > 0' failed.

For example, this game (but also a bunch of others): http://vincent.tengudev.com/temp/MoonBlade.zip

Thanks, I'll look into it once I get off work.  I'm in full-throttle development mode today

I was curious about the error DaVince pointed out.

I worked my way through the JS to try and find the trigger(s):

The cause of the hard crash was apparently using OpenFile with a file name ending in ".lng" - removing the ".lng" from the document name and at the same time removing it from the function call resulted in the crash no longer occurring.

However there was another crash - in the start of the game function there is the following:

Code: [Select]

for (var i = 0; i < game.arguments.length; i++)
{
    if (game.arguments[i] == "-d") debug = true;
}

In minisphere game.arguments is not defined and hence this causes a JS error (not a miniSphere hard crash though)

after commenting out this and changing the name above the game starts without crashing but it doesn't seem to do anything - it loads a screen with some moving clouds but doesn't then seem to take any input - not sure if this is intentional or another incompatibility I haven't found.

Edit: I've also spent a little time looking at miniSphere source to try and work out why the hard crash above occurs, I can't work it out for sure, as I don't quite follow the logic (my C skills are rather limited) but it looks to me like the function kev_open line 16 and on of Kevfile.c defines a variable slurp_size but never gives it a value - this variable is then supplied to al_open_memfile as a parameter if a certain condition is met - I cannot work out the logic of the condition - but at a guess it's if sfs_fslurp line 462 of spherefs.c fails to read the file, I can't see what the ".lng" extension has to do with this but; hopefully that's a useful start.

EDIT 2: I was wrong with the ".lng" extension point - the issue was not that at all; instead the issue was that the file was 0 bytes - changing the name somehow made it 1 byte instead of 0; the issue is also fixed if you open the file with a text editor and add some content of any kind to it.

after commenting out this and changing the name above the game starts without crashing but it doesn't seem to do anything - it loads a screen with some moving clouds but doesn't then seem to take any input - not sure if this is intentional or another incompatibility I haven't found.

This is intentional - it's an old project that only takes some debug input (keys 1, 2 and 3).

The crash seems to be caused by Allegro not wanting to open a zero-byte buffer as a memfile.  That seems like a bug to me--I'll report it.

@Rhuan If you're talking about this check:
https://github.com/fatcerberus/minisphere/blob/master/src/minisphere/kevfile.c#L25

That code is fine.  sfs_fslurp() reads an entire file in one go and returns a pointer to the first byte.  If the function succeeds, then the pointer returned is non-null and is therefore truthy, so we enter the if-clause and continue as normal (if it returns a null pointer indicating failure, the else-clause is entered instead, which is an error path).  Note that a pointer to slurp_size is passed to the slurp function--that gets set to the size of the file.  Thus slurp_size is set correctly by the time it's actually needed.  The problem here actually has to do with when slurp_size is zero--because the file was totally empty--then al_open_memfile() doesn't cooperate and crashes.

edit: For whatever reason I don't get the crashes on Windows.  It seems like maybe the Linux binaries for Allegro were compiled with assertions enabled for who knows what reason (this was stupid, since it hurts performance).  So I guess it's just the assertion failing and Allegro can actually open zero-size memfiles just fine.  MoonBlade runs without error for me on Win10 at least.

The problem here actually has to do with when slurp_size is zero--because the file was totally empty--then al_open_memfile() doesn't cooperate and crashes.

edit: For whatever reason I don't get the crashes on Windows.  It seems like maybe the Linux binaries for Allegro were compiled with assertions enabled for who knows what reason (this was stupid, since it hurts performance).  So I guess it's just the assertion failing and Allegro can actually open zero-size memfiles just fine.  MoonBlade runs without error for me on Win10 at least.

I picked up what the issue actually was in my second look at it - see the edit2 to my post above - the stuff about slurp_size not being set was my incorrect first guess.

Seems I have asserts enabled in my Mac build too - not actually sure how to disable them - I'll look into that next time I build it.

The problem here actually has to do with when slurp_size is zero--because the file was totally empty--then al_open_memfile() doesn't cooperate and crashes.

This is largely the same as how memory mapping files directly with OS APIs works. A zero-length file is not obvious from a file that doesn't yet exist if you try to memory map a file without checking if it exists first.

Does miniSphere support gif files? I just found a Sphere game that uses some gif files (namely, the Sully demo) and miniSphere refuses to load it ("Error: cannot load image").

Edit: also, I'm not sure if sound.setPosition() actually works. I have a little test game that will set the playback position to the playback position + 20 if a key is held. In the original engine, this would speed up the music, but in miniSphere it just adds a little bit of noise to the sound and nothing else happens. (This is the case for both ogg and it files.) See attached file.

Does miniSphere support gif files? I just found a Sphere game that uses some gif files (namely, the Sully demo) and miniSphere refuses to load it ("Error: cannot load image").

Odd, Sully worked fine for me last time I tested it.  That was one of the games I fixed back in the day because it had map layering bugs.  So if gifs are broken, that's a regression.  But I can't see why that would have happened, unless the file is corrupt...

Edit: also, I'm not sure if sound.setPosition() actually works. I have a little test game that will set the playback position to the playback position + 20 if a key is held. In the original engine, this would speed up the music, but in miniSphere it just adds a little bit of noise to the sound and nothing else happens. (This is the case for both ogg and it files.) See attached file.

setPosition() in miniSphere is in microseconds:
https://github.com/fatcerberus/minisphere/blob/master/src/minisphere/vanilla.c#L4115

Adding +20μs to the position of course isn't going to move the playback position much (in fact it may not move at all, if it's less than the seek threshold the underlying decoder supports).  Sphere 1.x by contrast, uses some unknown unit for seeking that I never bothered trying to decipher.  It's a larger unit than microseconds, but smaller than milliseconds.  And it's not counting samples either.  So I was never able to emulate it fully.

I've verified that the reason the FFV engine crashes is due to a behavior discrepancy in Surface#applyColorFX4 compared to Sphere 1.x.  In 1.x, the coordinates you pass in are clamped to the size of the surface, and the matrices are interpolated using the unclamped values.  I just throw an error instead.  So that will need to be changed.

I haven't gotten around to testing any other old games yet, but I'd like to test at least some of them before releasing 4.6 so I can boast of greatly increased backward compatibility in the new release.

Odd, Sully worked fine for me last time I tested it.  That was one of the games I fixed back in the day because it had map layering bugs.  So if gifs are broken, that's a regression.  But I can't see why that would have happened, unless the file is corrupt...

Just noticed - Sully works fine here too. I once tried to modify the game so it shows the intro and stuff, and it has to load different files for that, and that is what is failing. To be exact, it fails trying to show images/intro/retro.gif - a file that wasn't used in the original Sully Sphere demo.
This modified version of Sully can be found in that giant 1GB download with all the games I have, by the way. (Under games/DaVince to be exact.)

As for the microseconds thing, that makes sense! It feels a little silly to have to input a value of 10000+ before a noticeable change happens in the music, but it works.

Yeah, that's why Sphere v2 uses floating point (in seconds) for the position.  That way you control the granularity, not the engine.