Skip to main content

News

Topic: Sphere 5.5.1 (miniSphere) (Read 408857 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.2.4
Reply #630

Awesome! I have some ideas for redistributable games in that regard:

- Obviously, direct filetype association with spk files would be nice. Double-click the SPK, play the game.
- Renaming the zips with a different extension (like .spk2 or .spherezip or something). This makes filetype association easier for Sphere zips. (Compare to .cbz "comic book zip" files, which are just archives filled with pictures)
- The game launcher detecting these packages if you put them in games/, of course. :)

And some more special ideas:
- If you distribute just the engine binary + an spk file, it'll pick up on the spk file so you don't even need a games or startup folder, it'll just open that when you start the engine.
- The ability to load multiple spk/zip files. Could be useful for loading the game and then loading extra resources on top of it (like a mod, a levelpack, etc.)


Going to take these one at a time.  Now that the SPK support is actually implemented, I can tackle these.

- Filetype association is best left to an installer, methinks.  Since the official distribution is for Windows, I think I can handle that.  minisphere 1.3 will be the first to be distributed as an installer.  That is, assuming Google will let me upload it to Drive, I think it might block uploading .exe files?  But yes, association with SPK would be nice.

- I'm thinking zip support won't make it into 1.3 after all.  Having actually implemented SPK and seen the inner workings of the format, it seems more than adequate for its intended purpose.  Plus it's insanely fast: I saw literally no performance difference at all running Specs from an SPK vs. directly.  They are even fast to compress, too--the Sphere 1.5 editor made a 35MB SPK out of my Specs project folder in seconds!  This to me is a clear case of "if it ain't broke, don't fix it" :P

- Self-evident, skipping. :)

Now, the "special" ideas:

- This is an awesome idea and not too difficult to implement either.  Only one question: If both a single SPK and a startup folder are present, which one takes precendence?

- This adds extra complexity to the engine, probably out of the scope of the 1.x releases.  A good idea for minisphere 2.0, though, I'll add it to the GitHub issue for that. :D
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.2.4
Reply #631
Quote
- This is an awesome idea and not too difficult to implement either.  Only one question: If both a single SPK and a startup folder are present, which one takes precendence?

I'd say the startup folder, because that folder existing is evidence the entire package was not made to be a standalone game. Perhaps the game could still appear in the games list; I believe the default startup game just starts the game if it's the only one it finds anyway.

As for the special ideas: they're just ideas. But it's awesome that you're tackling both of them anyway. :P

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.2.4
Reply #632
I just enabled write access for games running from packages.  Actually modifying the SPK file at runtime would be time-consuming to implement and the file isn't guaranteed to be writable anyway, so if a game requests write access to an existing file, it is saved in ~/Sphere/.spkcache/[filename.spk] (the Linux meaning of ~, not Sphere's :) )

Note that this differs from Sphere 1.5, which puts the cache in packages under the engine.  Since nowadays we have to assume the engine directory is read-only, this needed to be changed.
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: minisphere 1.2.4
Reply #633
Re non-local files - For now, I recommend keeping all the various Sphere format file I/O functionality focused on local files. For non-local files, we can certainly consider expanding the network functions' capabilities to include a cURL implementation/shim or something as sugar for the existing socket functions for non-vanilla pre-2.0 engines and eventually fold them into official 2.0 API. Once the kinks are worked out, this folding in would also eventually allow non-local file reading on the Sphere format file I/O.

Then again, if it turns out to be trivial to change file I/O in minisphere to allow at least networked file I/O (as in less than 2 hours or so to add) feel free to add it now, show us some working tests, and we can have it much sooner. I'll then fully support such an endeavor as marked to be made official ASAP.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.2.4
Reply #634

Then again, if it turns out to be trivial to change file I/O in minisphere to allow at least networked file I/O (as in less than 2 hours or so to add) feel free to add it now, show us some working tests, and we can have it much sooner. I'll then fully support such an endeavor as marked to be made official ASAP.


The beauty of SphereFS is that it canonizes the Sphere 1.x sandbox.  For example when you call LoadImage("foo.png") under minisphere 1.3, you are not requesting <game path>/images/foo.png, the canonical name of the asset is literally:
images/foo.png

And names of this form are what get passed around inside the engine, not actual file paths.  SphereFS itself handles the final path resolution and I/O behind the scenes.  So yes, network I/O would be very easy to implement.  The tricky part is the synchronicity--the default APIs for loading assets are blocking in nature, which would slow them down running over the wire.

Long story short, the actual network file I/O isn't the issue, it's the API.
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.2.4
Reply #635
As of the latest master, minisphere will auto-launch a single .spk file placed alongside the engine executable, making game distribution drop-dead simple.  I just have to work out a couple more glitches and 1.3 should be ready for release.  ;D
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.3.0
Reply #636
minisphere 1.3 is out! 8)

This brings Sphere 2.0 SphereFS support, and with it the ability to run games packaged as SPKs!  You'll note that the startup game was converted to an .spk... ;)

As is usual for an x.x.0 release, expect bugs to show up.  So download minisphere 1.3 and test away!
  • Last Edit: June 17, 2015, 07:06:52 pm by Lord English
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.3.0
Reply #637
Oh, not mentioned in the changelog, but minisphere 1.3 is fully Unicode-aware under the hood.  Person names, etc. are all UTF-8 internally, so you can feel free to use any characters you want in them and the engine won't choke on it. :)
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.3.0
Reply #638
Nice work, as usual! ;D

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.3.1
Reply #639
minisphere 1.3.1 is available, with a ton of fixes for regressions introduced in 1.3.0.  This is my biggest maintenance release in a while, so be sure to check the changelog. :D

@FBnil: The fog demo should now work properly as of this release.
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • FBnil
  • [*][*]
Re: minisphere 1.3.1
Reply #640
yes yes! it works now!

Tested ApplyColorFX(). (test script added).
Same behavior as Sphere 1.6, however, as you stated earlier, much slower.

Still have to modify the unittests, and publish it.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.3.1
Reply #641
I think part of the speed problem is that I pass colormatrix_t objects around by value, so a lot of copying goes on, even more so for applyColorFX4().  But I also know Sphere does clever tricks with bitshifts for this operation, which I'm sure speeds it up considerably.  minisphere also calls a function to do the matrix interpolation, so that adds even more overhead if the compiler doesn't inline it.

I purposely didn't optimize it for this initial implementation, though.  I wanted to make sure I understood the theory behind it first.  I know now that it's just simple bilinear interpolation, but it wasn't easy to figure that out with all the magic tricks going on. :)
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.3.1
Reply #642
minisphere also calls a function to do the matrix interpolation, so that adds even more overhead if the compiler doesn't inline it.


Which is probably at least an order of magnitude smaller than passing an object on the stack :) What is the sizeof for a colormatrix_t?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.3.1
Reply #643
int is 32 bits on Windows, a colormatrix_t has 12 of them.  So 48 bytes, or 96 bytes on a platform with 64-bit ints.

Edit: Honestly I'm starting to think most of the performance hit is that locking a bitmap in Allegro is just insanely expensive for no apparent reason.  I could understand it when I was using hardware textures, but switching surfaces to software offered no real performance improvement in, e.g. getPixel() until I also added the pixel cache for that.
  • Last Edit: June 18, 2015, 02:31:15 pm by Lord English
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: minisphere 1.3.1
Reply #644
So I ran the profiler on minisphere to figure out what was causing the massive slowdown on my battle screen, and came back with some... interesting results.

As you can see on the Summary page, the function causing the majority of the bottleneck is js_Font_drawText().  No surprise there, I already knew minisphere was slow at rendering text.  However, the runner-up shocked me: js_new_Color, the Color constructor.  You can see the breakdown for that in the second screenshot.  Apparently creating Color objects on demand on expensive!

For good measure, the third screenshot shows the main culprit in the text rendering bottleneck: al_hold_bitmap_drawing(false);  This should be ridiculously fast, as fonts are atlased so Allegro can just send all the vertices at once.  But apparently not...
Sphere 5.5.1 - miniSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub