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

Re: minisphere 4.2.4

Reply #1380 –
Thanks, it crashes on Win10 too.  And, well, this is embarassing.  It crashes here:

Code: (c) [Select]

source = sfs_fslurp(g_fs, filename, NULL, &source_size);
code_string = lstr_from_cp1252(source, source_size);
free(source);


source is NULL because main.js didn't make it into the dist (it's not mentioned in the Cellscript).  This ultimately leads to a crash.

It should have given you an error that main.js didn't exist rather than crashing, I'll need to fix that.

edit: By the way, you don't need a game() function for Sphere v2, and in fact unless the engine is running in 1.x compatibility mode the function will be completely ignored.  Sphere v2 should be written like you'd write a Node.js script.

Re: minisphere 4.2.4

Reply #1381 –
Well, now I also wonder: how did main.js not get referenced? I literally just created a new project in Sphere Studio and those files were already included. I guess there's something to fix there too?

Re: minisphere 4.2.4

Reply #1382 –
Yeah, the project template is probably broken.  I always forget to update that when I reorganize stuff.  It was originally made for Sphere 1.x where all scripts go into the "scripts" folder.  For now you can fix it by adding this to the Cellscript:

Code: [Select]

install(files("main.js"));


Sorry about that.  :-[

Re: minisphere 4.2.4

Reply #1383 –
Thanks, I'll do that. That seems to work, at least! If I keep my other scripts in scripts/, should I be fine for the time being?

Edit: wait, it doesn't work properly after all. My script has one GetKey() but it is ignored and minisphere just quits right away. Same deal if I do while (!IsAnyKeyPressed());...
Edit 2: Oh wait. I guess game() isn't where Sphere starts by default anymore. Gotta start reading up on the documentation!

Re: minisphere 4.2.4

Reply #1384 –

Oh wait. I guess game() isn't where Sphere starts by default anymore. Gotta start reading up on the documentation!


Yep, I mentioned that above, guess you missed it.  minisphere completely ignores the game() function if you're running in Sphere v2 mode because everything is a module (like Node).  Write your scripts like you were writing a Node.js program.  Obviously it's not ignored in Sphere 1.x compatibility mode because that would break... well, pretty much everything. :P


Re: minisphere 4.2.4

Reply #1386 –
Okay, both the crash and project template are fixed in the latest build on GitHub.  Thanks for bearing with me on this.

Unfortunately Sphere v2 mode doesn't get much testing; I still need to run Specs in v1 mode because it relies heavily on RequireScript() and stuff going into the global scope, which doesn't work when everything runs as a module.  Some example projects I can test against would remedy that, but I've been too lazy to put anything together.

Re: minisphere 4.2.4

Reply #1387 –
Nice, will get it right away. :)

And I'm fully planning on creating a Sphere game with the new API in the coming weeks, so hopefully that will help. By the way, the API seems outdated again; Keyboard is undefined. Um, gonna check that changelog again.
Edit: I see, the API reference is actually ahead this time and it's still "keyboard" in this version. Gotcha.

Re: minisphere 4.2.4

Reply #1388 –
Yeah, I'll release 4.3.0 in a day or two and then everything will be in sync again. :)

Re: minisphere 4.2.4

Reply #1389 –
One quick change I want to make before release is for `Dispatch.later()` to be frame-perfect rather than wall clock timed.  This way it can be used to accurately time in-game events.  I might still have it take a value in seconds, but the actual timing would be based on frames under the hood.  For example if running at 60fps, then 2 seconds translates to "120 frames".

Re: minisphere 4.2.4

Reply #1390 –


Oh, I know about that, that's why I always run them in a terminal. But it still wasn't outputting anything by using the minisphere command.


No, that's what I meant - even if you have a terminal window, if the executable was compiled as a GUI application, Windows won't allow it to print anything.


It will if you manually fflush after every newline.

Re: minisphere 4.3.0

Reply #1391 –
minisphere 4.3 is out, and it includes a ton of new stuff: the new Dispatch API, promises, Reflect, miniRT enhancements, frame-perfect timing, better Sphere 1.x compatibility (it now runs Kefka's Revenge!), API refactoring, and a bunch of bug fixes.  Get it today--and get eaten by a giant pig tomorrow! :pig_nose:

I'm especially proud of the Dispatch API, as it brings the functionality of Sphere 1.x update, render and delay scripts engine-wide.  And you can set up multiple update and render jobs, so it ALSO works like the old hook-list script with the added bonus of being able to control the order using priorities.  It's quite useful!

Re: minisphere 4.3.0

Reply #1392 –
@Eggbert: It looks like you forgot to update the .tar.gz for the Arch release again, it's still the one for 4.2.4.


Re: minisphere 4.3.0

Reply #1394 –

minisphere 4.3 is out, and it includes a ton of new stuff: the new Dispatch API, promises, Reflect, miniRT enhancements, frame-perfect timing, better Sphere 1.x compatibility (it now runs Kefka's Revenge!), API refactoring, and a bunch of bug fixes.  Get it today--and get eaten by a giant pig tomorrow! :pig_nose:

I'm especially proud of the Dispatch API, as it brings the functionality of Sphere 1.x update, render and delay scripts engine-wide.  And you can set up multiple update and render jobs, so it ALSO works like the old hook-list script with the added bonus of being able to control the order using priorities.  It's quite useful!

Nice! I've been wanting to try out the new features. :)