...wow.  Just all I will say is "wow".  Still haven't found the cause of the animation bug, but I did find this:

Code: (c++) [Select]

for (unsigned int i = 0; i < m_Directions.size(); i++)
  if (strcmp_ci(direction.c_str(), m_Directions[i].name.c_str()) == 0)
  {
    d = i;

    // stop immediately.
    i = m_Directions.size();  // <-- wtf
  }

Traditionally most people early-terminate a for loop using a break statement...

Edit: Here are the results of my tests: COMMAND_ANIMATE seems to work fine.  Your Blockman sprite has a delay of 4 on each frame, so I did the following:

Code: (c++) [Select]

SetPersonSpriteset('robert', LoadSpriteset('blockman.rss'));
for (i = 0; i < 5; i++) for (j = 0; j < 4; ++j) {
	Console.writeLine("Frame: " + GetPersonFrame('robert'));
	Console.append("i = " + i);
	Console.append("j = " + j);
	FlipScreen();
	QueuePersonCommand('robert', COMMAND_ANIMATE, false);
	UpdateMapEngine();
}

It correctly cycled through all the frames (originally there was some log output here but it was a waste of space).  Sphere 1.5 was somewhat odd as it stayed on frame 0 twice as long the first time around (8 frames instead of 4), but otherwise cycled through all 5 images as normal.

Are you sure your issue wasn't with SetPersonFrame() and not COMMAND_ANIMATE?  Because that was the only difference I could find between 1.6 and minisphere, minisphere's SetPersonFrame wasn't resetting the animation frame counter.

Edit 2: Yeah, it was SetPersonFrame.  Sphere 1.5:

Code: (c++) [Select]

m_Persons[person].frame = frame;

Sphere 1.6:

Code: (c++) [Select]

m_Persons[person].frame = frame;
m_Persons[person].stepping_frame_revert_count = 0;
m_Persons[person].next_frame_switch = p.spriteset->GetSpriteset().GetFrameDelay(p.direction, p.frame);

1.6 resets the frame counter when the frame is set explicitly, 1.5 doesn't.  minisphere follows the 1.6 implementation now.

I just made my first x64 build of minisphere, and it's working great!  There's a good number of warnings due to conversions between int and size_t but other than that no issues that I've noticed so far.  Note that Allegro and every one of its dependencies generated similar warnings; whoever had the bright idea that both int and long should be 32-bit in 64-bit MSVC needs to be shot.

The best part?  The 64-bit build actually seems faster, especially noticeable with games that load a lot of resources upfront.

minisphere 1.0.10 is out.  I'm including the 64-bit build as an experimental surprise addition to 1.0.10 so that it can get some real-world testing before it's officially unveiled in minisphere 1.1.   Aside from that, this is basically a huge bugfix release to hopefully stabilize the 1.0 engine for real-world use.

So I had my first foray into 64-bit debugging in MSVC.  It was a simple 10-second fix for a null dereference, but boy was the exception dialog (shown below) disorienting.  I've been debugging 32-bit C/C++ apps for years, so I'm used to seeing this dialog, but all the extra digits in the memory addresses... wow.  It took me a good 20 seconds I think to recover from the shock, it was dizzying.

Anyone have any suggestions for what they want to see in minisphere 1.1?  Almost my entire v1.1 checklist has been checked off except for implementing config.exe, so I figure I should solicit feature requests now.

How do we check if we are running a game in minisphere? GetVersion() and GetVersionString() might have to take a parameter... not sure what though, here's the deal:

1. You can't overwrite the functionality of these functions because games check against them for compatibility, so they should return the API complacency. (v1.5 for the string and 1.5 for the number).
2. You can't pass 'true' to them to get minisphere's version since in SSFML, I could also return it's unique version too.
3. You pass a string, 'minisphere', to get minisphere's version. It returns nothing if you don't use minisphere. Trouble is, Sphere 1.5 will still return it's version number.

So... I guess the only way to detect sphere version is by feature detection. Namely we can use the features/apis function... whatever it was named.

Check whether GetExtensions exists.  If it doesn't, that's stock Sphere.  If it does, call it and check if 'minisphere' is included in the extensions list.  That's why I added that function, and why I also added it to SSFML recently as well.

That said, do note that GetVersionString() in minisphere returns a string like this:

Code: [Select]

v1.5 (compatible; minisphere 1.0.10)

I've been doing that since minisphere's inception and haven't had a game break because of it yet.

Just implemented a bunch of new APIs for follower management for 1.1.  FollowPerson was one of those dark corners of the Sphere map engine that really needed some love; heck, the only way to get a person's leader was through engine-provided metadata returned by GetPersonData, and the rest of the info was just unavailable.  minisphere 1.1 will add the following APIs:

• GetPersonLeader


• GetPersonFollowers


• GetPersonFollowDistance


• SetPersonFollowDistance

I have to thank DaVince for pointing out deficiencies in the Sphere implementation, or it never would have received these enhancements.  You can now write a handler, for instance, that condenses follower chains when a person in the middle of the chain is destroyed:

Code: (javascript) [Select]

SetDefaultPersonScript(SCRIPT_ON_DESTROY, function() {
	var person = GetCurrentPerson();
	var distance = GetPersonLeader(person) != "" ? GetPersonFollowDistance(person) : 0;
	Link(GetPersonFollowers(person)).each(function(name) {
		FollowPerson(name, GetPersonLeader(person), distance);
	});
});

That said, do note that GetVersionString() in minisphere returns a string like this:

Code: [Select]

v1.5 (compatible; minisphere 1.0.10)

I've been doing that since minisphere's inception and haven't had a game break because of it yet.

I guess my fear there is someone is checking against the string. So far there hasn't been an issue tho. Yes, GetExtensions was what I was thinking about, I guess it's the only reliable solution.

Yeah, I would have changed the string back by now if there were a compatibility issue.  From what I've observed, games that want to detect version level use GetVersion() instead, which returns 1.5 as always.  Which makes sense, since then you can use comparison operators on it:

Code: [Select]

if (GetVersion() < 1.5) {
  Abort("Unsupported engine version!");
}

That said, do note that GetVersionString() in minisphere returns a string like this:

Code: [Select]

v1.5 (compatible; minisphere 1.0.10)

I've been doing that since minisphere's inception and haven't had a game break because of it yet.

I guess my fear there is someone is checking against the string. So far there hasn't been an issue tho. Yes, GetExtensions was what I was thinking about, I guess it's the only reliable solution.

Even if there is, it's their problem to solve. They wrote the game for Sphere 1.5, and it's pretty obvious that not every single stock 1.5 game works out of the box with minisphere (for example, any using the const keyword, or any using MP3 files).

Even if there is, it's their problem to solve. They wrote the game for Sphere 1.5, and it's pretty obvious that not every single stock 1.5 game works out of the box with minisphere (for example, any using the const keyword, or any using MP3 files).

Yeah, I guess you're right. New games shouldn't have that problem. I already modified Blockman to run in minisphere, I guess old games are just stuck with old engines.

I suggest adding SetTileName(). I added that to my map engine just because I thought it was odd it was missing, and it was trivial to add.

Yeah, that would be trivial to add.  Is there a valid use case for it though?  I try not to add APIs just for the sake of it, trying to minimize perceived bloat.

I'm not sure it has a proper need, but every other method that has a Get also has a Set. I added it just for consistency.