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

I'm hoping to have the release ready by Halloween, but I'm not sure how feasible that is just yet.  There are a few showstoppers that may or may not be easy to fix:

So we'll see what happens.
Projects / Re: Project ZeC (My Zelda-esque Clone)
I love Zelda II.  Something about the atmosphere of the dungeons and towns always draws me in.  It's also unlike any other game in the series so the experience always feels fresh no matter how many times I go back to it.
Projects / Re: Project ZeC (My Zelda-esque Clone)
It's generally pretty easy to find $10-$15 mice in my experience.  Also a trackball is something different than a mouse and I actually find they give you more control.  I have one hooked up to my laptop, it's nice.

Even the cheapest mouse shouldn't crap out after 2 days though.  Definitely try to get your money back on that one.
Projects / Re: Project ZeC (My Zelda-esque Clone)
Not surprising, the Zelda II overworld graphics were obviously drawn to be very abstract, like looking at a paper map (I mentioned that in your other topic), whereas LoZ is top-down throughout so the tiles are more concrete representations of the objects they depict.
Sphere Support / Re: Player Movement Systems...
I kind of like the unmoving water, having no movement at all gives the overworld a feeling of looking at an actual map, with Link (whose own movements on the overworld are very rigid too) as a marker of sorts.  Then you enter a sidescrolling section and everything "comes alive" so to speak.  Even when the occasional random encounter enemies pop up it all feels very abstract.  Animated water in that context seems unnecessarily distracting.

Maybe I'm just weird though...
Sphere Support / Re: Player Movement Systems...
Link's Awakening to this day is my favorite Zelda game.  I have it on my 3DS and I play through the whole game at least once a year.  The size of the dungeons and the pacing were both perfect, and the reveal three quarters of the way through the game (no spoilers!) was so well-done that it colored my experience of the remaining 3 dungeons and made them completely unforgettable.

I do prefer the original black-and-white version to the colorized DX one though, not only for nostalgia (naturally) but also for reasons largely having to do with the aforementioned spoiler.  Some of the atmosphere was lost in the move to full-color.  Still an awesome game, though.
Forgot to mention - because files were renamed, I strongly recommend uninstalling any previous version of miniSphere before installing 5.0b4 to ensure cruft from previous versions doesn't cause problems.
5.0b4 is out now! 8)

The entire Sphere Runtime has been completely overhauled and brought some breaking changes with it (although I tried to be as conservative as possible), see the API documentation to find out what you'll have to do to upgrade.  Notably, Thread.join() and Scene#run() are no longer blocking and instead return a promise that you can await.

Major changes in Beta 4 off the top of my head:

  • "fullScreen" manifest field: Specifies default fullscreen state for game, defaults to false
  • "sandbox" manifest field: Specifies enforcement level of SphereFS sandbox.  "full" is the default and matches previous behavior, "relaxed" allows write access to @/, and "none" disables the sandbox
  • --performance command line option for SpheRun (disables the stepping debugger)
  • Thread#on_update() in subclass can be async and use await
  • No more or screen.flip(), v2 games must yield to the event loop (async/await makes this painless)
miniSphere 5 beta 4 is on its way, it's just that I keep hitting really bad bugs that I have to fix.  Also I'm a refactoring fiend so a good deal of the regressions are my own fault, but let's not talk about that... ;)
Projects / Re: Project ZeC (My Zelda-esque Clone)
Yes, that will produce an error.  You are effectively doing:

Code: (javascript) [Select]
var tn = GetTileName(undefined);
API design is a very subtle art and it's been my experience that method naming isn't always just about the immediate effect of a method.  Consider the difference between:
Code: (javascript) [Select]

Code: (javascript) [Select]

One might reasonably expect the former to close the engine regardless of what comes after.  It wouldn't, because the new job added to Dispatch keeps the event loop alive.  "But I explicitly said to exit, what's going on?!"  Whereas, if one looks at the latter code, it's requested a shutdown, but then added a new process afterwards which effectively cancels the request (you can't shut down if there are active processes).  It makes more sense intuitively that a request to "shut down" would be canceled (since an OS shutdown can do this too), canceling an "exit" (which sounds atomic) seems nonsensical.

Consider the documentation for ExitMapEngine(), where the note laying out the caveat is significantly longer than the description of the API:

And that note is *STILL* vague--what exactly causes MapEngine to return if not the exit call itself?  I know the answer to that because I'm familiar with the Sphere 1.x source code and know that it's single-threaded.  But to the uninitiated it's not nearly as obvious.  For example if you start a FlipScreen loop in an update script that will block the exit despite performing other event loop-y operations.  Which is why the miniSphere documentation is much more explicit about it:

Control MUST return to the engine (i.e. ongoing JavaScript operations must run to completion) for the request to be honored.
"exit" implies that the method is immediate (which it was), "shutdown" tells the reader that there's a process to it all.  Just as you can either press the power button to forcibly turn off the computer or click "shut down" which will cleanly shut down the OS but has rules to it (open processes must close first, busy apps can block it, etc.)  Subtle difference, but very important from an API design standpoint.  It's the same reason I renamed FileStream#size to fileSize: I want the API to be as intuitive and self-describing as possible to a person reading the code as it will be to the person writing it.
Sphere.exit() turned out to be problematic as it was implemented using a longjmp and apparently Allegro didn't like that, causing a crash on exit.  So I replaced it with Sphere.shutDown() which simply instructs the event loop to exit, similarly to how ExitMapEngine() works in Sphere 1.x.

I also brought back the Pact class!  With async/await and the event loop taking center stage in miniSphere 5.0, I figured there should be an easy way in the API to fulfill or reject promises out-of-band.  With Pact, as long as you hold a reference to both the promise and the pact it was made from, you can settle the promise at any time.  It's very intuitive and doesn't require understanding closures.
Projects / Re: Project ZeC (My Zelda-esque Clone)
That is a better explaination than the wiki. Although, not a fan of a "death" example

Not sure I follow - it's a good example of when you'd want to associate something with the world rather than a specific map.
I'm starting to put the finishing touches on miniSphere 5.0.  I'm not sure yet if there will be a 5.0b4 or if I'll go right to release-candidate stage for the next update.  I guess it depends how many bugs are reported in the meantime!

There is that crash on shutdown that @Rhuan keeps hitting, haven't been able to reproduce it yet... :(