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

Re: miniSphere 5.2b2 (stable 5.1.3)

Reply #2205 –
miniSphere 5.2 beta 2 is now available with more bug fixes and optimizations, better Sphere v1/v2 interop (including tweaks to how FlipScreen is handled in v2 code), support for all Sphere v1 surface blend modes and the ability to use Z.deflate and Z.inflate in Cell.

Re: miniSphere 5.2b2 (stable 5.1.3)

Reply #2206 –
Found a bug in beta 2: Calling MapEngine() or FlipScreen() from the event loop will cause the engine to crash on exit. :disappointed:

I have an idea of the cause already; fix will be in either beta 3 or 5.2.0 final, whichever comes first.
 

Re: miniSphere 5.2b3 (stable 5.1.3)

Reply #2207 –
This just in!  miniSphere 5.2b3 is up and fixes more bugs and brings new features for backward compatibility testing: 1) An apiLevel field in the game manifest for targeting a specific version of the API, and 2) --retro command-line option for SpheRun that makes the engine emulate the targeted API level (anything newer is disabled).

Re: miniSphere 5.2.0

Reply #2209 –
I agree TTF support would be nice to have, raster fonts work well enough in most cases but there's nothing like having an infinitely scalable typeface.  I'd want to give the API some thought first, as even if we just start with the bare essentials it needs to be extensible enough to remain stable.

I'll think about the best way to proceed on this front.

Re: miniSphere 5.2.1

Reply #2210 –
I forgot to mention before for anyone who hasn't already noticed, miniSphere 5.2 is now out of beta and brings a ton of new stuff: profiling, retrograde mode (old API emulation), blendmodes for Sphere v2, Dispatch.onExit() and much more.  Also, a lot of overhauling was done under-the-hood to give a very nice performance boost compared to v5.1. :smile:

Re: miniSphere 5.2.2

Reply #2211 –
miniSphere 5.2.2 is now available to fix a nasty bug in 5.2.0 and 5.2.1 that prevented double-clicking on minisphere.exe to launch the engine.  I'm a bit ashamed that this slipped under the radar, there's really no excuse for me not picking something that obvious up before the release.

Oh well, in any case it's fixed now. :sweat_smile:

Re: miniSphere 5.2.3

Reply #2212 –
Because miniSphere 5.1 shipped with Sphere.APILevel set to 2, in the interest of maintaining backward compatibility the APIs introduced in that release have been retroactively frozen and the current experimental API level increased to 3.

APIs added in level 2:
  • JobToken .pause() and .resume()
  • Color.PurwaBlue
  • Color.RebeccaPurple
  • Color.StankyBean

edit: The freeze mentioned above was reversed thanks to the release of 5.0.2 and 5.1.4.  Disregard this post.

Re: miniSphere 5.2.4

Reply #2213 –
miniSphere 5.2.4, 5.1.4 and 5.0.2 are up.  I did a simultaneous release across three minor versions to bring the API back into parity, since backward compatibility had drifted due to important bug fixes (for example 5.0 didn't support index.mjs) and the recent addition of system-directory packaging.  Now if you target API level 1 and the game works properly with --retro it is also guaranteed to work in miniSphere 5.0 (which notably is the last 32-bit version), as it should be.

No functional changes in 5.2.4 other than to drop the reported API level back down to 1.  Since I updated 5.1 to realign the level 1 API, the premature freeze mentioned above is no longer necessary.

5.0.2 and 5.1.4 are available on either the miniSphere GitHub Releases page or the Downloads Drive, if anyone needs them.

Re: miniSphere 5.2.5

Reply #2214 –
5.2.5 is up as a hotfix for a regression that prevented miniSphere 5.2.4 from being able to run standalone .js and .mjs scripts (it would show an unsupported API level error and quit).  Sorry about that!

Re: miniSphere 5.2.7

Reply #2215 –
Was image replaced with something else? It was completely remove from the sphere-runetime and game-modules, however Sphere Studio will still call the default project which still uses the image module.

Or am I missing something?

Re: miniSphere 5.2.7

Reply #2216 –
Yeah, the default project has been broken since miniSphere 5.0.0, that release changed the API significantly compared to 4.8 but it seems that I neglected to test creating a new project before I did the release.  I'll fix this in 5.2.8.  There was also a separate, more serious issue I discovered where several APIs are missing due to a bug in apiLevel handling.

Note that API Level 1 is frozen since 5.0.0 (the system modules are not, but I do try not to break them unnecessarily), so breakage like this should be minimized going forward.

Re: miniSphere 5.2.9

Reply #2217 –
miniSphere 5.2.9 is up.  It fixes a few minor SSj bugs as well as a bigger issue where certain combinations of circular module dependencies and import() (or require()) can crash the engine.  Barring major unforeseen issues (read: a showstopping bug), this will be the final release in the 5.2 series so that work can commence on miniSphere 5.3.

Re: miniSphere 5.2.9

Reply #2218 –
Forgot to mention this above, the module fix besides fixing the aforementioned crash, also corrects module load order which was previously reversed, such that imports will now correctly execute in the expected order, e.g. this will now work properly:
Code: [Select]
import 'side-effect-module-1';
import 'side-effect-module-2';

In miniSphere versions prior to 5.2.9, such imports would execute in reverse order, which could cause issues especially in cases where modules are pulled in only for their side effects, à la legacy RequireScript. Special thanks to @Rhuan for fixing this in ChakraCore.

Re: miniSphere 5.2.11

Reply #2219 –
I released miniSphere 5.2.11 which fixes a bug with dynamic import() and updates ChakraCore to the latest stable release (1.10.0).  This is the final version of miniSphere 5.2 so that I can focus on coming up with ideas for 5.3.  As always though, if there are any issues let me know so they can get fixed. :smiley: