Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8506287 times) previous topic - next topic
0 Members and 10 Guests are viewing this topic.

Re: minisphere 1.0b3

Reply #165 –
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.

Re: minisphere 1.0b3

Reply #166 –
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. :)

Re: minisphere 1.0b2

Reply #167 –
Quote from: Lord English – on

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.
 

Re: minisphere 1.0b3

Reply #168 –
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.

Re: minisphere 1.0b3

Reply #169 –
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.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: minisphere 1.0b3

Reply #170 –
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.

Re: minisphere 1.0b3

Reply #171 –
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... :-\

Re: minisphere 1.0b4

Reply #172 –
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.

Re: minisphere 1.0b4

Reply #174 –
Quote from: N E O – on

Quote from: Lord English – on

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


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!

Re: minisphere 1.0b3

Reply #175 –
Quote from: Lord English – on

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.

Re: minisphere 1.0b3

Reply #176 –
Quote from: Flying Jester – on

Quote from: Lord English – on

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?

Re: minisphere 1.0b4

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

Re: minisphere 1.0b4

Reply #178 –
Hm, looks like minisphere was so successful that I attracted a spambot! :P

Re: minisphere 1.0b4

Reply #179 –
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.