Skip to main content

News

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Fat Cerberus

31
Engine Development / Re: miniSphere 5.3.0
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:
32
Engine Development / Re: miniSphere 5.3.0 RC1
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
33
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.
34
So when I said above that from queries would be blazing fast, I meant it, and to prove it I've done a quick benchmark of other similar solutions:
Code: (javascript) [Select]
let fromQuery = new Query()
.where(it => it % 2 === 0)
.take(10000)
.select(it => it + 1)
.reduce((a, it) => a + it, 0);
Code: [Select]
 event                    count   time (us)   % run  avg (us)    % avg |
------------------------------------------------------------------------
 Array method chain       1,001   3,605,798  34.1 %     3,602   34.3 % |
 Underscore chain         1,001   2,065,016  19.5 %     2,062   19.6 % |
 Lodash chain             1,001   1,168,390  11.0 %     1,167   11.1 % |
 from.js 1.0              1,001     903,805   8.5 %       902    8.6 % |
 from.ts (Oozaru)         1,001     875,786   8.3 %       874    8.3 % |
 Link.js query            1,001     475,447   4.5 %       474    4.5 % |
 Link.js query (NR)       1,001     325,084   3.1 %       324    3.1 % |
 from.js 2.0              1,001     319,423   3.0 %       319    3.0 % |
 Lazy.js sequence         1,001     270,130   2.6 %       269    2.6 % |
 Sphere from() query      1,001     205,757   1.9 %       205    2.0 % |
 Sphere Query object      1,001     188,966   1.8 %       188    1.8 % |
 handwritten 'for' loop   1,001     119,092   1.1 %       118    1.1 % |

Sphere from() query and Sphere Query object is us!  All timings are for running a chain equivalent to the above query 1,000 times with the respective library over an array of 100,000 random integers between 0 and 1000.

Special thanks to @Radnen for (indirectly) giving me the idea - Link.js was touted as a replacement for writing repetitive for loops, which got me to thinking... what if I just compile the query to an actual for loop...

This is really incredible that I was able to get so close to native loop performance and is a big win for code readability.  Query chains remain understandable even with 10+ query operators chained together, but throw together a couple filters and mappings plus a sort (or two!) and the set of for loops you need to write to match it can get pretty gnarly.  Lodash is proof people are willing to sacrifice a great deal of performance to get more readable code (see benchmark results above), even in tight loops where it matters most, but it's even better if you don't have to. :smiley_cat:
35
Starting in miniSphere 5.3, from() will be built into the Core API without the need to import the "from" module.  Like @Radnen 's Link.js library that came before it, from() queries are often incredibly useful in battle engines, and now I've written some code in the engine to compile these queries directly to JS for super-fast performance.

Code: (JavaScript) [Select]
let dinnerAmount = from(worldPopulation)
    .where(it => pig.isHungryFor(it))
    .besides(it => pig.devour(it))
    .reduce((a, it) => a + it.weight, 0);
SSj.log(`the pig just gained ${dinnerAmount} lbs.`);
36
Engine Development / Re: Oozaru: Sphere for the Web
I finally got SoundStream working today!  It took me forever to get it right and in the process I had to learn how to do sample rate conversion, but now Oozaru can run the sphere-mp3 demo (with a couple small code tweaks to accommodate for the lack of synchronous file loading).

Next I'm going to see about getting this thing to work in other browsers besides just Chrome.  This isn't the late 90s/early 2000s after all. :P
37
Engine Development / Re: Oozaru: Sphere for the Web
What kind of functions do you have in mind?
38
Engine Development / Re: Oozaru: Sphere for the Web
It's funny you say that because a big part of why I shelved Oozaru for a while is that, a year ago, the Web technology wasn't quite there yet.  WebGL was a thing (which I didn't realize at the time--Canvas2D is an awful API to use for game development), but the missing piece, ES module support, wasn't actually a feasible option since browser makers were only just starting to implement it.  I would have had to use a require() shim, which didn't seem ideal since you don't really want to be blocking your code while loading things on the web.  The user will hate you for it, and most likely so will the browser.  And I was just starting to push use of ES modules for Sphere at that point too, so forcing require() for Oozaru felt like a step backwards.

But now that stuff I need is finally widely available, Oozaru will finally see the light of day!  Or, well, the light of a full moon, as the case may be...
39
Engine Development / Re: Oozaru: Sphere for the Web
So after having left this project to languish for a year and almost giving up on it entirely, I picked it back up about two weeks ago and started hacking away... and now it can run the kh2Bar demo!

It currently requires an up-to-date version of Chrome or Safari but this serves as a very nice proof of concept.  The entire Galileo API is implemented (I think), the Keyboard API somewhat works, and it even reads the data from
game.json.

If anyone wants to test it out you'll need to checkout the Git repo and set up a local web server; I'll see about posting it online eventually.

https://github.com/fatcerberus/oozaru
40
The first beta of miniSphere 5.3 is out, bringing some new APIs and several useful features, including cell init for initializing a new, working project directly from the command-line (no Sphere Studio required!).  More will be coming, but this seemed like a good point to push out a beta to hopefully get some field testing in on the new features, especially cell init.
41
Game Development / Re: The Screenshot Thread
Huh, I didn't know there was a shortcut key for that.  I usually just press Win+G and look for the Record button.  That's a good wisdom! :dog2:
42
Projects / Re: OFF: Puppetmaster
Word to the wise: Do not attempt to fight off a giant eaty pig with a broomstick.  The broom will get eaten along with everything in a hundred-mile radius, which naturally includes you (unless you happen to have a broom that's over 100 miles long).

In less pig-eaty news, OFF is coming along slowly but steadily.  The first conversation with the Judge is implemented; next up I need to implement the first few puzzles and eventually the tutorial battle with the Judge.

It's so much easier to make a game when I can use pre-made assets and in general can use the original game as a template.  I just keep RPG Maker 2003 open and cross-reference it when coding the cutscenes. :)

I might post screenshots later.
43
Projects / Re: OFF: Puppetmaster
Finally started working on the field in earnest today, I've been trying to integrate @Rhuan's map engine but kept running into bugs.  He was quick about fixing them though so it's all good. ;)

My progress consists of a single map (drawn with shitty placeholder tiles, naturally :P) with a teleport trigger at the top that sends you to another unfinished map with some music... that you then can't escape from.  So nothing special yet, but it's progress at least.  Next up: Fending off the pig with this broomsti*MUNCH*
44
Projects / Re: OFF: Puppetmaster
I've finished the title screen as well as the entire opening cutscene of the game--save for the name-entry screen so the player can enter his/her name.  This game plays with the fourth wall a bit so that screen is kind of important. :P

This being my maiden voyage of developing for Sphere v2 (Specs doesn't count as that was gradually ported from v1 as-needed and isn't even a full conversion), I have to say developing for the new engine is a joy.  The event loop is great, especially when combined with async-await, it's easy to coordinate concurrent actions and makes the engine very powerful as a result.  Many things that were very awkward to do with the v1 API are trivially easy with v2.  It's awesome.
45
Game Development / Re: The Screenshot Thread
Here's a couple of screenshots from the introduction of my OFF remake.  @DaVince has actually seen it in action; I'll hopefully post a demo soon.