I actually tried to fix the const thing early on by editing Duktape, but it's lexer code is... Obtuse.  Go ahead, try to find keywords in duktape.c, they just aren't there.  It baffles me.

Good news: I posted an issue on Duktape's GitHub repo regarding the lack of a reported filename for syntax errors, and the dev fixed it.  So now minisphere reports the exact location of syntax errors, making it easier to locate consts that need to be changed.

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

It defaults to 16 in Sphere 1.5. That's just the number of pending connections that have not yet been Accept'ed before connections start getting refused outright.

That makes no sense because Sphere 1.5 has no accept() method for listeners and (from what I can tell) the listening socket closes as soon as someone connects to it, at which point the object becomes (i.e. is internally mutated into) a normal bidirectional socket.  Sphere might set a backlog of 16 internally, but the way the API is exposed, it effectively can only accept a single connection.  Hence the zero default in minisphere to specify the legacy behavior.

Note that the actual backlog on a socket is likely going to be larger than whatever you pass to ListenOnPort() for the second parameter anyway because Dyad is set up to accept() connections automatically--I get a callback with the new socket only after this has been done for me.  Which means minisphere can't actually reject any connections--it has to disconnect them after they've already been established if its own backlog is full.

Do connections close properly when Sphere shuts down? One thing I noticed is that when I made networked games in Sphere 1.5, and you hit the X button or Alt+F4 out of the app, you couldn't close open files, connections, etc.

In fact it'd be nice to have access to that as a new feature. The "on close" or "shutdown" callback.

All native-implemented objects in minisphere have finalizers and Duktape guarantees they will be called on shutdown if the GC hasn't done so already.  Duktape also uses refcounting in addition to mark-and-sweep, so in most cases you don't even have to wait for an object to be collected when it goes out of scope--it's finalized immediately.  Short of a segfault (or refcounting bug in minisphere--I've encountered these before and they're not pretty), you're not likely to leak resources in minisphere.

That said, a shutdown callback could be useful.  I'll consider implementing such a thing.

I've decided to make minisphere's API functions more JS engine agnostic.  They are now defined like this:

Code: (c) [Select]

static js_retval_t
js_CreateColor(_JS_C_FUNC_ARGS_)
{
	js_begin_api_func("CreateColor");
	js_require_num_args(3);
	js_int_arg(1, r_val);
	js_int_arg(2, g_val);
	js_int_arg(3, b_val);
	js_maybe_int_arg(4, a_val, 255);

	r_val = fmin(fmax(r_val, 0), 255);
	g_val = fmin(fmax(g_val, 0), 255);
	b_val = fmin(fmax(b_val, 0), 255);
	a_val = fmin(fmax(a_val, 0), 255);
	js_return_sphereobj(color, al_map_rgba(r_val, g_val, b_val, a_val));
}

Unlike Sphere's beginfunc() macro, this still looks like a normal C function and so doesn't hurt the code's readability.

The thing is though, I don't know if I'm up for the massive refactoring that's going to be required to get all my API functions to conform to this setup...

minisphere 1.0b4 is up.  No new APIs this time around, just under-the-hood changes.  Much of the architecture was rewritten, however (I now use fopen instead of Allegro's file routines, for example), so I thought it was good to push out another release so I could get some testing in.

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

Groovy! Can you PR those edits to the repo?

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

Groovy! Can you PR those edits to the repo?

Haha, sure, thing.   Until you said that I had actually forgotten I checked it out from GitHub!

That makes no sense because Sphere 1.5 has no accept() method for listeners and (from what I can tell) the listening socket closes as soon as someone connects to it, at which point the object becomes (i.e. is internally mutated into) a normal bidirectional socket.  Sphere might set a backlog of 16 internally, but the way the API is exposed, it effectively can only accept a single connection.  Hence the zero default in minisphere to specify the legacy behavior.

That's not what that number means. Setting that number to zero in Linux or BSD will result in no connections whatsoever being accepted. If any are accepted with winsock, that is a bug in winsock or a misinterpretation of the BSD API. Setting that number sets the number of connections that can exist waiting on listening socket, waiting for an Accept. Setting it to zero means that there can be zero sockets ready to be accepted, the queue has a size of zero and will always be empty.

Setting it to one is much more correct.

That makes no sense because Sphere 1.5 has no accept() method for listeners and (from what I can tell) the listening socket closes as soon as someone connects to it, at which point the object becomes (i.e. is internally mutated into) a normal bidirectional socket.  Sphere might set a backlog of 16 internally, but the way the API is exposed, it effectively can only accept a single connection.  Hence the zero default in minisphere to specify the legacy behavior.

That's not what that number means. Setting that number to zero in Linux or BSD will result in no connections whatsoever being accepted. If any are accepted with winsock, that is a bug in winsock or a misinterpretation of the BSD API. Setting that number sets the number of connections that can exist waiting on listening socket, waiting for an Accept. Setting it to zero means that there can be zero sockets ready to be accepted, the queue has a size of zero and will always be empty.

Setting it to one is much more correct.

I know what the backlog is.  I researched sockets after implementing the networking API to better understand how everything works.

Here's the thing: The Dyad library I'm using for networking manages it for me.  From what I can tell, Dyad by default sets a backlog of 511 and accepts connections for me, it's just that, for compatibility reasons, I defined zero passed to ListenOnPort() (NOT winsock) to be a sentinel meaning "make this socket behave as in Sphere 1.5".  It doesn't mean the actual backlog is zero--that would be nonsensical!

Long story short: minisphere still accepts connections past the backlog value passed to ListenOnPort, it just drops them immediately if it's own backlog is full.  Understand now?

New APIs: RoundRectangle and OutlinedRoundRectangle.  No idea why Sphere didn't have these, but now minisphere does!

Hm, looks like minisphere was so successful that I attracted a spambot!

Okay, so heads up: Next release of minisphere will include at least the following as system scripts:

• analogue.js (Radnen)


• kh2Bar (me!)


• Link (Radnen)


• MultiDelegate.js (me again!)


• Scenario (totally me! )

I may add more, but these five seemed like good candidates for essential functionality to include in the default distribution.

I'm removing all the old legacy cruft that the system scripts folder comes with in vanilla.  I haven't seen a game yet that uses any of them, and at least half of them are broken or incompatible now anyway.  They're just dead weight at this point.