Skip to main content

News

Topic: neoSphere 5.9.2 (Read 522308 times) previous topic - next topic

0 Members and 23 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1635
@DaVince: In your Cellscript template, The files() for transpile should be recursive, as most people, myself included, like to organize scripts into subfolders.  For a native Sphere v2 game that doesn't need backward compatibility, I also recommend transpiling into @/bin (rather than @/scripts), as a hint to a person looking at the distro that the game has been compiled in some way and they should look for the real source code if they want to make edits.

In other words:
Code: (javascript) [Select]

transpile('@/bin/', files('src/*.mjs', true));
transpile('@/bin/', files('src/*.js', true));
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.5.11
Reply #1636
Okay, I'll  make the changes. And now I know what the true statement is for. :P

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1637
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1638
I want to refactor the standard library for miniSphere 5.0.  The code is all over the place currently and different modules use different styles; they sometimes don't even use module.exports consistently. What I think I'd like to do is reorganize it so that the CommonJS view is split at the object level--each require() module would correspond to a single namespace, function, or class--while the ES6 view would have it all merged into a single composite module, making everything more intuitive for both environments.

Node style (CommonJS):
Code: (javascript) [Select]
const from     = require('from'),
      Delegate = require('delegate'),
      Music    = require('music'),
      Scene    = require('scene');


ES6 style:
Code: (javascript) [Select]
import { from, Delegate, Music, Scene } from 'miniRT';


Which really shows the strength of the ES6 module syntax compared to old-style require() :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1639
There will be some minor compatibility breakage in miniSphere 4.6 in preparation for the above change.  I can still technically do that because the Sphere v2 API hasn't been finalized yet ;)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1640
Idea I had: Example project could take advantage of classes:

Code: (javascript) [Select]
import Thread from 'thread';

class Game extends Thread
{
    constructor() {
        super();
        // startup code
    }

    on_update() { ... }
    on_render() { ... }
}

new Game();


The Thread constructor sets up the dispatch automatically, avoiding the need to deal with the Dispatch API or threader directly.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1641
This is what the new game template looks like now:
https://github.com/fatcerberus/minisphere/blob/master/assets/template/src/main.mjs

Much cleaner and doesn't require you to understand the Dispatch API :D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.5.11
Reply #1642
Looks great, much easier to get started with!

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1643
Regarding file association, I think Linux has regex-based associations, so we could define a standard that the first field in the JSON file must be version and then use a regex like...

Code: (regexp) [Select]
^{\s*(?:\r?\n)*\s*version:\s*\d*


...to associate them with miniSphere without pulling in all JSON files.  Unfortunately Windows associates only based on file extension :(
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.5.11
Reply #1644
Well, why not give it its own extension then? I still think s2gm is a good candidate (for a file extension), and the contents can just stay the JSON format that they're in.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1645
The reason I chose game.json was for consistency with Node.js package.json.  I wanted more veteran JS developers (like myself ;)) to find Sphere approachable and familiar too, not just newbies.  Plus .json is more likely to have "Edit" as an option in its right-click menu in a default Windows setup, whereas an unknown format won't be associated with anything.

And you can always compile to an SPK ;)

I guess both have their pros and cons.  I'll revisit the issue after I finish up the module reorganization and release miniSphere 4.6.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.5.11
Reply #1646
Sounds fair, although to me it's felt like the json file just tends to be the resulting file after compiling with Cell (even if not strictly necessary), especially now that ES6 transpilation is going to be a common thing. I always found having a project file to double-click in order to run it more convenient.

Well, I guess since I've only recently started learning the New Way of Doing Things, I'm still totally used to having the sgm. :P

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1647
miniRT is being promoted to a first-class part of the Sphere v2 API.  This will split the API into two levels: the low-level Core API which can't be implemented in script such as Galileo, Audialis and the like, and sphere-runtime, which is more high-level with stuff like the Thread class, Scenario, the Music manager, and more.

I'm hoping this change will make Sphere v2 more approachable, as I've noticed that people tend to get scared away due to the more low-level design.  I try to point people to miniRT as consolation, but I think there's a stigma there due to it seeming like a third-party add-on, albeit one that happens to be bundled.  Making it an official part of Sphere v2 increases the burden for standardization, but should avoid the "inferiority complex". :P
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.5.11
Reply #1648
I think this is a really good idea, and it's good that you're pretty much immediately showcasing what it can do in the example project.

Re: miniSphere 4.5.11
Reply #1649
I agree, especially considering image/surface blitting can be very tedious without the respective miniRT module. It's almost necessary.