I found that the color constructor adds noticeable overhead in TS, too. My main advice is just to not create colors on the fly as much as possible.

For good measure, the third screenshot shows the main culprit in the text rendering bottleneck: al_hold_bitmap_drawing(false);  This should be ridiculously fast, as fonts are atlased so Allegro can just send all the vertices at once.  But apparently not...

I'd be curious how the Turbo runtime's font renderer runs in Minisphere.

I still can't get minisphere to load the Turbo runtime successfully due to all the circular RequireScripts.  How do you have RequireScript implemented in TS?  I evaluate the script AFTER entering it into the tracking list, to avoid infinite circular recursion.  So what ends up happening for me is that, after requiring map_engine.js, at some point in the require chain it gets to segment.js and Turbo is undefined because it's still in the middle of resolving the RequireScript chain.

https://github.com/FlyingJester/TurboSphere/blob/master/src/configmanager/openscript.cpp#L68-L104

...Which leads to large stacks at certain points...

That's very strange. In TurboSphere, RequireScript enters a script into the list of evaluated scripts immediately after it checks if it was previously evaluated, which is right before it evaluates the next script.

But every one of the runtime's scripts should have the declaration of the Turbo object before anything that uses it--you should be able to require any one of them, and in any order, and not have that issue. It seems odd to me that Minisphere would complain about Turbo being undefined, unless the RequireScripts are not sharing all declarations until after they have completed or something similar. Or somehow our implementations are really that different? I think we do it the same way, and I can't really think of another way that would even come close to working properly.

https://github.com/fatcerberus/minisphere/blob/master/src/api.c#L496-L521

Looks like the same basic logic to me.  Weird.

I know I had this same problem with miniRT, and I was only able to fix it by centralizing everything to a single script (miniRT.js) which pulls in all the others at the bottom (not the top).  And when I mentally followed the call chain, it made sense--if the RequireScripts are at the top and there's a circular reference, then when you hit the effective "bottom" of the tree (conceptually there is no bottom since it's a circle but in reality there is because of the implicit include guard), Turbo is undefined because all the scripts higher up in the call chain are still in the middle of include resolution, so nobody's actually had a chance to define it yet.

So yeah, not sure why this works in one engine but not the other.

Edit: Shame on you for calling malloc and not checking for null!   Actually though, I've stopped checking it myself.  I figure by the time a malloc returns null there's not much I can do in the way of recovery anyway so may as well just let it crash.

Edit: Shame on you for calling malloc and not checking for null!   Actually though, I've stopped checking it myself.  I figure by the time a malloc returns null there's not much I can do in the way of recovery anyway so may as well just let it crash.

Yeah, in general there's just no point. In very almost all cases, an OOM is unrecoverable from any perspective. I could fail fast, but if I suspect an OOM I can use a debug malloc that aborts when it would return null.

New version up, with a few map engine fixes.

edit: Awesome, 1111 posts!

edit: Awesome, 1111 posts!

Don't you mean, 15?

Why 15?

Tip of the day: Use RNG.name() if you need a unique internal name for something.  The function returns a random string of alphabetic characters, similar to the format of a YouTube video hash:

Code: [Select]

IlysMylJv

The function takes an optional integer parameter specifying the length of the string to generate, up to 255 characters.  If called with no parameter, a default length of 10 is used.

https://github.com/fatcerberus/minisphere/commit/313d3dd455d632eb550de578233986c2a45fc5ad

That is all.

1111 is 15 in binary.

And you have some funny comments in your code.

Hey, if I have to document the code I might as well have some fun with it, right?   You'll find I also tend to write funnier comments when I'm frustrated, like the "HERE BE DRAGONS" ones I have at the top of a few particularly hairy functions.  Then you have my personal favorite minisphere comment of all time, in persons.c:

Code: (c) [Select]

	// check that the person didn't mysteriously disappear...
	if (!does_person_exist(person))
		return;  // they probably got eaten by a hunger-pig or something.

And of course, this one's a classic too:

Code: (c) [Select]

	// check for obstructing persons
	if (!person->ignore_all_persons) {
		for (i = 0; i < s_num_persons; ++i) {
			if (s_persons[i] == person)  // these persons aren't going to obstruct themselves!
				continue;
			if (s_persons[i]->layer != layer) continue;  // ignore persons not on the same layer
			if (is_person_following(s_persons[i], person)) continue;  // ignore own followers
			if (is_person_ignored(person, s_persons[i])) continue;
			base = get_person_base(s_persons[i]);
			if (do_rects_intersect(my_base, base)) {
				is_obstructed = true;
				if (out_obstructing_person) *out_obstructing_person = s_persons[i];
				break;
			}
		}
	}

minisphere 1.4 is up!  I fast-tracked this one since I didn't really have any other ideas for a release, but the CS support is enough of a change to warrant a version bump, methinks.

To be clear: You can now specify .coffee files directly in a RequireScript() call, and require() will recognize .coffee modules as well.  No need to include the CS compiler with your game and manually invoke it, minisphere will load and use it from the system directory automatically.

The funny thing is I don't even really like CoffeeScript that much...

edit: I also recompiled everything with /O2.  It seems I sacrificed a lot of performance when I optimized for size a while back, not really worth it to reduce the engine size by half a MB.

Good or bad? Many opinions:
http://code.tutsplus.com/articles/should-you-learn-coffeescript--net-23206

And dipping your toes into CS:
http://blog.teamtreehouse.com/the-absolute-beginners-guide-to-coffeescript

Syntactically, coffescript is nice to have for a few areas: Classes, loops, and some areas of logic that may get too verbose. But I've found that libraries like my Link.js go a long ways in making sure iterations on lists and management of larger code sections is easier to maintain.

There's a point in professional JS in which you use code to write less code to code (like my post signature). I find that if you tackle every loop like this:

Code: (javascript) [Select]

for (var i = 0, l = items.length; i < l; ++i) { /**/ }

// rather than:
Link(items).each(function() { /**/ });

Or every class like this:

Code: (javascript) [Select]

var SubClass = function() {
    Class.call(this);
    /* ... */
}

SubClass.prototype = new Class();

// Rather than:
var SubClass = Extend(Class, { /**/ });

Then you are doing JS within JS wrong. CoffeeScript had a good use to write out JS shims for old browsers which isn't exactly needed for Sphere. Sure there are JS features that have been added since Sphere 1.6, but if you use CoffeeScript solely for minisphere I doubt you'll get the most out of it.