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

Re: miniSphere 4.7.0

Reply #1815 –
MiniMP3 seems to be buggy or something.  Stereo files at least don't seem to be decoded properly; if I create a stereo stream with the proper frequency, the sound is choppy (like it's coming through a box fan or something) and plays at half speed.  If I create a mono stream at double the frequency, it sounds normal with just a bit of distortion.  No idea what's up with that.

In any case I most likely will ultimately use a different mp3 library.  I want to try to get Fluendo's decoder working because that's MIT-licensed so I don't have to worry about LGPL quibbles.  And all the mp3 patents are expired now so that'll be great :D

Re: miniSphere 4.7.1

Reply #1816 –
miniSphere 4.7.1 fixes a very, very old bug where getting stuck in an infinite loop caused you to be completely locked out of the debugger.  Not only does that mean you no longer have to kill the miniSphere process when that happens, it also means you can click the Pause button in Sphere Studio to find out exactly where your code is stuck!

Re: miniSphere 4.7.0

Reply #1817 –
Quote from: Fat Cerberus – on

If you don't set Sphere.Game.version to 1 in your Cellscript, the default is 2.  In that case your main script will be loaded as a CommonJS module (like node) rather than normal program code (like Sphere 1.x/browsers).  You have a few options: A) Set the API version to 1; B) Explicitly make the variable global global.objects = ...; or C) Take advantage of closures and pass a function to SetDefaultMapScript().


Just making sure I understand this correctly so that I avoid running into similar errors later on, "synth:onLoadMap" and any other similar case run from SetDefaultMapScript runs from a different "scope" than the main module and anything declared/defined in it that is not explicitly added to the global object? If I put
Code: [Select]

// main
global.somepkg = require('somepkg');
global.otherpkg = require('otherpkg');

is somepkg available from otherpkg without doing
Code: [Select]
global.somepkg = require('somepkg');
from there as well? I have only a rudimentary understanding of CommonJS usage.


Also, as a suggestion, can you replace glob strings in CellScript's files function with a regular expression? I don't know how common this is, but I sometimes save copies of a script as "scriptname.bak.js" if I have to make major changes to scriptname.js and don't want to have to do a lot of backtracking and rewriting if I have to exit before the major change is implemented. This would allow me to do something like
Code: [Select]
install("@/scripts",files(/scripts\/.*(^bak)\.js$/, true));
 

Re: miniSphere 4.7.1

Reply #1818 –
CommonJS is pretty simple to understand, just pretend the whole module is wrapped inside of:
Code: [Select]

(function() {
    // your module code here
})()


...which is exactly what the engine does under the hood when loading them.  That way any vars, functions, etc. are local to the module.  By assigning something to global you explicitly put it in global scope, the same as adding stuff to window in a browser.

SetDefaultMapScript() etc. basically work like eval(), anything in there is effectively run in the global scope.  Unlike Sphere 1.x, miniSphere lets you pass a function to them instead though, if you wanted to take advantage of normal scoping rules.

Regarding Cellscript regular expressions, I actually wanted to implement that originally, but it's pretty hard right now because files() is implemented natively and Duktape doesn't expose its regex engine to C code.  I didn't want to add a dependency on a third-party regex engine just for the sake of pattern matching files.  Maybe I'll put in a feature request on the Duktape repo...

Re: miniSphere 4.7.1

Reply #1819 –
By the way, tip: requires are cached.  So if you do require('something') in multiple places, only the first one will actually load the module and the rest will just return the cached exports.  So you get built-in lazy loading that way without needing to store it globally.

Re: miniSphere 4.7.1

Reply #1820 –
Quote from: Fat Cerberus – on

CommonJS is pretty simple to understand, just pretend the whole module is wrapped inside of:
Code: [Select]

(function() {
    // your module code here
})()


...which is exactly what the engine does under the hood when loading them.  That way any vars, functions, etc. are local to the module.  By assigning something to global you explicitly put it in global scope, the same as adding stuff to window in a browser.

SetDefaultMapScript() etc. basically work like eval(), anything in there is effectively run in the global scope.  Unlike Sphere 1.x, miniSphere lets you pass a function to them instead though, if you wanted to take advantage of normal scoping rules.

Alright, good to know to avoid future confusion.

Quote from: Fat Cerberus – on

Regarding Cellscript regular expressions, I actually wanted to implement that originally, but it's pretty hard right now because files() is implemented natively and Duktape doesn't expose its regex engine to C code.  I didn't want to add a dependency on a third-party regex engine just for the sake of pattern matching files.  Maybe I'll put in a feature request on the Duktape repo...

Is there no available Regex engine that can be implemented similar to Duktape (i.e. you provide the source and header files in your own code rather than linking)? It seems especially strange, considering the RegExp constructor is available.

Quote from: Fat Cerberus – on

By the way, tip: requires are cached.  So if you do require('something') in multiple places, only the first one will actually load the module and the rest will just return the cached exports.  So you get built-in lazy loading that way without needing to store it globally.

I figured that would be the case, since that would be more efficient than having to reload a library every time require is called.

Re: miniSphere 4.7.1

Reply #1822 –
Quote from: Eggbert – on

Oh, and you never answered my question. In the meantime, until regular expressions are allowed, or if they aren't at all, is scriptname.bak.js a common practice in case a major change doesn't work out?


I can't speak for anyone else, but I use version control for that (Git).  If I used your method though, I would probably swap it around to script.js.bak instead--then normal globbing would exclude them.  For me version control works better though because my "major changes" tend to involve multiple files (thanks to my penchant for refactoring) and at some point I would almost surely forget to back one up and screw myself over. :P

Re: miniSphere 4.7.1

Reply #1824 –
I use GitHub Desktop for day-to-day stuff and only use the command line interface for more advanced stuff (like bisect).  Nothing like being able to right-click individual files and "Discard Changes" to automatically revert to the previous commit.  It would be awesome if it let you discard changes within a file that way, that'd be perfect.

Command-line junkies can say what they want, but sometimes a GUI really is a more efficient way to work.

Re: miniSphere 4.7.1

Reply #1825 –
Quote from: Eggbert – on

Is there no available Regex engine that can be implemented similar to Duktape (i.e. you provide the source and header files in your own code rather than linking)? It seems especially strange, considering the RegExp constructor is available.


I can actually just call the regexp object methods directly (so I was wrong to imply it was impossible), but for sandboxing purposes I didn't consider that ideal.  It's a good idea if nothing else works out, though.

Re: miniSphere 4.7.1

Reply #1828 –
Quote from: Eggbert – on

I use Linux a lot, and according to WineHQ, it doesn't run, or runs terribly.


That doesn't surprise me, I'm pretty sure it's written in C#.  Sphere Studio doesn't run that well in Wine either.

Regarding Git support in the IDE, I considered that for Sphere Studio at one point too.  Maybe I'll eventually get around to implementing it. ;)

Re: miniSphere 4.7.1

Reply #1829 –
I'm about to disappear for a while, but advance query for when I'm back, after I get the mapengine working well I'd be keen to help with making a variant of minisphere to run with spidermonkey, I'm very curious what that would do to performance.

(Note, in my draft sprite and map engine scripts the bottleneck performance wise is now in the javascript not in the rendering - when I say bottleneck I'm talking about it slowing down when dealing with moving ~1000 sprites)