Skip to main content

News

Recent Posts

71
Sphere General / Re: What is SFXR?
Last post by Fat Cerberus -
I think at this point, now that we're using ChakraCore instead of Duktape, I would probably want to implement something like this in JavaScript, on top of SoundStream, rather than bloating the Core API with what is really high-level functionality.  Then it would even work in Oozaru (which also implements SoundStream) without further code changes.
72
Sphere General / Re: What is SFXR?
Last post by FBnil -
Sorry for the lateness:
I took the code (with the blessings of the author) from http://www.drpetter.se/project_sfxr.html
And wrote an API for it for Sphere 1.6.
It was working, stable and tested.

There was a demo games/sfxr.zip and some unittests for it games/auto_test/scripts/test_sfxr.js
Are those resources needed?
If so, where can I upload them?
73
Hellos and Byes / Happy 2019!
Last post by FBnil -
Hello community! I hope each and everyone of you have a very fantabulous 2019!

https://www.merriam-webster.com/dictionary/fantabulous
74
Engine Development / Re: miniSphere 5.3.0
Last post by Fat Cerberus -
miniSphere 5.3.0 has just been released and is now available for download.  This version brings a ton of new APIs, a brand-new, faster version of from.js rewritten from the ground up, bumps the API level to 2, brings back support for 32-bit versions of Windows in the official release, adjusts script-loading semantics to allow using .js for modules (it's like a long lost friend coming back home :P), and so much more.

Be extra sure to check out the Release Notes for this release before getting started, as there are several potentially breaking changes due to modified semantics in a few places (the Core API remains backward compatible, as promised by the mS 5.0.0 API freeze).  And for Windows users, as always with milestone releases, uninstall your previous version of miniSphere before installing 5.3.0 to ensure all stale files get removed.

Merry Christmas everybody!
:santa: :christmas_tree::gift:
75
Libraries / Re: box2d-sphere
Last post by Eggbertx -
This project stagnated for a long time because I ran into some hiccups and had larger projects that needed my attention (and still do, technically), but it's actually starting to work decently, as you can see from the video. It still currently relies on the debug draw mode, but I'm figuring out how to make it more flexible. When I get a proof of concept "game" working, I'll post the source code to my changes to the original box2d-js, my box2d-stage module, and the game itself.
76
Engine Development / Re: miniSphere 5.3.0 RC1
Last post by Fat Cerberus -
miniSphere 5.3.0 RC1 is now available for download!  This is a release candidate, which means the code is essentially frozen; no further changes will be made other than bug fixes for 5.3.  If no major issues are reported, this exact build will become the final version of miniSphere 5.3.0.

There's way too much new stuff to list here (5.3 ended up way bigger than I originally planned), so just check out the release notes on GitHub:
https://github.com/fatcerberus/minisphere/releases/tag/v5.3rc1
77
Engine Development / Re: Oozaru: Sphere for the Web
Last post by Eggbertx -
What kind of functions do you have in mind?


One thing I can think of is accelerometer support. You see it in use in stuff like racing games, where your phone becomes a steering wheel, or even just simple stuff like Pokémon GO, where putting the phone upside down will turn the screen black to save performance.
Stuff like this, or handling swiping. Though I guess it would technically be possible for a game to do that, but a runtime ES6 helper module would be nice.
78
Engine Development / Re: Oozaru: Sphere for the Web
Last post by DaVince -
What kind of functions do you have in mind?
One thing I can think of is accelerometer support. You see it in use in stuff like racing games, where your phone becomes a steering wheel, or even just simple stuff like Pokémon GO, where putting the phone upside down will turn the screen black to save performance.

I imagine that Oozaru will be able to do more anyway, if we can have access to the JS DOM API.
79
Engine Development / Re: miniSphere 5.3b2 (stable: 5.2.13)
Last post by Fat Cerberus -
miniSphere 5.3 release is very close - just a few more API kinks I have to work out but otherwise everything is ready to go.

I even made a last-minute API addition: you'll be able to create custom BlendOps to have better control over the blending stage of the graphics pipeline.  This is something that can't be handled in the fragment shader at all--blending is still fixed-function even on modern hardware.
80
Engine Development / Re: miniSphere 5.3b1 (stable: 5.2.13)
Last post by Radnen -
I'm still baffled the widespread popularity of lodash... when libraries you and I write can be an order of magnitude faster, and any missing convenience methods lodash has, can always be added.

Anyways, I didn't have from.js on me, but I ran your parameters on my new Linkier library along with lazy and Link and got:
Code: ('js') [Select]
const Linkier = require('./linkier.js');
const Link = require('./modules/link.js');
const Lazy = require('./modules/lazy.js');
const Benchmark = require('benchmark');

// Generate a random list of 100,000 integer between 0 and 1,000.
const items = [];
for (let i = 0; i < 100000; ++i) {
    items[i] = Math.floor(Math.random() * 1001);
}

const suite = new Benchmark.Suite;
const linkier = Linkier(items).filter(n => n % 2 === 0).take(10000).map(n => n + 1);
const link = Link(items).filter(n => n % 2 === 0).take(10000).map(n => n + 1);
const lazy = Lazy(items).filter(n => n % 2 === 0).take(10000).map(n => n + 1);

suite.add('Linkier', function() {
    linkier.reduce((a, n) => a + n, 0);
}).add('Link', function() {
    link.reduce((a, n) => a + n, 0);
}).add('Lazy', function() {
    lazy.reduce((a, n) => a + n, 0);
}).add('For Loop', function() {
    let n = 0;
    let r = 0;
    for (let i = 0; i < items.length; ++i) {
        if (items[i] % 2 === 0) {
            n++;
            if (n <= 10000) {
                const m = items[i] + 1;
                r = r + m;
            }
        }
    }
}).add('For Loop 2', function() {
    let n = 0;
    let r = 0;
    for (let i = 0; i < items.length; ++i) {
        if (items[i] % 2 === 0) {
            n++;
            if (n <= 10000) {
                const m = items[i] + 1;
                r = r + m;
            } else {
                break;
            }
        }
    }
}).on('cycle', (event) => {
    console.log(String(event.target));
}).on('complete', function() {
    console.log('Fastest is: ' + this.filter('fastest').map('name'));
}).run({ async: true });

Code: [Select]
Linkier x 4,242 ops/sec ±5.49% (78 runs sampled)
Link x 3,786 ops/sec ±2.13% (91 runs sampled)
Lazy x 2,917 ops/sec ±2.87% (91 runs sampled)
For Loop x 2,213 ops/sec ±2.01% (96 runs sampled)
For Loop 2 x 11,052 ops/sec ±1.52% (97 runs sampled)
Fastest is: For Loop 2

What we learn here, is that hand-writing a for loop can be slower... The first for loop doesn't short circuit after 10,000 items, but that's on intention. How many times in writing a for loop you think of doing that? Therefore from.js, link.js and other libraries are going to be faster since they can make those common-sense decisions for you, and just automatically make your code faster.