Skip to main content ↑ ↓
Topic: Future of Sphere: Cell command line compiler (Read 79673 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Future of Sphere: Cell command line compiler

To go along with the upcoming minisphere 2.0, I started work on a new Sphere compiler, which I've named Cell.

Alll the issues in the past with game.sgm contents being overwritten by various editors?  Well, that's solved handily with Cell.  With a script like this, called cell.js in your game source directory:
Code: (javascript) [Select]
function make()
{
	game({
		name: "Spectacles: Bruce's Story",
		author: "Fat Cerberus",
		description: "Follow Scott Starcross in his quest to stop the Primus.",
		resolution: "320x240",
		script: "main.js"
	});
}


You run cell on the command-line and get this output:
Code: [Select]
$ cell
Cell 2.0.0  (c) 2015 Fat Cerberus
One minute left! There's nothing you can do now... ha ha ha ha!

Processing target 'make'
Success!


Since the build script is JS, it potentially has a lot of power, as long as the bindings are there.  Besides the basic stuff like copying files, there could be functions to, e.g. generate an RSS spriteset from a set of images, or perhaps if there's a vector-based map format in the future it could be converted into a Sphere-compatible RMP by a Cell script.  The possibilities are, quite literally, endless.

The idea for this came about due to Radnen's idea for a scriptable build pipeline in Sphere Studio.  I actually started implementing that (the initial effort can be seen in the Studio build included with minisphere 1.7.11), then realized it would be very useful to have this kind of functionality universally, accessible from the command-line as well as in the GUI.

What do you guys think of this development?

Re: Future of Sphere: Command-line build system

Reply #1 –
Sounds interesting!

Quote
or perhaps if there's a vector-based map format in the future it could be converted into a Sphere-compatible RMP by a Cell script.

Here's an idea, but what if you have two pics, one being a static map pic, and the other a black & white collision map for that map. Could this build system allow you to convert that into an RMP (or future map format) with proper collisions (either through vectors or by setting up tile obstructions)?

It's just a hypothetical idea, although I really see this having its uses in, say, platformers.

Re: Future of Sphere: Command-line build system

Reply #2 –
Oh, most definitely.  The default JS environment provided for a Cell build will probably end up including basic file primitives like Sphere's RawFile (which, incidentally, will be deprecated--note: not removed--in minisphere 2.0 and replaced with the new FileStream object) but probably also things like MapWriter, SpritesetWriter, etc. for generating Sphere-format files.  So it would just be a matter of writing some JS to read your custom images and then use a MapWriter to save out the RMP.

Here's a GitHub issue about it too, although right now it doesn't have much more information than I already provided above:
https://github.com/fatcerberus/minisphere/issues/43

Re: Future of Sphere: Command-line build system

Reply #3 –
Completely necessary and relevant image:


:o

Re: Future of Sphere: Cell command line compiler

Reply #5 –
So Cell is now as functional as the build pipeline prototype I did for Sphere Studio, now on to the feature that will make it worthy of the "compiler" title: SPK creation!

Re: Future of Sphere: Cell command line compiler

Reply #6 –
Well that was painless.  I love the SPK format, it's so simple and easy to work with.  Honestly most of the difficulty I had with it in minisphere wasn't the unpacking and reading files, what caused me the most grief was the fact that you NEED a canonized path to access anything in the archive since files are indexed by their full path.  In the end I kind of like that though--it saves having to maintain multiple index structures for each directory, it's just a flat list of files.

It does make it difficult to non-recursively enumerate files in a directory, though (this is needed for GetFileList())

I probably should make an SPKv2 format though, the current V1 format uses 32-bit offsets but it wouldn't be hard to make a format with 64-bit offsets instead and support >4gb packages.

Re: Future of Sphere: Cell command line compiler

Reply #7 –
So I had an epiphany earlier and finally understood the SCons dependency model.  It turns out the system is actually very powerful being designed the way it is.  Unlike most build systems, it doesn't work in terms of sources, but rather in terms of targets.  This was counterintuitive to me at first (see recent comments in minisphere thread), but it actually makes a lot of sense: Your dependency is on the output of a build, not its input.  So I decided that Cell will use a similar model.  Instead of having functions to build stuff serially and then installing files like this:
Code: (javascript) [Select]

install("src/*.js", "scripts");
buildSpriteset("something.rss", "something.sprite");  // or whatever
install("something.sprite", "spritesets");


It would instead be more like this:
Code: (javascript) [Select]

install(files("src/*.js", { recurse: true }), "scripts/");
install(spriteset("something.sprite"), "spriteset/something.rss");


In other words, instead of directly installing files, you install assets.  This is indeed much more robust as it allows the compiler to determine the proper build order of the various dependencies on its own without the build script having to worry about everything being in the right order.

Re: Future of Sphere: Cell command line compiler

Reply #8 –
It's actually a relatively common model among Unix-based build systems. Make uses a similar design, although it mainly just uses that to determine what order to build things. Since make is not nearly as declarative, it is less apparent. With SCons, it is clear(er) you are emitting dependency declarations, and after all the scripts run the dependency graphs you have generated are run.

Re: Future of Sphere: Cell command line compiler

Reply #9 –
I like that change, it looks easier to understand. I usually dislike short or cryptic build instructions, but even though this is shorter it reads much cleaner and that's always better. Too verbose and it can look cluttered from a distance. This is very succinct and straight to the point. +1
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Future of Sphere: Cell command line compiler

Reply #10 –
The declarative model has another benefit I realize: Cleaning can be implemented in the build tool itself by simply going over the declared assets replacing the "build" step with a "delete" step, obviating the need for a separate "clean" target like what's required when using make.

Re: Future of Sphere: Cell command line compiler

Reply #11 –
One thing I've found that's nice with working with target declarations instead of directly with names as, e.g. make does, is that there's no real need to build a dependency graph - by definition, a target must be declared before it can be mentioned as a dependency, so all I have to do at build time is run through the targets in order of appearance.  This also makes circular references logistically impossible as far as I can tell, alleviating the need to specifically detect cycles.