Skip to main content


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

Engine Development / Re: miniSphere 5.1.3
I've made some improvements under the hood that should make miniSphere 5.2 noticibly snappier than 5.1 in various scenarios.

Also some new features coming in the next release, stay tuned for more info. :D
Projects / Re: Sphere 6502 emulator
This is a pretty awesome little assembler/emulator, me likey. :smiley:  Is there a specific device this is meant to emulate?
Projects / Re: Sphere 6502 emulator
I'm intrigued and looking forward to seeing more. :D
Engine Development / Re: miniSphere 5.1.3
I've updated the link for the macOS build in the OP to 5.1.3.  All supported platforms are now up to date. :D
Engine Development / Re: miniSphere 5.1.3
5.1.3 is up to fix a couple annoying issues and add support for Promise#finally().  The error screen is also a bit more colorful now. :smile:
Engine Development / Re: miniSphere 5.1.2
miniSphere 5.1.2 improves exception handling for asynchronous code.  Unhandled rejected promises--and by extension, uncaught exceptions in async functions--will now trigger the error screen the same as a normal exception.  It also adds system-directory packaging: When packaging a game into an SPK, Cell will now include the system files to future-proof the package (do note that the packaged system files will be ignored unless the package is run with v5.1.2 or later).

These are somewhat large additions for a point release (and technically violate semantic versioning rules), but they are low-risk changes and I wanted to get these out sooner rather than later, particularly the async exception handling.

Note: In line with the post above, the Windows release of miniSphere 5.1.2 is 64-bit only.
Engine Development / Re: miniSphere 5.1.1
Heads up: The next Windows release will be 64-bit only.  I've considered doing this a few times before, but kept backpedaling since I still wanted to support XP/Vista.  There are few factors that make going full 64-bit make more sense now:

  • ChakraCore minimum requirement is Windows 7 SP1.  Except for circa 2009 Atom-based netbooks with crappy integrated graphics (on which the OpenGL experience was awful), the vast majority of consumer PCs made around this time came with a 64-bit version of Windows 7 preinstalled.  At least this was my experience.
  • Hardware makers are slowly dropping driver support.  nVidia recently did so for their graphics drivers, for example:
  • 32-bit Linux and macOS are already unsupported, as the ChakraCore build script only supports x64 builds.  This fact alone makes continuing to support 32-bit Windows feel like an anachronism.

So yes, long story short: miniSphere 5.2 5.1.2 and later will require a 64-bit operating system on all platforms.

edit: This change came earlier than expected and has been implemented starting with miniSphere 5.1.2.
Engine Development / Re: miniSphere 5.1.1
@Rhuan and I have been working on a great new debugging aid which is coming in miniSphere 5.2.  Historically, rejecting a promise in miniSphere would crash the specific promise chain it occurs in, but otherwise go unnoticed.  This can cause some very strange and difficult-to-understand behavior in heavily asynch code, especially in codebases where async functions are used heavily (like my own Spectacles project).  To illustrate the problem, take this code:

Code: (JavaScript) [Select]
async function pig()
    SSj.log("Oh no, I think I'm going to get eaten by the pig...");
    throw new Error("PIG!!!");
    SSj.log("The pig totally ate me, you guys!");

SSj.log("The pig is coming to eat EVERYTHING.");

This will hit all the SSj.log() calls except for the second one in pig(), and terminate normally.  That happens because pig(), being an unawaited async call, crashes at the throw without affecting the primary (i.e. synch) code path; the promise representing its return value is simply rejected sight unseen.

Broken promises are annoying and difficult to debug, but thanks to @Rhuan's hard work getting promise rejection tracking into ChakraCore, in miniSphere 5.2, the code above will be detected as a runtime error (by the event loop) and generate an error screen with a stack trace the same way an exception in synch code does.  This will make debugging async code much more pleasant.
Engine Development / Re: miniSphere 5.1.1
miniSphere 5.1.1 is up and fixes a bug where the engine could crash on startup if a game had any circular import dependencies.  The macOS build has been updated to the latest version as well.  Special thanks to @Rhuan for this release.
Site Comments / Re: Discord server
I do like Discord, but does it seem like it kind of killed forum activity? This wouldn't be the first time I've seen this happen to a community.

I don't know, the majority of the discord activity has been me and Rhuan trying to figure out bugs and stuff, back and forth conversations that don't really lend themselves to the bulletin board format anyway.  We've had lots of people join the discord channel, but none of them really talk, so...

It's more that we don't have that many members to begin with, I think, and they all have lives outside of Sphere.
Game Development / Re: DragonBall Z: Saiyajin Legend
I just noticed the low-health powerup ability is called "Plot Armor".  That's hilarious and awesome.
Game Development / Re: DragonBall Z: Saiyajin Legend
For the gameplay I'm picturing something like Secret of Mana but with DBZ characters.  Would that be accurate?  I played a bit of Buu's Fury a few years ago but didn't get very far in it, so I'm trying to get a feel for the battle system.

In any case this looks awesome.
Off-Topic Discussions / Re: Happy new year everyone!
Hmm... I wonder what new awesome miniSphere features await in 2018...

Happy New Year! 🎊
Engine Development / Re: miniSphere 5.1.0
Protip: The Sphere 1.x API is still available, and for the most part can be freely mixed with v2 API code.
Engine Development / Re: miniSphere 5.1.0
That's odd, because 5.1.0 was supposed to fix that:

So yeah, change any instances of "screen" to "Surface.Screen".