Skip to main content

News

Topic: neoSphere 5.6.4 (with Cell, SSj) (Read 445838 times) previous topic - next topic

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

That sounds really useful, especially on Linux. Think you can also generate the standard project folders on cell init?

Also, for the "adding files" thing, I don't know how I feel about manually adding every thing into the project. It adds a factor of forgetting to add that new script or resource you just made that the game uses. Wouldn't adding every file/folder found that matches the standard Sphere format work better? Or perhaps a list of files to ignore for packaging, rather than files to add?


Hm, I agree it's very easy to forget to add something, and then end up with a non-working SPK package.  Automatically adding all files matching the Sphere formats isn't really optimal either, since there are some games (like your own Sir Boingers) that have .txt files serving as control data in the maps folder that would be skipped over and break the package.  So the blacklist idea might work.  To simplify things it could be based on wildcard patterns as with the .gitignore file in a git repository rather than individual filenames.

The other alternative is to just package everything in the source directory, but that requires some discipline on the developer's part to put non-game files like design documents and such outside of the source directory.

I do like the idea of having it create the standard folders.  Thanks for the tip. :D
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.1.0
Reply #1186
minisphere 3.1.0 is up.  I'm not up for that Cell overhaul just yet, but didn't want to delay the 3.1.0 release, so... here it is!  New in this version: the Transform object, setting shader uniforms (Allegro 5.2 only), new single-character SphereFS aliases, new miniRT modules, and a few other enhancements under the hood.  Get it while it's hot! :D
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.1.0
Reply #1187
From here on out I'm going to try to minimize the breaking changes in minor releases.  It's going to make Sphere very hard to support from a user perspective if games break with every update.  It's not so bad for us developers who can just update our code, but breaking packaged games is not nice.  The only thing that's been perfectly stable since the first version of minisphere is the Sphere 1.x API for the simple fact that it HAS to be locked down to avoid breaking compatibility.

This is part of why I want to implement an Android-like "API level" value in the eventual overhaul.  The level is strictly increasing so that whenever changes are made to the API, the API level is bumped.  This makes writing compatibility shims easier as well as allowing game code to adapt more easily since each API level is well-defined, as opposed to the current model of, "Oh, I think I changed that in minisphere 8.12... or maybe it was 7.0?  Anyway, yeah, go look at the API reference again." :P

Anyway, I'll try to have more self-control going forward.
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.1.1
Reply #1188
@DaVince minisphere 3.1.1 includes a change that might fix the lockup you saw the other day when running against Allegro 5.0.  Care to re-test when you get a chance?
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rahkiin
  • [*][*][*]
Re: minisphere 3.1.1
Reply #1189
You could just document when you add or deprecate a function/value/class/whatever.

I suggest you use SemVer: breaking changes (removing stuff) needs a major version number update, new stuff needs a minor version update (old code still works, but code written for 5.4 might not work on 5.3). And when you fix stuff, use patch. 5.4 code should work on 5.4.10 and other way around.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.1.1
Reply #1190
Yeah, the problem is that you basically can't ever break anything once the API is established, otherwise you break already-packaged and released games which isn't nice.  It'd be like if every single Android update broke everything on the app store.  People wouldn't think very highly of the platform. :P  As for SemVer, it's actually really hard to get right.  I refactor constantly, and since I'm a perfectionist the refactoring usually extends to the API, so stuff breaks.  If I followed SemVer to the letter, you'd be getting minisphere v812.0 by now. :P
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rahkiin
  • [*][*][*]
Re: minisphere 3.1.1
Reply #1191
Just don't release so often then. Also, if you give someone a game, pack it with the version of minisphere you tested it with.
If you send someone a game with my engine, the .app contains both the game and the engine so you can just start it. And it is always the right version, until the developers gives the game an update with new version of the engine and distributes that.

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 3.1.1
Reply #1192

@DaVince minisphere 3.1.1 includes a change that might fix the lockup you saw the other day when running against Allegro 5.0.  Care to re-test when you get a chance?

Works great, thanks. :)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.1.1
Reply #1193
Nah, I follow the philosophy of Release Early, Release Often, I don't like keeping new features to myself and this is more likely to reveal bugs quickly :)

Anyway, packaging the engine was something normally done with Sphere 1.x.  I don't much like that - it'd be nicer if users could just install one copy of the engine and then you only have to distribute the .spk file.  This can be done as long as I show some self control in changing public APIs.  Which is exactly what I promised to do above, so don't worry.
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.1.1
Reply #1194


@DaVince minisphere 3.1.1 includes a change that might fix the lockup you saw the other day when running against Allegro 5.0.  Care to re-test when you get a chance?

Works great, thanks. :)


That's good.  I wish I knew the workaround would be so simple or I would have done it a long time ago. ;)

By the way you can do "spherun --version" to see the version of all dependencies including Allegro.  Useful when making bug reports since everything on Linux is dynamically linked.
  • Last Edit: May 10, 2016, 03:52:28 pm by Lord English
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.1.2
Reply #1195
So I decided what I want to do for minisphere 4.0.  I'm going in a slightly different direction than the original Pegasus ideals.  In Pegasus, everything is a module, including all the standard subsystems.  This is similar in design to Node.js.  Now in Node this kind of setup makes sense, because it's a primarily designed for servers and you only want your server to load what it actually uses.  Node has a LOT of different components built into it that most apps won't even use half of, so it would be wasteful to load up everything in advance.

In all my experience with Sphere, I can't help but feel that the Node.js-inspired design for Pegasus is overkill.  It's not a big deal if the engine needs to initialize audio for a game that happens not to play sound, for example.  And needing to, say, require("graphics"); at the top of every file gets tedious, even more so once you start needing other components (audio, engine, fs, keyboard...).  In practice all that accomplishes is make you want to write a do-it-all wrapper module to avoid all the boilerplate every time you create a new file.  Which entirely defeats the purpose of modularizing it.  :P

This doesn't mean I'm doing away with modules, mind you.  Being able to write a self-contained script that's guaranteed not to clash with any other library regardless of what you name your exports?  Pure unadulterated awesome.  So instead, my idea is for low-level stuff to be exposed globally, as in Sphere 1.x, while the more high-level "scripty" stuff gets put into modules.  For example, you can require("prim") to get convenient Sphere 1.x-like immediate-mode primitives:
https://github.com/fatcerberus/minisphere/blob/sphere-api-v2/assets/system/modules/prim.js

Or require("link") for Radnen's awesome query library. :D  For Scenario, you'd require "scenes", etc.  That kind of code makes sense as a module, but the core engine functionality is better if it's exposed by default.  That's, I think, a big reason for Sphere's high level of accessibility over the years, and I wouldn't want to give that up.
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rahkiin
  • [*][*][*]
Re: minisphere 3.1.2
Reply #1196
So what are you going to do? You don't actually mention that.

My engine just always loads the audio and graphics stuff. You just load an API using the require() stuff... it is not that only then the graphics is set up.

I think it is nice to have modules. You could then easily extend api's or override them as a user. So instead of using 'graphics' y ou could do 'let graphics = require('./myGraphics')' which loads an API that has the same API but does stuff differently. It allows for modulism.

I would like to hear what else you propose. If you throw it all in global space, you can't override them anymore: not using modules anyways. Always only within the same module...

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.1.2
Reply #1197
I thought I explained it plenty well: Low-level functionality would be global, anything "user replaceable" is a module.

The thing is, you probably aren't going to override the native functions because they're so low-level.  There are no "user-replaceable parts" there.  It's impossible to replicate the basics of Galileo in script, for example.  So if you're not changing the API, what could a replacement graphics module actually "do differently"?  All the higher level stuff that you would want to swap out like the map engine, cutscene manager, etc. is still going to be in modules.

That's why I'm designing the core to be so low-level by the way - the engine provides the bare minimum functionality to make a useful game out of the box, and all modules are built on top of that.

Think of how annoying it would be if, in JS, you had to require("array") in every file that worked with arrays.  Or require("string") for strings, etc.  It would be infuriating.  That's the level of functionality I'm talking about making global, the basic building blocks.  Everything else is modular.
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rahkiin
  • [*][*][*]
Re: minisphere 3.1.2
Reply #1198
Hmmm.

So you will be adding a large bunch of globals? Make sure they are all classes and start with capitals.

Could you give me the classes you will expose?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 3.1.2
Reply #1199

So you will be adding a large bunch of globals? Make sure they are all classes and start with capitals.


Not nearly as many as you're probably imagining. ;)  It won't be anything like the Sphere 1.x API, that's for sure.

For reference, here's a list of every single global in minisphere 3.1.2:
https://github.com/Radnen/spherestudio/blob/master/ScriptEditPlugin/Dictionary/SphereAPI.txt

minisphere 4.0 won't even have a fraction of that.  Like I said, I still very much prefer modules for high-level functionality.  Here's my current module list:
https://github.com/fatcerberus/minisphere/tree/sphere-api-v2/assets/system/modules

Global classes/namespaces are currently:
Color
Group
Image
Logger (<-- is now a module :) )
Mixer
Server
Shader
Shape
Socket
Sound
SoundStream
Surface
Transform

global singletons:
console
engine
fs
keyboard
manifest
random (<-- this can probably be a module too)

"manifest" was going to be called "game" but I found that it tended to get shadowed in practice, causing bugs.
  • Last Edit: May 15, 2016, 02:06:41 pm by Lord English
neoSphere 5.6.4 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub