So one thing that always bugged me about the Sphere map engine is that maps smaller than the screen are rendered aligned to the top-left corner of the screen.  Well, I've fixed that: Small maps will be centered in minisphere, as shown in the screenshot below.

Edit: Also, just because of how awesome this is: One of my most recent changes was to massively improve the CPU usage of minisphere under framerate throttling.  As you can see in the second screenshot here, my 2nd gen i5 is barely breaking a sweat running minisphere at 60fps without skipping a single frame.  See, when there's time left over after a frame, instead of uselessly spinning, the process actually goes to sleep via al_wait_for_event_timed(), greatly reducing its CPU footprint.  Of course, this doesn't apply if framerate throttling is off--at that point there's obviously nothing I can do.

Heh, you know most of the awesomeness with minisphere has a lot to do with, well... allegro being awesome.

This truly is a light-weight and fast implementation of Sphere! Can't wait to see full parity with the Sphere catalog. And as a bonus since allegro is so awesome there might be a future when minisphere get's a more decent engine like V8, but in the meantime this simply seems good enough.

And as a bonus since allegro is so awesome there might be a future when minisphere get's a more decent engine like V8, but in the meantime this simply seems good enough.

Yes, unfortunately Duktape is the weak link here.  For what it is (a lightweight, easy-to-embed JS engine, basically the JS answer to Lua) it's great, but there are some issues.  Namely, compiling scripts, even tiny delayscripts, is slow, even compared to Sphere 1.5's SpiderMonkey.  This means that anything that abuses delayscripts--like, say, Lithonite--is going to take a pretty noticeable performance hit.  Of course this can be alleviated in new games if I allow SetDelayScript and friends to take a (already-compiled) function as argument, but this does nothing to help games using the older method.

Not only that, but games with large codebases, for instance Trial & Error and Aquatis, cause a pretty painful delay on startup while all the scripts are compiled.

So I was going to wait until after releasing 1.0b2 to do this, but I had some free time today and implemented the networking API.  For this I used a tiny asynchronous networking library called Dyad (https://github.com/rxi/dyad), which is essentially just a thin wrapper over the target platform's native sockets implementation (e.g. Winsock for Windows, BSD sockets for other platforms) and adds only about 3k to the engine executable's size.

I tested it out with this code:

Code: (javascript) [Select]

var socket = OpenAddress("www.google.com", 80);
while (!socket.isConnected()) FlipScreen();
socket.write(CreateByteArrayFromString("GET / HTTP/1.1\r\nHost: www.google.com\r\n\r\n"));
while (socket.getPendingReadSize() == 0) FlipScreen();
Abort(CreateStringFromByteArray(socket.read(socket.getPendingReadSize())));

And got some HTML code back in both Sphere and minisphere, so it works perfectly!

minisphere 1.0b2 is out.

"Oh, I just casually implemented networking inbetween minor versions." Damn, man.

Haha, what can I say, I'm very motivated.  . For what it's worth, I'm getting very close to a 1.0 release, but I need some outside testing to happen first, particularly with regard to joystick support, which I couldn't test myself as I don't have a gamepad handy.

I'm thinking I might need to make some enhancements to the networking API, though.  As implemented in Sphere (and minisphere), it's very barebones and lacks basic functionality--for example, there's no way to tell from script when a socket has finished receiving data.

I think the networking API is very close to what it should be. I rather think it should basically be the same as the BSD socket API, which it almost is. Mainly, I believe that there should be an "Accept" function in addition to "ListenOnPort".

I'm not sure what you mean by "finished receiving data".

Is the SCons file commit going to be pulled in?

Ignore me on the finished receiving thing.  I didn't do enough research into how sockets work to realize that there was no built-in facility for the receiver to know when the other end has sent a full response (for instance, a full HTML doc), it's just an open data channel.

...and yes, that means I somehow successfully implemented networking without knowing a thing about how sockets work. 

As for SCons, can I cherry-pick only the SCons stuff somehow?  The rest of the commits in that pull would probably be a very bad idea to merge in at this point.  I may just have to close the pull and import them manually.

Ignore me on the finished receiving thing.  I didn't do enough research into how sockets work to realize that there was no built-in facility for the receiver to know when the other end has sent a full response (for instance, a full HTML doc), it's just an open data channel.

...and yes, that means I somehow successfully implemented networking without knowing a thing about how sockets work. 

As for SCons, can I cherry-pick only the SCons stuff somehow?  The rest of the commits in that pull would probably be a very bad idea to merge in at this point.  I may just have to close the pull and import them manually.

I do know there is a way to cherry-pick certain commits, using a command literally called `git cherrypick', but I don't recall exactly how it works. I haven;t had to do that since last summer.

I can just make up some new SCons files. There are new source files to account for, anyway. It's probably easiest that way.

Re sockets, you are guaranteed that write commands are not broken when they are read on the other end, even if the amount sent is greater than what a literal packet can hold. You are only in danger of having multiple responses queued up and not being able to distinguish where one ends and another begins. This is almost always solved by the application.

And I believe that anything more is totally up to the application, and really should only be in script in a Sphere-like environment. Only holding the BSD API allows Sphere-like engines to talk to any kind of server and be any kind of server. Any extension of this by the engine in native, I believe, puts this in danger.

So I see what you mean about the lack of any kind of Accept() function for listening sockets.  As it's implemented in Sphere, a socket created via ListenOnPort is literally replaced by the first thing to connect to it, meaning trickery like this is required to run an actual server:

Code: (javascript) [Select]

Threads.doWith({ socket: ListenOnPort(80) },
	function() {
		if (this.socket.isConnected()) {
			var text = GetVersionString();
			var data = CreateByteArrayFromString("HTTP/1.1 200 OK\r\nContent-Length: " + text.length + "\r\n\r\n" + text);
			this.socket.write(data);
			this.socket.close();
			this.socket = ListenOnPort(80);
		}
		return true;
	}
);

(Also, let's just take a moment to appreciate how awesome the Specs threader is. )

So I made some improvements to the networking API as suggested by Jester:

ListenOnPort() now takes an optional second parameter, max_backlog.  If not provided, it defaults to zero, which causes the socket to behave as in Sphere 1.5, closing the listener and replacing the socket in-place with that of the first client connection.  If max_backlog is greater than zero, it acts as a BSD socket, and the script must call the new Socket:acceptNext() method to get socket objects for new client connections.  If acceptNext() is not called periodically, any pending connections past the size of the backlog will be automatically dropped.  The listening socket remains open as a listener until closed.

The way this was done, it's fully backwards compatible with the Sphere API and only adds one new method.

Edit: Okay, I fibbed.  There are 3 new methods: The aforementioned acceptNext(), getRemoteAddress() and getRemotePort().  It's good to know who's connecting to your server, methinks.

Just posted minisphere 1.0b3.  See OP for download link and changelog.

At this point I have to recommend Sphere developers use minisphere over vanilla Sphere if possible.  Only a few APIs are unimplemented (particularly oddball stuff like color matrices), and minisphere is not only faster, but in my testing at least, less glitchy than Sphere 1.5.

Oh, and NEO: After a few necessary minor edits to the code, your Artyxx demo works great in minisphere.

At this point I have to recommend Sphere developers use minisphere over vanilla Sphere if possible.  Only a few APIs are unimplemented (particularly oddball stuff like color matrices), and minisphere is not only faster, but in my testing at least, less glitchy than Sphere 1.5.

I will say the only outstanding issues are discrepancies between SpiderMonkey and ECMA5.1, such as const and error constructors and other wacky additions Mozilla decided to add. Since my RadLib library has lots of this intrinsic stuff I'll have to spend time converting it. But yes, I should update my code rather because ECMA complacent JS ideally works anywhere ECMA is supported: it's the smallest subset that's considered correct JS.

I'm going to log bugs on github, even if they can't be fixed (such as const).