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

Re: minisphere 3.0b3 (stable: 2.1.6)

Reply #1020 –
Cell is most likely going to get an overhaul before the official release (March 28), the codebase is not very modular making any changes difficult, and writing a Cellscript isn't particularly intuitive even with the manpage.

SSJ probably won't change any further, I'm very satisfied with how it turned out. :D

minisphere itself hasn't gotten many changes at all, the 2.1 codebase was already quite mature.  The only major change I made was to support source code download by the debugger.  Other than that it's just minor bug fixes.

Re: minisphere 3.0b3 (stable: 2.1.6)

Reply #1021 –
Hm, on second thought I think I'll hold off on that Cell overhaul until v3.1.  Development time would be better spent improving the Sphere Studio debugger UI, which has kind of fallen behind compared to SSJ's feature set, particularly w.r.t. variable and object inspection.

Re: minisphere 3.0b4 (stable: 2.1.6)

Reply #1022 –
I just posted the fourth and final beta for minisphere 3.0.  This one fixes a few SSJ crashes and has vastly improved object inspection in Sphere Studio.  See screenshot attached.

The rest of the time before release will be spent improving and polishing off the documentation, particularly the Linux manpages which are still a bit incomplete.

Re: minisphere 3.0rc1

Reply #1023 –
As the minisphere 3.0 release is only 3 weeks away, I decided to do a code freeze.  minisphere 3.0rc1 has been posted, and if no showstopping bugs are found, that build will be officially released as minisphere 3.0.0 on March 28.  I took down the links for 2.1.6 to encourage testing the new version.  As with all major minisphere releases, the previous one will remain available in the Spherical download repository.

Sphere Studio is no longer bundled: For Windows users, it is highly recommended to download Sphere Studio 1.2.1 as a companion to minisphere 3.0.

To the Spherical regulars:
I know you guys don't have much free time, but if some testing could be squeezed in on the RC before the 28th it would be much appreciated.  I will keep an eye out for bugs myself in the meantime.

Re: minisphere 3.0rc1

Reply #1024 –
I'll try to find time over the weekend to give it a go on Mac.

Re: minisphere 3.0rc1

Reply #1025 –
Thanks, NEO.  By the way you don't need to build Allegro manually after all: It turns out Allegro 5.1 is available through homebrew, you just have to use the --devel switch:
https://github.com/fatcerberus/minisphere/blob/master/INSTALL.md#mac-os-x

Re: minisphere 3.0rc2

Reply #1026 –
Well, now we're at release candidate #2.  There was a change I had to make to SSJ otherwise it would have driven me bonkers, the help command didn't recognize abbreviated command names.  Now it does!

...yeah, I'm bad at this whole "code freeze" thing. :P

Re: minisphere 3.0rc2

Reply #1027 –
Testing it out! It seems VERY stable; hasn't crashed once, even with the deb build that uses allegro 5.0. It's also fast, so far.
Now just coding random stuff (see attached file :P) and coming across the following:

I used TypeScript for a bit and it seemed to work fine. Classes worked properly and stuff. :)

LoadSound("it file").play(true) didn't work, but I think I remember this being an Allegro 5.0 specific problem, not a 5.1 one. Similarly, I think music keeps looping even if I tell it not to (there are several tunes in my test game and it's supposed to pick a random new one after finishing one song, but it always sticks to the same one tune it started out with).

surface.filledCircle(), and probably the other circle functions too, only accept integers. It errors out if I give it any radius that is a floating point value. It also doesn't seem to antialias them even when I pass true to the antialias argument.

Is there any way for the screenshot function to take a screenshot at the game's native size rather than the window size? I personally always thought that Sphere screenshotting at the native size was a strength, because it makes for really easy quick screen capping.

Finally... I still haven't played around with any of the new functions yet, other than trying TypeScript for a little bit. This is because this thread is huge and I don't know where I could find a list of the new functions specifically!

Re: minisphere 3.0rc3

Reply #1028 –
You'll have to look through the changelog to see what's new.  That should be much more manageable than trying to sift through a nearly 70-page thread! :P  Also check minisphere-api.txt, I make it a point to add all new APIs to that file.  It's missing some Sphere 1.x stuff mostly related to the map engine, but it's comprehensive otherwise.

Thanks for the testing, especially trying out TypeScript, I didn't expect that. :)

No antialiasing on circles is due to Allegro limitations, it's a known issue that I don't have any fix for at present.  Floating point radii causing an error is unexpected though, I'll have to look into that.  As for the screenshots: This is implemented by taking a snapshot of the backbuffer.  For low resolutions, the backbuffer is actually enlarged and all rendering is run through a transformation matrix.  So getting an actual-size screenshots is actually pretty difficult.  At one point I tried to have it scale down the screenshots before saving, but that caused loss of quality, so I decided to leave it as-is.

I'll look into the music issues, I think I touched the Audialis code during 3.0 development at some point and may have fouled something up.

Re: minisphere 3.0rc3

Reply #1029 –
@DaVince: I did some digging.  IT looping was an Allegro bug:
https://github.com/fatcerberus/minisphere/issues/17

One of the many reasons I made the switch to A5.1 for the Windows builds.  Unfortunately most of the bugs fixed in 5.1 never got backported...

Re: minisphere 3.0rc3

Reply #1030 –
Thanks for the tips. And yeah, I was pretty sure that was a 5.0 bug. I'm obviously testing the 64-bit deb so that basically means I'm stuck with 5.0 until April. :P

Re: minisphere 3.0rc2

Reply #1031 –
Just noticed this:

Quote from: DaVince – on

LoadSound("it file").play(true) didn't work, but I think I remember this being an Allegro 5.0 specific problem, not a 5.1 one.


This is not a bug, per se, and actually nothing to do with Allegro.  It's probably by sheer accident that it even works in Sphere 1.5.  What happens is: You're loading a sound, calling .play() on it and then immediately losing your reference to the sound object.  The garbage collector then finds it, sees it's unreachable, and finalizes it.  I'm guessing the old SpiderMonkey in Sphere 1.5 had a pretty lazy garbage collector and didn't free objects immediately, so that little trick ends up working.  Duktape primarily uses reference counting, so the second you lose the last reference, the refcount hits zero and the object is freed.

Working around it is possible: I could probably have the engine temporary bump the refcount of the sound while it's playing so that it doesn't get freed unless it stops (or the engine is closed).  That shouldn't be too difficult.  Sounds aren't intrinsically linked to the lifetime of the JS Sound object--they have their own independent refcount and everything.  That was done to allow assets to be passed around internally without causing segfaults galore when their JS objects go out of scope... those were just loads of fun to debug during early engine development. :P

Re: minisphere 3.0rc3

Reply #1032 –
Actually? Don't fix that. In hindsight, what you said about throwing the reference away, it might actually be good for the engine to fail at accomplishing this so people will be forced to do it the 'right' way instead. :)

Re: minisphere 3.0rc3

Reply #1033 –
Huh, weird.  I changed the line below to remove the Math.round():

Code: (javascript) [Select]

this.size = Math.round(4+Math.random()*7);


And it still worked fine on my end, drew the balls and everything.  What kind of error are you seeing when giving a non-integer radius?

By the way, a tip: minisphere has a far better random number generator than Math.random() built right in, based on Mersenne Twister and allowing manual reseeding.  In this case what you'd want is:
Code: [Select]

RNG.range(min, max);

  Returns a random integer uniformly distributed within the range [min,max].


To wit:
Code: (javascript) [Select]

this.size = RNG.range(4, 11);


There's also a drop-in replacement for Math.random, called RNG.random, along with a bunch of others (search for "RNG" in the API doc).  My favorite is RNG.normal - it gives you a random number from a normal distribution with a range of about 6 standard deviations.  I use it in Specs to calculate when bosses change phases.  I was going to use it for damage calculation too, but then I figured the critical hits from that would be brutally unfair and decided against it. :P

Re: minisphere 3.0rc3

Reply #1034 –
Quote from: DaVince – on

Actually? Don't fix that. In hindsight, what you said about throwing the reference away, it might actually be good for the engine to fail at accomplishing this so people will be forced to do it the 'right' way instead. :)


I fixed it anyway.  While it's probably bad to use that for playing looping music (since you can then never stop it), it's useful to be able to throw away references to sound effects and still have them finish--say you have a function that loads and plays a sound then returns: the sound object goes out of scope but you still want it to play through.  Without the fix you'd have to keep the reference somewhere globally accessible, which adds extra complexity (and prevents it from being GC'd ever).